Well-articulated design decisions are often the single most impactful improvement design teams can do. It helps in transparency, more confident design choices, and more intentional design work.

A medieval cyber coffee with medieval computers has just lost the network connection and the patrons are angry, generated with DiffusionBee
A medieval cyber coffee with medieval computers has just lost the network connection and the patrons are angry, generated with DiffusionBee

☕ Articulating design decisions makes design work transparent

One of the most important duties design leaders have is to make sure the design team is highly intentional in their work. This means every interaction, every screen, every word, and every pixel should have a clear reason to exist the way it does. Since the design output will be also the result of collaboration and more often than not shared with a wider audience of stakeholders, there needs to be a clearly described design rationale, easily understood by everyone. That is, the design decisions need to be well articulated.

Well-articulated design decisions should stand on solid ground. I’ve introduced some of the topics to make this happen in the last few newsletter issues. Having a shared understanding in the org of what good design looks like sets up ways to evaluate design decisions. Defining design principles creates a foundation for making choices and accepting trade-offs. Stating a clear design intent sets the context, summarizes research and data insights, and defines goals for the design. These three help in developing a solid rationale.

Having a solid rationale also lets the designers be more confident in their choices. In product teams, designers often partner with more senior peers - an engineering lead or a product manager. Being partners, they need to stand as equals in their argumentation. Designers can develop their confidence in their own arguments by getting better at how they articulate their decisions.

Not having clear articulation of design choices results in a few problems. The design process will be super messy. There will be last-minute additions contradicting the established vision. The designer might feel the pressure to take each piece of feedback as a must-act-on (a lot of time they are more like ideas, and need to be treated like that). The UX across the app developed by different teams will be confusing. Past decisions will be overruled without understanding why that decision was made in the first place. Shipped products will have busy pages with too many features and busy flows with too many steps.

In the design process, the designer and the other collaborators should have alignment on why things are created in a certain way. The way to do it is to involve peers early and often, sharing research done, sharing intent, and establishing shared ownership, all with the occasional workshops to align. Design decisions should be made by combining user research, and business awareness with the design angle (hierarchy, design system, heuristics, etc). These make the design process more transparent and strengthen trust in the decisions made.

Since these decisions are made within the product team, designers should proactively seek feedback from outside, other designers, and the wider group of peers. Accepting / not accepting feedback is the first part where articulating decisions is needed, as it helps to determine whether the feedback is relevant or not. As the design progresses, there will be other presentations and sharing - this means people farther away from the immediate decisions, stakeholders - who need to understand why things happen to understand the impact. So more questions, ideas, and feedback - some of these will strengthen the design rationale, while others might weaken it up to a point where the decision needs to be reconsidered.

What well-articulated means will depend on the scope of design decisions. For macro-level decisions (like features, pages, navigation, or workflow) more detailed rationale is needed, including more collaboration, more data, connection to business strategy, and possibly validation. For micro-level decisions (like layout, buttons, copy etc.) usually less rationale is needed, often principles, heuristics, and aesthetic notes enough. Between macro and micro, the level of expected documentation also differs, macro will need a permanent description, while micro level will barely be needed to put on paper if any. The exception when micro-decisions matter are the key interactions (for example a payment button in a webshop) where details will have a lot of eyes on them and clearer articulation will be needed.

Effective articulation works the same way independently of scope. Start with describing the problem, explain options and pros and cons supported with data, and possibly address potential concerns. What changes with scope, is how these are documented, usually, micro-decisions won’t need to be documented at all, or at most as notes within the design file itself. The macro level will be part of documentation or presentations where it will be needed to share.

An important situation for articulation is presentations. This can happen in a variety of ways, including sharing an exploration on a standup, presenting for review within the design team, getting yes on a stakeholder check-in, and showing progress on an all-hands. In each of these, the designer needs to show the work that was done while highlighting the design choices made. This is where presentation skills matter and why all designers should practice.

Design leaders can help their teams in a few ways to develop better articulations. Asking whys often and getting designers to present their work (rather than the design lead presenting it) is the first step. Leaders can practice a few things to help their team:

  • Encourage clarity within the design teams, both for written and verbal communication skills.
  • Develop a design language within the organization with consistent critique practice and iteration on design principles.
  • Practice and coach for active listening when getting feedback or questions.
  • Develop a suitable way of documentation that is accessible to stakeholders.
  • Get designers to seek feedback more from outside their immediate circles.

Besides the obvious improvements in the design process, clear articulation of design choices also helps the wider strategy. Showing transparency in the design process and explaining why things were designed in a certain way makes organizations more design focused, and ultimately more user-centered.

This is a post from my newsletter, 9am26, subscribe here:

🍪 Things to snack on

Dan Saffer raises a few important points in What is a Design Decision? about what’s a design decision and what’s not. A lot of the decisions affecting the product are not design decisions and are better understood as constraints to be considered in the design work.

Chris Lee provides a simple, two-step approach to making design decisions in A framework to make great design decisions. The first step is to look at the first principles, that is to think about the whys and the intention. The second step is to look at the expected outcome and potential risk for directions to take. The article also gives a good example to illustrate this process.

Confidence is key to articulating decisions, and it can be increased by working on the narrative in our heads, as Linda Eliasen writes in Finding confidence in design decisions. The article describes two activities (Early Scary Things and Building Confidence with Data and Experience) that can be done alone or in a group to build confidence.

A huge part of articulation is presenting design solutions, and there is no better resource for that, than the Articulating Design Decisions book by Tom Greever. It provides plenty of guidance on the whys and hows and is also generally a good resource for stakeholder management.

When presenting design solutions, it often comes down to deflect some of the feedback. There are a few ways of doing this as Chris Kiess describes in Defending UX design decisions — 8 essential techniques.

Comments