Articulating Design Rationale
Why it’s easier to understand this skill in terms of practical application.
Almost every UX Designer job listing includes some form of “articulate design rationale” as a required skill, and that requirement is there for good reason. It’s also a really vague description that offers a readily accessible, but perhaps naive, interpretation of what it means to do this. I’ve developed a more useful understanding of this phrase after practicing the skill for a few years, and I want to ground the phrase in practical application.
My naive understanding of “articulate” was “to tell or explain”, but I now know that it’s more nuanced than that. Articulation is more like a segment in an ongoing conversation than it is like a lone person’s monologue. If you’ve ever read a line and gone, “that’s what I was thinking but couldn’t express!”, you’ve seen something articulated well. The author’s voice clarified ideas you couldn’t quite decipher.
This is your goal for your audience when articulating a design rationale: describe the design in a way that clarifies things that haven’t yet been made clear, helping them to express what they’re thinking.
You want them to walk away not just knowing more, but understanding more, and more clearly. You’re not simply telling them about what you did; you’re facilitating a conversation about what is being solved and how that’s being done. This is the difference between explanation and articulation; articulation supports the audience’s thinking while explanation only serves to demonstrate yours.
Next is the question of what problem is being solved and how that’s being done, otherwise known as the “design”. The design is a series of questions and answers. Communicating it involves specifying which questions were asked and what answers are being given. Think of your visual artifacts like Jeopardy! questions where you’re the player. If the answer is “organize this information chronologically by default”, what was the question asked? Share that question with your audience as it relates to the things they already know about the project. For example, I might share with an audience member that “users wanted to know when to take which actions in the target flow, and the majority interviewed described the flow chronologically”. Organizing the actions chronologically is the answer and “which action do they take next” is the question. There are usually lots of questions that inform a design; I focus on the ones that most heavily influenced the design and take audience questions on the rest. The audience in this example determined the target process, and so the connection is made for them between user needs, business needs, and design solution. They walk away knowing both the design decision that was made and the context that lead to it because you communicated the design clearly. This shared understanding is practical for collaborative product design.
This example also describes how the users understood the target flow, which is the rationale behind this design decision. It’s straightforward here: users revealed a chronology-based mental model of the process being designed for in interviews. As I show the organization visually, I describe the findings that lead to this choice of organization. This is the “rationale” that motivates the design. Sometimes the rationale is more complex. In those cases, it’s important to communicate the different aspects of the rationale and how they relate to each other to form a cohesive motivation for a particular design. This is also why it’s important to stay humble, curious, and ready to iterate. As the rationale evolves with new information, you’ll iterate on the design to reflect that. Communicating the rationale as it evolves keeps the team aligned, which makes for smoother collaboration and a more robust solution.
Presenting that next iteration towards the solution will require “articulating the design rationale” once again. But this time, you’ve practiced this skill on this project at least once. You know who you’re in conversation with and can articulate to them specifically. You’ve defined your problem and solution space for the design more clearly. You’ve made updates to the idea based on the most recent information, which has increased your understanding of the design rationale. With some examples of these concepts grounding the ideas back to experience, hopefully this skill isn’t quite so ambiguous anymore.
