Designer / Developer workflow

So, I wanted to take a fresh look in the community again to see what others are doing in this space. Specific to the .Net 3+ stack, we've been using various workflows for over five years now, but I'm always curious to get fresh insights as to what works and doesn't work. Visual Studio 2008 and Expression Blend 3 afford some luxuries to solve this dilemma to some degree, but truly doesn't provide a seamless mix of tools and support that fixes this in all cases - let's face it, resources have their own constraints, and we'll have to live with that. And frankly, this is where the breadth of an org's resource pool (when properly distributed with the right roles) really shines. So, I don't want to convey a forcing function to standardize "proper" workflow for both Designers, Developers, and Integrators (if you don't know the meaning of the latter role, at least our meaning, please read Nathan's article on the Integrator here as well as his very straight forward article on integration therero found here) - aka, Deselopers, Devigners.

In my Web travels this morning, I found a good article from Tim Aidlin @ MixOnline called "How we work (and sometimes skip some steps)". From this read, I have one key takaway that really sums up my feelings. "It depends - wireframes are great tools when used properly". And here's a two-fold statement on this behalf. As a consulting org and a project manager, we don't always get the most ideal resources for the job. We make do with who we get, and cater the project around their strengths to deliver results and good success for the client. Secondly, in terms of necessities for taking the design directly into production, like HTML, CSS (or more specifically for us, as basic XAML) assets really depends on what we're trying to solve for the problem at hand. Now, I'm not trying to say that we should toss any old resource at the problem, and getter' done one way or the other:-). What I am suggesting though is that we need to be very critical about how and why we're bringing on a particular resource for the job - an Information Architect from the creative team, vs. an Interactions Designer from the creative team, vs. a Visual Designer from the creative team, vs. a resource with some mix of Integration and Creative skill sets.

Hopefully, I've still got your attention - I do, right?? If we're trying to comprehend a client's issues, we must first have a solid problem statement that defines what our client is trying to solve and to what degree, and craft this immediately into the Opportunity phase of this project. From here, we should be able to deduce which "role type" we need to bring in to help. For instance, if we think taking use cases w/user personas and generating some high level wireframes to solve these needs is vital, you'd better be asking yourself, "...how necessary is this? Will our client truly need a redesign to its existing solutions, has visual style already been well defined and we shouldn't mess with that tier, is layout and general interface design important at this point or already approved elsewhere, can I break ground with my new technology stack, did my client see something cool at some conference and they say, I want. Did you ask, why?" Likewise, if I bring in an Interactions Designer to exploit my target platform by way of motion tests and wireframes on the whiteboard, am I truly doing right by my project because of the list of questions above?

Wireframes should be used when appropriate for the situation. Conversely, despite my remarks here, I am a firm believer that the Information Architect (or he who creates wireframes in your org) needs to set in motion, by way of an agnostic nature, the required flows through the proposed solution. To say that wireframing, in our line of work, inside of Blend or SketchFlow is the Holy Grail is a falsity - I'm on the wagon that says down and dirty whiteboarding and team collaboration is very important. We don't skip wireframes, for the sake of expeditiousness, and take the designs directly into comps using your design tool of choice: Photoshop, Illustrator, Expression Design. I don't want to agrue over which method is best; there isn't one IMO. Introducing visual style, interface, and UX into the mix should happen in parallel with the wireframes. I regress to my earlier statement about using the resources you have on your project...unless truly junior, each resource has its own way of conveying wireframes and working with the creative team to stitch them into interface comps, perhaps even prototyping interactions in 3rd party utilities, or taking design directly into Blend.

Furthermore, have you really decided which workflow method you'll use for your project at hand? So, back to the title of my post...how does all of this affect the developer who needs to be tightly coupled as well? Perhaps we can we take the project from wireframes directly into Blend if we've got a resource capable of spilling out the app's framework mostly in XAML. Next, we introduce the Developer/Architect type build the custom controls necessary to support the design. In tandem with this, the Interactions Designer gets a textual handoff from the wireframer that describes the intended interactions; this resource gets to work building these. Then, the Integrator and the Developer integrates the design into the solution...What about the converse to this (no, not, the "low top, All Stars" you're wearing)? If the solution is going to mimick an existing interface and interactions, why not consider letting the Developer build the core logic, functionality, and custom controls needed to support the "expected" vision in code - doing so with sound architecture and integration in mind along with lookless controls such that the creative team can provide a design to skin it? From here, the Integrator can stitch together the design and polish up the visuals where needed with the creative team? This is a risky option in some cases, and yes, can somewhat distance the creativeness that your team can bring. But if nothing else, I've learned one thing over the years as a consultant...we're not building the solution for ourselves - don't treat the project like a household pet. To reiterate, provide good user experiences and user interfaces commensurate with what the client wants - not your secret fancy for dancy bears and 3D rotations at every corner.

Still, as I've stated in several older posts over the years, as soon as we master this Designer/Developer workflow, I'll let you know;-).