UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 664 May 5, 2011

Understanding Designer-Developer Workflow

The most appealing software applications developed today are produced by a close collaboration of designers and developers. Unfortunately, the existing development and design tools have been a barrier that keeps everyone from working with a productive workflow. As of late, rich Internet application (RIA) technologies such as Silverlight, WPF, Flex, and client-side HTML5/JavaScript have attempted to destroy this barrier with varying degrees of success.

Examples of Workflow

A workflow is the set of steps used to achieve a goal. The designer–developer workflow refers to the way designers and developers work together to produce a product. It includes the steps taken to start a project, evolve it, and finish it. Since software is never developed without tools, the tools that the designer and developer play a vital role in the workflow. For a designer, these tools include art programs such as Adobe Photoshop or Illustrator. For a developer, these tools are suites such as Silverlight, Flex or Ruby on Rails.

Consider some common workflow patterns:

The Jack-of-All-Trades

The Jack-of-all-Trades is an individual who wears many hats. She designs the look-and-feel, produces assets, architects for usability, and implements the final product. When there is only one person involved, the workflow is extremely efficient and is supported by most tools. Efficiency is certainly a good thing, but it comes at a cost. Unfortunately, it is quite rare that any one person can produce a quality design, experience, and implementation. Some, if not all, aspects of the product get compromised in this workflow.

Over-the-Wall

Most people are familiar with the Over-the-Wall workflow. The designers and usability experts come up with a vision and pass it over the wall for the developers to implement. Important subtleties (such as transitions and easing) often get miscommunicated or lost and the final product is a limited rendition of the original vision. The designers and developers often have close communication but there is a technological barrier that keeps the designers’ vision separate from the actual product. The designers are rarely able to directly affect the final product. This workflow does support a back-and-forth communication, but the ideas are still passed “over the wall.” The biggest reason we continue to use this workflow tends to be related to the lack of tools for the technology being used. Web-based projects, for example, use this workflow.

One-Way

The One-Way workflow is a form of Over-the-Wall workflow where an integration tool (e.g., Adobe Flash Catalyst) is used to start the project. The designers and usability experts import their comps into a tool that creates a project that a developer can start with in her tool suite. The integration tool aids the creative team in state management, transitions, easing and componentization. It is a significant improvement over the Over-the-Wall approach because the designer has more direct control of the final product. Unfortunately, this process only goes one way—from design to development. The designers will continue to effect changes after the initial project creation but the changes are still pushed in one direction using the integration tool. Iterations using this workflow often require new components and modifications to be merged into the existing product. This merging process is tedious and error-prone.

Round-Trip

The Round-Trip workflow builds upon the One-Way workflow. The developer can add behaviors to the product and then send the product back to the designers for further updates. The designers and UX experts then make changes and send the product back to the developer to continue affecting the behavior of the application. This workflow continues back and forth in an iterative way and allows the product to grow more organically. The biggest problem with this workflow is that one group is always blocked as they wait for the other to finish. It can be optimized using a more modular approach (breaking the product up into smaller projects), but it forces an architecture that may not be ideal for the product.

Fully Integrated

The Fully Integrated workflow allows every person to modify the product simultaneously. The integration tool works directly out of the software code base but hides the code from the designers and UX experts. Everybody who works on the product can modify it at any time. It leaves the experts to do what they do best and the product evolves naturally. The team collaboration is heightened using this workflow because there aren’t any roadblocks to productivity. It is the most direct way for designers to affect the final product because they essentially become part of the development team.

Cross-Discipline Roles

With the technology to produce user experiences the way we envision them, a new role has emerged: the Integrator. The Integrator is responsible for translating comps (usually Photoshop or Illustrator projects) into components that make up the software. The Integrator knows enough about the design tools to apply vector and raster art to the product. She also knows enough about software development to componentize the application so that a developer can work with it easily.

The Integrator is more of a role than an individual. A designer can be designated as the Integrator, or a developer can fill this role instead. Ideally, everyone on the team should feel comfortable to act as an Integrator. In this way, the disciplines overlap.

This requires designers and UX experts to understand component models and separation of concerns. They must understand that a developer cannot effectively work with an unwieldy code base, so they must produce compositions of smaller parts. Proper naming conventions must be agreed upon so that the developer can apply behavior to the components in a way that makes sense.

Similarly, the developers need to understand that UX matters. They must preserve the original intent of the creative team without compromise. The developers need to know how to use the integration tool even though it may feel more like a design tool. The integration tools are extremely powerful and the developers need to understand how to use them, ideally at an intermediate level or better. Developers of software in stacks that support integration tools (WPF, Silverlight, Flex, etc) will never properly leverage the power of the framework without learning the integration tool for that stack.

This type of cross-pollination will be vital to the success of applications in the near future. Designers and developers will be working more closely together with integration tools so they must understand more about each other’s worlds. Those who understand this now will be ready for when it is a common expectation.

Some Examples of Tools

Flash Catalyst

Adobe Flash Catalyst is a tool that enables the design to be easily translated into a Flex product. Although it does not support a Fully Integrated workflow, it does support all other workflows mentioned in this article. The Integrator can import Photoshop or Illustrator assets via files or copy/paste. It is important that the Integrator break the application into components using Catalyst, and the tool makes this easy. Within Catalyst, the Integrator can define visual states for custom components or apply assets to known components (such as Button or Checkbox).

Expression Blend

Microsoft Expression Blend is an integration tool that also supports the transfer of comps to applications on the Silverlight and WPF platforms. Users of Expression Blend can employ any workflow mentioned in this article including the Fully Integrated workflow. Expression Blend works directly out of the software project folder as if it were a developer tool. The only difference is that the tool hides the implementation and allows the Integrator to template anything in the system. This tool has a steep learning curve, but the power available is significant. Expression Blend supports templating, states, transitions, easing, behaviors, and plug-ins.

What About HTML5/CSS/JavaScript?

Unlike Flash Catalyst and Expression Blend where the integration tool focuses on a specific and well-defined target (Flex and Silverlight), there is no standard integration tool for the Web. There is a hole in this space. We have CSS and JavaScript libraries that can work with a myriad of web stacks, but we don’t have any tool that allow Integrators to do what they can in Flash Catalyst or Expression Blend. This reinforces the idea that designers and developers need to overlap in order to produce a user experience similar to the one that the design team envisions. Until the Web gets integration tools similar to Flash Catalyst or Expression Blend, Flex and Silverlight will continue to have a leg up when it comes to user experience.

What Do We Need?

Future tool sets need to consider designer–developer workflows more. It would be nice to see a web tool, for instance, that allows a designer to define visual states, translate vector art into HTML5, style using an actual design-centric tool instead of using a CSS metaphor, and aid in the control of state transitions. Ideally, integration tools in the future will define a component model that aids in the development of design-driven applications, even for the Web.

In the meantime, what can we do? Until good tools are created for the technology stack you are using, designers need to become a bit more technically savvy. Designers need to better understand CSS and HTML5, for example. By getting closer to the implementation, designers have the freedom to affect the final product the way they want rather than leaving it to the developers to interpret the design requirements. Using this approach, the web development workflow can get much closer to the Fully Integrated workflow.

Another approach might be for the development team to find areas in which the designer can effect the most change and develop internal tools to aid the workflow. Every team has their own flavor of the designer–developer workflow, so their own tools can support that workflow best. That being said, it is certainly better to use off-the-shelf tools for this purpose, as they often are more mature and cheaper. The decision to build your own versus buy will come down to several factors including technology, existing tools for that technology, team dynamics, and the desired workflow.

Conclusion

Workflows matter. The closer you get to the Fully Integrated workflow, the more the creative team can affect the final product. Rich Internet application technologies such as Flex and Silverlight are currently dominating the usability space, but this is likely to change as we craft our web workflows to suite our needs better. The ubiquity of the web will drive us to innovate in this space.

Take a moment to consider what workflow you employ within your organization. Can you do better than what you are doing now? Will your product benefit from an improved workflow? What might you do to make this happen? Do your designers need to become more technically knowledgeable? Do your developers need to understand design better? Do you need to develop your own tools? The answers to these questions will depend on your own situation, but asking them will likely benefit everyone involved, especially the end user.

ABOUT THE AUTHOR(S)

User Profile

Brian Genisio (@BrianGenisio) is a senior software consultant for SRT Solutions in AnnArbor, MI. He focuses on RIA technologies such as Silverlight and Flex.

Add new comment

Comments

29
31

nice

23
32

Thanks for posting this

23
40

Issac and Kasey,

I don't think we disagree as a whole, possibly on a few points, wording, etc.

I do think that for where we are today with tooling, it is important that designers and developers cross-polinate.  I make that clear in my article.  Where I think we disagree is whether or not CSS SHOULD be a design tool.

In other words, I agree that CSS is a design tool today.  But to me, CSS is more of an implementation detail.  That a web designer needs to get down to the CSS and HTML is an artifact of the lack of tooling, in my opinion.  It comes down to a lack of well thought-out metaphors for design in the HTML stack (due to the evolution it has taken).  If the component model of HTML/CSS (not much of one as of today) were more powerfully abstracted, you wouldn't need to deal with CSS as an implementation detail.

A good designer needs to know CSS and HTML today because there isn't anything better.

I am not trying to say that a good integration tool will improve your UX skills.  I am trying to say that a good integration tool will facilitate a more efficient workflow.  The time it takes, for instance, for me to break up an Illustrator file into skinned components (using Catalyst) ready for development is significantly faster than what I have ever seen for the web.  I WANT that tool for the web.  I want to be able to rapidly rip apart a design and apply it to a well thought out development environment.

Until then, we have what we have... and you are completely correct.  Web devs need to cross into design.  Web designers need to cross into dev.  

Brian

29
35

I have an issue with "style using an actual design-centric tool instead of using a CSS metaphor."

I'm a web designer. I went to school for Graphic Design and started in the Print industry. When I moved to the web, I knew I needed to do it right.

CSS *is* a design tool. You have to think like HTML, and know the limitations of the web in order to design a good website. Some of the best advice I ever received was in Drawing 1 in Art School:

Your medium defines your art. You can't make an oil painting look like a technical drawing. Don't fight the tools, embrace them for what they are.

or "If you're going to design on the web, learn HTML and CSS."

27
36

"Web-based projects, for example, use this workflow."

This is a silly distillation. I think you're discounting the ability for teams to work well together, regardless (or despite) the tools they are using. You don't _need_ flash, Flex, or Silverlight to get a great user experience on the web, or anywhere else, you need a good team.

"...hides the code from the designers and UX experts"

If you are a UX expert, you can't be afraid of the underlying technologies powering your interface.

If you are, you won't know its boundaries and its limitations, of which your tools won't protect you from. I don't believe that you can be an expert, and have the code hidden.

I agree that you will have a sub-par product with anything less than a "fully integrated" approach, but I think you stop short of the real goal of a fully integrated approach. Designers don't "essentially" become part of the development team, the ones worth their salt are pushing to the repo.

Designers code, coders design, everybody has commit access.

"...Flex and Silverlight will continue to have a leg up when it comes to user experience."

Now you lost me. There aren't good integration tools for the web or even iOS/OSX as a whole, but the amount of _top notch_ user experiences on these platforms, compared to flash, flex, silverlight or much of anything else is astounding. It all goes back to the team, not the tools. Tools won't improve anybody's UX skills, and they won't improve the quality of communication in your team.

33
33

Thanks for this article, Brian! Certainly food for thought.

35
38

Great article. I was just drafting a blog post myself on how the designer-developer workflow is broken so I couldn't agree more.

I'm working on an open source mockup/prototyping tool called Mockdown right now that I'd like to see bridge the designer-developer gap. It's still alpha software but I'd love to get your thoughts on it once I get a demo together.

I started a blog (http://polishing.ricksha.ws) about the process of building it. I need to integrate Disqus comments but I'd love to hear anyone's comments on what would make a great mockup tool.