Getting the Most from Design Deliverables

That’s a wonderful design. Now, write it up so development can implement it right away.

It seems there are some managers, (apparently from an ideal universe,) who believe, once a great design is hatched, a simple written document is all the development team needs to make it a reality. Unfortunately, for most teams, it takes much more work to communicate anything but the simplest of designs.

Designing the Design Deliverables

The design deliverables are a critical bridge between designers and developers. Both the documents and the process that produces and delivers them deserve careful attention.

We recently turned our attention to looking at how teams ensured they communicated the design ideas successfully to their development teams. Our research shows that teams lose many important details because of poor deliverables and a poor deliverable process.

The problem is compounded as the tools for interactions become more complex. As we see client-server interaction become more sophisticated and interaction capabilities, such as drag-and-drop, become richer, a simple “write-up” can’t do the project justice. The most successful teams play close attention to the critical goals behind their deliverables.

Goal #1: Getting Everyone on the Same Page

In the ideal universe, the designers and developers would all go into a special room. They’d put on special helmets. Within seconds, every detail of the design that any team member had would be instantly communicated to everyone on the team.

In our universe, problems occur because the developers can’t read the designers’ minds. It’s not that the designers are deliberately keeping important details from the developers. It’s that, when you’re neck deep in thinking about a problem, it’s hard to know if you communicated all the details in your head.

Among those details that frequently get lost in the crossover:

• The priority of the different design elements. Not every element in the design is equally important to the users’ objectives. In the design process, the team works out the relative priorities. However, if all that developers have to work with is a screenshot or a rough design sketch, the priorities are lost.
• Subtle interactions. Static images make it hard to show dynamic activity. It becomes more difficult when that motion is triggered by users actions that don’t have corresponding visible controls, like a mouse-hover behavior.
• The rigor of the design rationale. In the design process, some portions will be heavily discussed and considered by the team. They’ll try out multiple iterations, hammering out the result. Once turned over to developers, changing these portions can upset a carefully tuned balance. However, other portions will remain unchanged from the beginning. The developers need to know there may still be more flexibility in these portions.

There are tricks to creating a deliverable process that gets these details across. For example, we learned from Keith Robinson at the Seattle design firm, Blue Flavor, that his firm creates a design priority document that describes, in priority order, each design element and how it works. As implementation issues surface, the document acts as a guide to making decisions.

To help communicate the more complex interactions in the design, consider delivering an interactive prototype along with the written description. Many teams we talked to use prototyping tools, ranging from paper prototypes to sophisticated Flash implementations, to show the developers how the design works. These prototypes don’t have to be fancy, as they only need to show how the interface will operate when implemented. In fact, we’re surprised how effective crude paper prototypes can be and how pleased the developers are to have them to work from.

One team we talked with uses a visual language to communicate the rigor of the designed features. Those elements they’d rigorously thought through were in regular text without any indentation. Those elements that hadn’t yet received much consideration were italicized and indented. This simple, yet effective, visual language told the developers what they needed to know.

Other teams made sure they included a description of the testing process they’ve used and the rationale behind the finalized designs. Communicating the design rationale, along with the finalized design description, can help the development team maintain the integrity of the high priority elements throughout the implementation process.

Goal #2: Reducing Development Costs

In the ideal universe, every aspect of the design would work perfectly on the first implementation, without ever needing “redo” work.

As we talked with teams, we found many had been plagued by ideas that looked great “on paper”, but didn’t work so well when implemented. Sending the design back to the drawing board and the subsequent redo work involved increased development costs and slowed deployment. Anytime the team can find a way to reduce or eliminate these costs is good for the organization.

Many teams turned to low-cost, fast-implementation prototyping tools to help reduce costs. Again, these don’t need to be sophisticated tools—only something that quickly communicates the design’s intent.

Having a working prototype is useful, but it’s better when you have accurate use cases to work with. The teams with well-researched personas and scenarios found it easy to create their use cases, helping them validate their prototypes. By running the prototypes against the use cases, they could see where the design would hold up and where it fell flat.

When updating an existing design, a couple of teams used before-and-after images to help communicate the differences. Seeing the old design next to the new design, along with a clear description of the changes, helped the development team plot out their work.

Goal #3: Making Edge Conditions Explicit

Back in the ideal universe, you’ll be happy to find out that users only take the “happy path” through the design. (The happy path is the easy, straightforward sequence through an application without any of the complications.)

Unfortunately, the happy path won’t cut it for most real-world uses of the design. Instead, the team needs to clearly communicate the flow branches and edge conditions that could arise. Edge conditions are hard to visualize, making them an easy thing to miss when communicating the design to the development team.

Solid research is key to identifying the edge conditions that can pop up when using the design. Several teams established solid communications with the organization’s support center, collecting up a list of the types of problems the support specialists were handling.

Other teams held “What Could Go Wrong?” brainstorming sessions, to imagine what happens when key information, such as account numbers or hard-to-remember personal information, was left out or incorrectly entered. (37signal’s book, Defensive Design for the Web, is a great resource for brainstorming these types of problems.)

Of course, many teams used usability studies to identify the types of issues that can arise. However, a few others used some novel approaches, including rewarding team members for helping identify edge conditions. One team went as far as holding edge-detection parties, where team members competed to see how many different, unique edge conditions they could produce in a short time period.

One novel approach we turned up was the use of a “Values List” to help ground the designers and developers on the underlying values instilled in the design. These values might include “We don’t want our users to feel stupid” or “If we can avoid an error message, we will.” Having values help team members know when a little extra effort or resources might be the right way to fix a possible problem, instead of taking the easiest implementation.

One team produced a Contingency Q&A document, which helped them account for paths beyond the happy path. It posed questions, like “What happens when users leave the Headline Field blank?” or “What happens when they try to type more than 60 characters into the Headline Field?” Their answers went beyond the specifics and discussed the underlying rationale. (This would match up well with the values list.)

Creativity in Deliverables

In our research, the teams producing the most effective designs all had well-considered techniques for their deliverables process. They understood they weren’t living in the ideal universe and dedicated the resources to ensuring they communicated design and its rationale to every member of the team. The results paid off with shorter development times and a higher-quality implementation.