All the WPF presentations I've seen made a big deal about how this technology allows you to separate the work of the designer and the developer. The designer can go about, designing away with the Expression tools, crafting a XAML file. Then the developer can add C# logic to the relevant CS file.
When I actually tried to do something with WPF, it immediately seemed suspicious to me. XAML, apparently, is also code. Not only that, it is also tightly coupled to the accompanying "code-behind". There seem to be some things that you just can't do with XAML - and I'm talking about visuals - like making a video resize correctly. Anyway, while coding I kept going back and forth between the XAML and the code until I got the result I wished for.
Now, I'd be the first to admit that I'm not WPF pro, but I do have experience with ASP.NET, and it is the same way there - It is good to have a separation between display code and behavioral code, but I just don't think that it would ever work if someone handed me an ".aspx" file and told me to "just add my code to that".
I think that it might work if the developer and the designer worked together (i.e. same desktop) on creating a window. Or if the designer works only on very limited things, such as control templates and styles. But coding a complete XAML for a window with Expression and passing it on to the developer? I doubt that the latter will be able to read the damn thing, let alone work with it.
Then again, I might be wrong. I really have no idea, as I don't know anyone who works with WPF on a daily basis and has a designer in his team. Just had an itch to talk about this.