Articulating Design Decisions (for . .) (Tom Greever)（Z-Library）

Page 1

(This page has no text content)

Page 2

Articulating Design Decisions THIRD EDITION Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience in the Age of AI Tom Greever

Page 3

Articulating Design Decisions by Tom Greever Copyright © 2026 Tom Greever. All rights reserved. Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: David Michelson Development Editor: Angela Rufino Production Editor: Beth Kelly Interior Designer: David Futato Interior Illustrator: Kate Dullea January 2027: Third Edition Revision History for the Early Release 2026-04-27: First Release See https://oreilly.com/catalog/errata.csp?isbn=9798341673908 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Articulating Design Decisions, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have

Page 4

used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 979-8-341-67386-1 [LSI]

Page 5

Brief Table of Contents (Not Yet Final) 1 Great Designers Are Great Communicators - available 2 Becoming a Great Designer - available 3 Skills for Being Articulate - unavailable 4 Stakeholders are People Too - unavailable

Page 6

Chapter 1. Great Designers Are Great Communicators A NOTE FOR EARLY RELEASE READERS With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles. This will be the 1st chapter of the final book. The GitHub repo will be made active later on. If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at @oreilly.com. Have you ever had to make changes to your design work you disagreed with? Me too! It’s not easy to talk about design, especially with people who aren’t designers. Yet, the ability to effectively articulate design decisions is critical to the success of any project, because the most articulate person usually wins. In fact, I would say that the difference between a good designer and a great designer is in their ability to not only solve problems with design, but to also articulate how their solution solves it in a way that’s compelling, fosters agreement, and gets the support needed to move forward. That’s what this book is about: getting support for your design decisions. Lots of people are involved in our design process. People from all over the organization see the value of creating a great user experience (UX) and will tell you how they think it should look and work. Because the user experience has a long-term effect on the product, everyone is going to have an opinion. The good news? You’re a very popular person!

Page 7

The Big Important Meeting Several years ago, I had to catch a late flight to San Francisco for a meeting. It was one of those Big Important Meetings: a dozen people from different areas of the company were all presenting designs to the CEO. Vice presidents, directors, product owners, engineers, and designers had all planned a three-hour event just to get this one executive’s support! We had spent the better part of two weeks planning, rehearsing, and making slides. There were meetings about the meeting and late nights getting everything just right. We traveled across the country and then spent a whole day in a conference room. All of this just to get support for our design work. What struck me about this whole thing was the amount of effort that was going into just communicating design ideas to one person. The amount of time the designers spent actually creating the mockups was trivial compared to the time and energy that went into finding the best way of communicating them. Communicating about the designs was more important than the designs themselves. Not every team or meeting is like this, but the principle is still the same. The way we talk about design work with stakeholders is critical to the success of our projects. It might be even more important than the design itself. Design Is Subjective...Sort Of When I interview designers for a role on my team, I always ask them, “What makes a good design good?” The way people answer this question tells me a lot about how they think about design and UX. Most of the answers are predictable, but they often speak to an aesthetic – a level of subjectivity that not everyone will agree on. One of my favorites was “when you can’t remove anything else.” While I get that there can be fuzzy thinking around why we make certain decisions in design, in the context of a business, many of those explanations won’t hold up to scrutiny.

Page 8

The truth is, all design is subjective. What one person likes, another person hates. What seems obvious to me might not be obvious to you. What works in one context could fail miserably in another. This is why design is such a difficult thing to talk about, especially with people who aren’t designers. There is little common understanding of what design is or should be. Too Many Cooks It would be easy to create designs if it weren’t for the fact that other people on the project might disagree with our decisions. Actually, they will! There are a lot of people who may know little or nothing about design, yet who have the authority to oversee and dictate our design practice. They have a vested interest in our work, but they likely don’t have the same depth of knowledge in design or technology that we do. It turns out that in the world of making design decisions, other people are our biggest problem! Ironically, these people will often admit that they aren’t the experts. They know that they don’t know, yet they’ll still insist their ideas and opinions are right. It’s weird. People will readily admit they are not good at our jobs, yet insist on making changes against our recommendations. They’ll say we are the experts and then frequently overrule us. It can be incredibly discouraging and confusing, but the problem may not lie entirely with them. This is what we need to figure out. Everyone Is a Designer! To top it all off, anyone can design anything these days using their favorite AI tools. In the olden days, we were somewhat insulated from the stakeholder-as-designer conundrum because the barrier to entry was specialized design tool knowledge. Sure, stakeholders have always given us sketches, used PowerPoint as a design tool, or just links to other designs they liked. But in those cases, they knew these weren’t production-ready solutions. Now, the outputs from generative AI look an awful lot like

Page 9

something they could ship right away. And the temptation is almost too great. “Why can’t you just use this?” Regardless of their access to design tools, the truth is that everyone knows good design when they see it, even if they can’t create it or explain it. Consider this: I may not know how to play an instrument, but I can decide what music I like (and don’t like). Of course people have different preferences, but we’re all able to choose music we like, regardless of whether we know how to reproduce those sounds ourselves. The same is true for design, even if what our stakeholders like isn’t the goal.

Page 10

(This page has no text content)

Page 11

Figure 1-1. Andy Zelman, Skeleton Claw Comics. (Used with permission: http://skeletonclaw.com) There Is No U or X in Team It gets even more complicated when you add more people, more roles, and more possible outputs. We want to have healthy collaboration, but it’s hard. Collaboration seems like it should be the essence of great design work: different opinions coming together to uncover the best possible solution. We expect to passionately debate possibilities, ultimately leading to a collaborative discussion and an ideal solution that no one could have thought of on their own. Teamwork! In reality, it gets far more complicated when we disagree with one another. When we disagree, we tend to become defensive. When we become defensive, we fail to focus on the real issues. The meeting ends, not with collaboration, but with grumbling compromise and, often, a crippled user experience. Meetings like this can easily turn into design-by-committee. Everyone has an idea. One suggestion evolves into something else. That idea changes the scope. Unchecked, the conversation can spiral out of control into a collection of well-intentioned tweaks that collectively ruin the experience. The thing we came together to accomplish has been muddied by groupthink and mob mentality. Remember, teamwork always ends with work. THE CEO BUTTON Because of this, we see things like the CEO button. The CEO button is an unusual or otherwise unexpected request from an executive to add a feature that completely destroys the balance of a project and undermines the very purpose of a designer’s existence. Maybe you don’t work directly with the CEO, but we’ve all had this experience. It’s funny because it’s true. You might spend weeks or months building the best possible app. Your team has poured in all the best

Page 12

practices and you’ve done usability testing to prove it works. And yet, one executive can come in and blow up the whole thing. We want to avoid this. You may have heard this referred to as the HiPPO, which stands for the Highest Paid Person’s Opinion. Another common reference is the “swoop and poop” where one person swoops in and makes a huge mess. The sentiment is real, but for reasons you’ll see in subsequent chapters, I’m a big fan of staying positive and believing the best about these folks. Comparing them to large, fat animals who crap all over our work is likely not the healthiest way to approach the relationship, so I’ve renamed it for this reason Communication Is the Job The good news is that it doesn’t have to be this way. It’s possible to avoid the disruption and compromise that happens so frequently in organizational design through better communication with our stakeholders. I’ve found that the majority of issues or concerns that our stakeholders bring to our attention are often just a matter of misunderstanding or miscommunication. The way that we talk to them about our designs is the key to ensuring that we always end up with the best possible user experience. It makes sense when you think about it. All human relationships are really nothing more than a series of understandings and misunderstandings. We don’t have control over how other people understand us. Everyone brings their past experiences into our conversations on a daily basis. We do, however, have control over how we communicate with them in an attempt to influence those understandings. The way that we talk to people and the things we say will have a huge impact on their response.

Page 13

(This page has no text content)

Page 14

Figure 1-2. I know you were told your job was to design stuff, but it’s not. Communication is the job! GOOD COMMUNICATORS WIN Overall, being a better communicator will give you more opportunities. As a design leader, the most common feedback I hear about my own team has more to do with the way they set expectations, follow up, and manage the relationships in the organization. When I am coaching people or helping them create a path for promotion, it almost never involves their design skill. Instead, it’s usually about how they can increase their influence and impact across teams. In that way, your career will improve if you’re a good communicator. In fact, that may be all it takes to set yourself apart from other designers— even designers who might be more talented than you. Very simply: good communicators win. Being Articulate Means Success It’s more than just using words, though. We have to turn those words into something that will enact change or compel people to support our decisions. We have to explain why we did what we did in a way that is compelling and convincing. It’s about being articulate. The key to being articulate is to understand both the message you want to communicate and the response you want in return. If you can learn to craft your messages in such a way that they yield the desired response, you’ll find that you’re much more successful at getting support for your decisions. THE BEST IDEAS (DON’T ALWAYS) WIN It might seem like the best ideas should always win, or that great design should speak for itself, but that’s not usually how it goes. Unfortunately, the best ideas get stuffed into a series of meetings where competing needs vie for attention. The person who can convince others that they’re right is the

Page 15

one who gets their way. Your design solution might be amazing, but an assertive and well-spoken colleague is more likely to get support if they can convince the boss that they’re right. Designers lacking the ability to explain why they did what they did end up on the losing side of the argument, forced to make changes they disagree with simply because they were unable to fend them off. This is not to say that the stakeholder relationship is adversarial. In fact, these discussions can feel like good, solid teamwork. But the inability to speak up and articulate your side will often land you in the position of making changes that won’t yield the best results. Alternately, being articulate about our designs: Imparts intelligence You’re smart, you know what you’re talking about, you have expertise in this area, and you can be trusted with the solution. Demonstrates intentionality You’ve thought about it, pursued it, and are logical in your approach. This isn’t just a random idea; there is purpose and focus. Expresses confidence You know what needs to be done and how to make it happen. Having a solid argument shows conviction and clarity. Shows respect You value people’s input and time enough that you’re well prepared. You’re not wasting time or disregarding others. Given these, our job is to articulate our decisions in a way that explains our reasoning while framing it in a way that appeals to the needs and

Page 16

expectations of our stakeholders. When those two things come together, we build trust — showing our expertise through both what we say and how we say it. In the next chapter, we’re going to answer a deceptively simple question: what makes a design successful? At first glance, it seems obvious. Solve the problem. Make it work for users. Done. But if you’ve been in this field for any amount of time, you already know that’s not how it plays out. Designs don’t succeed or fail in isolation. They succeed or fail in conversations, in meetings, and in the way we explain them to other people. Which means being right isn’t enough. And that’s exactly why we need to become better at something most designers were never taught.

Page 17

Chapter 2. Becoming a Great Designer A NOTE FOR EARLY RELEASE READERS With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles. This will be the 2nd chapter of the final book. The GitHub repo will be made active later on. If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at @oreilly.com. Let’s look at what makes a design successful, because that will form the basis for how we communicate about it. Remember the question I ask in interviews: What makes a good design good? There are many different ways we could answer this, but when it comes to creating the user experience (UX), a design is really only good if it solves a problem. Usually, we are trying to solve problems for the business by accomplishing a goal or improving a metric. But, if we’re also practicing user-centered design, we must make our designs effective for the people who will use them. Both of these are fairly well understood in the design community. However, one thing that we often forget in the process is that there are other people involved who have influence over our project. It’s not enough to simply solve the problem for the business and users; we have to get the support of other people in the organization in order to move forward. So, if we take that into account, there are three things that every design needs to be successful:

Page 18

It solves a problem It’s effective for users It’s supported by everyone The difference between a good designer and a great designer is the ability to not only solve the problem, but also to articulate how the design solves it in a way that is compelling and earns support. If you can do that, you’re a great designer. Let’s look at each one in more detail. SOLVES A PROBLEM Of all the things we’re trying to accomplish with our work, we have to solve problems: business goals, engagement, conversion, interaction, and feedback. Whatever the problem is, our job is to find a solution and measure its success. We will know we’ve done a good job by looking at the impact our decisions had on the problem we set out to solve. Ideally, you and your team already have goals, objectives and key results (OKRs), or key performance indicators (KPIs). At a minimum, you need a well-formed problem statement that you can work from. If not, create them yourself or work with stakeholders to define them. Without a measuring stick, everything becomes opinion, and that’s where projects stall. You need something concrete to point to if you want to move forward. So figure out what matters most - impressions, conversions, sign-ups - pick one or two measurable areas to improve, and write them down. Use those goals to guide your work and anchor your conversations. The Awareness Gap While we’re certainly skilled at approaching these problems to find creative solutions, we’re not always in tune with our own thought processes to help others understand why we did what we did. It is difficult to know why we made certain design decisions because a lot of our thinking is the output

Page 19

from years of experience and education. Some will call it intuition, but I’m convinced that good intuition is mainly a reflection of our past experience. Because of this, we may not be consciously aware of why we did what we did. This opacity is even more pronounced when using AI-generated designs. Just like our own experience-driven intuition, AI-decision making is based on pattern recognition from training data. You might have to ask the AI to justify and explain its decisions the same way a stakeholder would expect of us. In either case, the practice of solving problems with design must also be accompanied by an awareness that helps us explain our decisions to others. Therefore, when you’re working on a design, you need to make yourself consciously aware of every decision and why it matters. You need to be constantly asking yourself, “What problem am I trying to solve with this?” While Chapter 3 will review some of the most common design principles that drive a lot of decision making, and Chapter 7 will list some of the most common ways I describe my own solutions, your immediate task is simply to remain aware of the changes you’re making. These unconscious choices hold the key to explaining your designs to others and ensuring that your expert perspective remains at the center of the final decision process. Documenting Your Thought Process The best approach is to write them down. There is something about moving your unconscious thought to a more tangible form that makes it easier to understand. Do whatever you need to do to document your own thought process. This documentation can also serve as an input for AI tools, helping you evaluate your thinking, create new alternatives, or identify gaps. Since you have measurable problems you’re trying to solve, you can write down the problem and then list your solutions next to it. I personally use a notes app, while others prefer the tactile experience of handwriting in a journal. You can even use AI to evaluate your design and help you uncover your own thinking. The method you use for writing down your thinking

Page 20

doesn’t matter. The point is to get you thinking about your decisions in concrete ways. Examples of Problem-Based Solutions Here are a few examples of how I document solutions based on specific user problems: