The flow of ideas and assets from design to development has been a sticking point in web development since the beginning of HTML. Designers would create a design, hand it to a developer and the end result was rarely what the designer intended. Sometimes this disconnect was due to the skill of the developer, maybe they didn't know how to do what the designer wanted. Other times it was due to the designer asking for something that wasn't possible with the technology being used. Whatever the reason, it often left all parties less than satisfied.

Today, with the advent of Silverlight and other RIA platforms, the problem is even worse. Over time designers and developers have figured out the limits of HTML and everyone worked together nicely, for the most part. Now with the advanced capabilities, we back to ground zero.

Patterns

Today there are several patterns that this workflow takes with Silverlight today. This list is not complete I'm sure so please let me know how your company does it, I'd love to hear about it.

Solo

With this approach a single person does both design and development. This pattern has the advantage of one person knowing both the look/feel and doing the implementation. Unfortunately, very few people have the skills in both arenas to create an application that is aesthetically pleasing, intuitively useable and functionally complete. In most cases what you end up with is an application that "looks like a developer built it" or one that has problems with the code that will introduce bugs and increase maintenance costs.

Walls

This is quite possibly the most common pattern in use today and is often referred to as "throwing it over the wall". This frequently results from (or causes) a feeling of "us vs. them" between development and design. You end up with each side feeling like the other is making decisions not based on client desires or technical limitations but out of laziness or, in extreme cases, spitefulness against the other group. If not managed properly this pattern can have a significantly negative effect on morale and productivity. It also rarely ends up with any party being completely satisfied.

Iterative

Design -> Development -> Design -> Development etc. This is in general a good pattern. It gives the designer a chance to give feedback on how it is being implemented and the developer a chance to see what is possible. The biggest downside to this approach is the time it takes. In today's environment, too often by the time the developer has started implementing the design, the designer is off on another project.

Middleman

With Silverlight development, this is quickly becoming the pattern of choice. With this approach you essentially have one person that sits between design and development. There many names for the role of this person: Integrator; Producer; Devigner. the person in this role can come from either a design or development background but is fairly comfortable using some skills from the other field as well. This person has a deep understanding of Silverlight objects and Expression Blend. They take a design and create Silverlight objects from it that are true to the design and ready for developers to wire up. Sometimes this is the same designer that created the design, others it is the developer that wires it up. Often though it is someone independent of either effort. One disadvantage of this approach is that it can take a considerable amount of time to get someone to the level where they are able to confidently fill this role.

Nirvana

At least with Silverlight, the dream is that designers create their designs in Blend in the exact same project that the developers are coding in. In essence it would mean that all of your designers are at the middleman level of competency with Silverlight. While the technology does support this, so far most companies have had limited actual success. This is partly due to Blend not being as powerful as the tools the designers are used to using and it just being 'different'. In time we may get to the place where this happens but I wouldn't hold your breath.

How do we Improve?

As with most things in life, we can't improve until we know where we are at. Any organization that want to have a good designer -> developer workflow needs to take a look at what they are doing currently and what aspects of it are working and what aren't. This is certainly not something one size fits all. Each organization will need to find it's own blend of techniques that work for it. The important thing is that you identify a process and be ready to continually change it as people's skills and interests change.

What processes are you using? Do they work well? Are they different than what is discussed here? Let me know.