Establish precedent

Ideally, your deliverables will give you tools to decide what “good” is. That sounds simple, but it varies enormously by project. What is a “good” experience for the underwriters? This let us all decide, as a group, designers and non-designers alike, that a good experience would let users navigate by state. That it would convey that these four pieces of metadata were important. Then we could decide how we were going to make that happen. When you’re designing too much at once, it’s easy to make compromises without thinking about it too much.

Aside: Dan Klyn has a great talk about deciding what good is, and developing metrics for organizational alignment.

When you’re deciding things at this level, it actually becomes really easy. It’s much simpler to understand and explain things in words, requirements, and stories, or even conceptual diagrams, than in the fidelity of an interface.

Decision-making is really exhausting, and when you’re making dozens of decisions at once, like in a sketch or a wireframe, you’re usually doing too many things at once to really know why things are happening. Having a precedent to appeal to makes this process much much easier.

Building to complexity through precedent means that your stakeholders understand what’s happening and why. They’ll want to talk about it when you’re not around because of the shared history you’ve built. Designing one thing at a time this way gives them the tools to go explain in their own words.