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.
