As a business, design is built around deliverables: clients pay for wireframes, mockups, prototypes. As a practice, these deliverables are a means to a single end: communicating design decisions. The Agile Manifesto prefers “Working software over comprehensive documentation”, so why are designers spending time on artifacts the user will never see? Agile seeks to minimize waste, so taken to its logical extreme, all documentation is waste. That doesn’t mean documentation can (or should) be done away with entirely; it’s necessary for teams to function (particularly at scale). But it does suggest that minimizing documentation is a Good Thing, and that designers ought to be seeking to communicate design decisions with the least amount of work possible. Welcome to the Minimum Viable (Design) Deliverable.
With Apologies
We are uncovering better ways of designing experiences by doing it and helping others do it.
Through this work we have come to value design decisions as the fundamental unit of work for designers. We prefer to communicate design decisions by:
- Comments over Wireframes,
- Wireframes over Low-Res Mocks,
- Low-Res Mocks over High-Res Mocks,
- A Few DRY High-Res Mocks, Supported by a Live Styleguide, over Exhaustive High-Res Documentation
That is, while there is value in the items on the right, we value the items on the left more.
Using the Minimum Viable Deliverable
It’s easy! All you need to do is 1) socialize the idea that “less artifact can be better” among your team, and 2) always ask the question: what’s the least amount of deliverable that we need right now? Is a high-resolution mockup really the only way to communicate that design decision? Could we get away with describing the design decision in a sentence, and then using the saved time to work through other design decisions? Or to implement some of the design? Making this question a regular part of your design process can greatly speed up your team’s Think-Make-Check loop, reduce the amount of high-resolution drudge-work, and make more time for the fun part: digging into design problems—and solutions.
About the Author
