Doneness Matrices

A Pattern for Getting Projects Done

Delivering big, complex design projects can get really messy when many people get involved, each urgently zooming in different directions: James wireframing header nav, Jason cranking on product pages, Jody unifying components into a beautiful comp that our front end tech will build out. Don’t forget, James and Jason need to document stuff too!

Can we predict when each part will be delivered downstream and progressively rendered? Do we know how close we are to getting each thing done? More simply, just how done are we?

It’s time for a doneness matrix.

The Doneness Matrix

A doneness matrix is a grid (usually, just a spreadsheet) that lets you to track different parts of a design solution to completion across one or more stages or milestones. Rows represent the parts of the design, and columns represent the stages. At a glance, a doneness matrix provides both a bird’s-eye visualization of the project’s “doneness” and a detailed status of each item.

On some projects, the page layouts, modular components, icon sets, and other design elements comprise the rows. Columns represent stages like wireframes, pixel-perfect comps, annotated behaviors, and front-end code. The figure below depicts a typical doneness matrix, as it would appear part way through the process:

Use When

Despite diligent planning before a project even starts, the team can definitively identify deliverables and milestones only after digging into the design problem. Usually, there’s a moment early in the project when ideas converge around a specific approach. We know what must be done and who’s doing it. Use a matrix when:

• The scoped design solution is stable and well defined.
• You have identified most or all of the different parts to track, like page layouts, components, visual conventions, and more.
• You can articulate the activities you’ll do, like progressing from wireframes to visual comps to front end code and design documentation.

Don’t Use When

Doneness matrices don’t fit every activity, every time. Avoid a doneness matrix when:

• Projects have just a few parts
  Then, it’s not really worth it to go through the formality of a doneness matrix.
• Projects lack parallel, independent parts to work on
  For example, while a usability test goes through phases like plan, script, recruit, facilitate, analyze, and report, you won’t find some parts in the recruiting phase but others in the report phase.
• Identified parts are unstable
  If requirements, scope, and design ideas are unsettling the list of parts to do and how they are organized, it is premature to create and track against a doneness matrix.
• What to do varies significantly between parts You can’t create a matrix if each part has a different set of milestones. Instead, doneness matrices are most effective when items progress through the same stages.

Guidelines & How-To

It’s not hard, especially if you have a template to start from. Using the template as a starting point:

• Identify items row-by-row, usually consisting of page layouts, components, varied states, and other design elements.
• Confirm artifacts we’ll produce, usually a combination of wireframes (screen designs), annotations, visual comps, front-end code, and (unless we can avoid it) visual specs/redlines.
• Fill in any data on artifacts already done, iterating, or in draft form already.
• Collaborate to plan remaining delivery.

The most effective doneness matrices remain simple, work as a visualization, facilitate reviews, and create deeper alignment on delivery specifics. Guidelines to help you optimize your doneness matrices include:

Visual Structure

• Create a visual structure that, with a “squint test”, implicitly reveals progress. In this case, it’s a horizontal bar graph, with doneness progressing left to right.

• Be compact and highlight the most important data points. If you find yourself asking “How do I cram this text in here?”, be sure to balance the needs of extra data with the effectiveness of this dashboard display.
• Size it to fit a specific size (especially horizontally), such as a laptop screen resolution like 1280×800.
• Limit row height to 1 line per row to create a visual rhythm. Avoid wrapping text lines by being succinct and using cell comments.

Item-by-Item Information

• Artifact(s): Clearly identify the few artifacts you’ll progress through for each item, like Wireframes, Annotations, Comps, and Markup.
• Keep artifact-specific data simple, and avoid overcomplicating what’s tracked and perceived. Optimally, it’s a status (like “Draft”) and projected “Done By” date (like 1/15).
• Status: Settle on basic, ordinal status values, like Not Started, Draft (the client hasn’t seen it yet or is seeing for the first time), Iterating (the client has seen it but we’re refining), and Done (the client has seen it and approved it as done, moving us to the next step).

• Descriptions: Embed deeper descriptions (such as “What is this item?”) in comments revealed on hover in order to sustain consistent row height.

• Classifications: Classify items, such as by type (Page, Component or Map/Concept) and/or area (Homepage, Products, Checkout), but don’t go overboard.
• Owner: Identify who is responsible so you can answer “For this item, the ball is in who’s court?”
• Priority: Enable sorting by what’s most important, which can also be used for phasing or delivering “lot by lot.”

Using Color

• Reduce emphasis on inactive things (done OR not started) by graying type.
• Highlight delays of varying severity using warm colors, such as red for very overdue and orange for barely overdue.
• Use background color sparingly, except for (a) extreme circumstances, (b) meeting-specific highlights that can be removed easily, or (c) things that don’t change often (such as graying “done” bars).
• Avoid cell border colors. They look great when you first make them, but as things change, borders are a headache to manage.

Formatting & Values

• Make data values succinct, like using “Not Started” instead of “Not Yet Started”, “12/20″ instead of “December 20th, 2010″, and “?” instead of “Unknown”.
• Avoid subjective measures. What does 75% done mean? What matters more is “Is it done (so I can start), and if not, when do you estimate it will be done?”
• Use precise dates for delivery estimates, such as 8/20 and 8/27.
• Avoid polluting the visualization. Unnecessary data includes guessed dates and “Not Started” for subsequent steps (such as Comps or HTML) when a preceding step hasn’t even started or been planned. This reduces the impact of the visualization as a horizontal bar graph.

Acknowledgement

We’ve worked hard at EightShapes to make the doneness matrix just as much a visualization as a data-rich spreadsheet. That said, I first encountered these matrices (and the even the name “doneness matrix”) from work with a large Sapient team working on a massive telecom site redesign years ago. Thanks to them, I’ve been able to organize my own delivery — and that of larger, cross disciplinary design teams — that much better.

Originally published at www.eightshapes.com on December 23, 2010.