Wednesday, January 30, 2008

Getting The Most From Design Deliverables

Getting deliverables accepted ...

"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."    (Continued via UIE, Jared Spool)    [Usability Resources]


Post a Comment

<< Home

<< Home