If you are a designer working on a Silverlight 1.0 project, or if you are working with designers, check out the video by Arturo Toledo entitled "Workflow of Silverlight with Expression and Visual Studio from the recent "Silverlight 1.0 Fire Starter" event in the US.
Arturo talks about wireframing in Expression Blend and emphasises the importance of establishing a naming convention as early as possible.
Interaction designers typically create wireframes for user interfaces to represent the high-level interaction design - before visual design is applied. Typically, these wireframes are static, and created with drawing tools like Illustrator, Visio, OmniGraffle or even PowerPoint. Sometimes the wireframes are turned into click-through protoypes using tools like Axure, Intuitect or iRise.
One of the advantages of wireframing is that it allows interaction designers to test the usability of the user interface with real users before time is invested in coding, or visual design. Wireframes are also a great way to communicate the vision for a system to the wider project team.
Arturo talks about how to wireframe in Expression Blend. While Blend is not a prototyping tool per se, there are some advantages of wireframing in Blend, including:
In Arturo's video, he emphasise the advantages of establish naming conventions for the elements and storyboards in the user interface as early as possible. That allows developers (and visual designers) to work independently as the interaction design, the visual design and the actual application logic evolve.
So in the video, Arturo locks down the names for all the elements early, even though he doesn't know yet how they are going to look or behave on-screen.
Now, in a perfect world those names will never change, and developers and designers will live happily ever after. Realistically though, some things will change. For example, usability testing inevitably reveals problems with the user interface, which may require functionality to change, or to distributed across pages in a different way. This is gonna annoy developers. It just is - just as it always has. The best you can hope for is to minimise this disruption (with up-front, broad wireframing and testing), and to manage any changes as smoothly as possible.
In the video, Arturo shows a document which lists all the UI elements which the coder will need to interact with and their name and function. This is a good start, as it forms a kind of 'contract' between designers and developers, which will help manage changes over time.
This is good advice from Arturo.
If I had my way, there would be a way to encapsulate this kind of design documentation inside the design file in Blend itself, to make it easier to work with, and to reduce the chances of it getting out of sync. (Let's face it, designers are lazy when it comes to this kind of detail.)
Even better, Blend would use that information to produce a specification document, like Axure, iRise and Intuitect do. Or, best of all, Blend would talk to Visual Studio Team Foundation thingy and try and keep track of how changes in the code or the UI might affect each other and help manage that process.
In the meantime, check out this and the other videos from the Fire Starter event.