Design communication is a critical skill
Build trust by explaining your designs effectively and understanding the needs of your stakeholders
As designers, we have a unique ability to communicate through visual artifacts. Wireframes, flow diagrams, and mock-ups are all useful tools that help us share ideas with stakeholders. Since creating these is part of our day-to-day work, it’s easy for designers to get caught up in the pursuit of perfect design artifacts.
The reality is, these artifacts are a means to an end. They let us express how we’d go about solving a given problem. But customers don’t judge us on the quality of the wireframes in our Figma files. They judge us on the quality of the end product they interact with. Until design work is shipped into production, value is never realized.
This is why one of the most important skills for designers is the ability to communicate design intent. We need to help stakeholders understand why a design decision provides the best possible solution to a problem. This is how we build trust with our stakeholders and ultimately go from artifact to reality.
Improving stakeholder communication has been an ongoing focus for me throughout my time at Shopify. This article was inspired by some takeaways from Articulating Design Decisions by Tom Greever, and some learnings in the field along the way. My hope is impart some knowledge to other designers who’ve faced challenges when trying to communicate design intent.
Part 1: Design communication foundations
Communication allows designers to discuss problems, brainstorm solutions, and share ideas. Effective communication is ultimately what enables designers to work with stakeholders and other disciplines to bring ideas to life. What constitutes effective communication varies with team dynamics and contexts, but I’ve found these four communication foundations hold true.
Product over process
First and foremost, always orient your sharing towards the product and not the process used to come to a conclusion. Most of your stakeholders likely don’t care about methods and artifacts; they care about how your decisions directly impact the product. You should always be prepared to show your work and speak to how you arrived at a conclusion, but it should not be the center of your message.
Explain the problems
Set the stage for what you’re sharing by starting with the problems. Never assume that stakeholders have as much context as you do. If you’re proposing solutions to a problem, then you’ve also been close to it. This means it’s your responsibility to develop a shared understanding for everyone in the room before getting into any solutions.
Link solutions to the problems
As you present your solutions, explain how they’re directly related to the stated problems. To effectively create this link, you need an awareness of the decisions you made along the way. One of the best ways to capture these decisions is to write them down so that you move your unconscious thoughts to a tangible form and preserve a history of your thinking.
One exercise that helps with linking solutions to problems is describing a design using only words. This exercise is best used proactively before designing anything, but can also be used retroactively to record rationale.
It’s pretty simple — you write out the problem, then write out potential solutions to that problem. See example below.
Keep in mind this is a thinking tool. Your end goal is to communicate design intent to stakeholders, so describing solutions in sentences is intended to better equip you for this task. You may also be able to communicate the same intent with a sketch. Whatever the method you use, the goal is to turn your thought process into something real and shareable.
Bonus: Consider doing this exercise with your team to collaborate and combine ideas early in low fidelity. Co-creating with your team creates a shared sense of buy-in for the solution, while preventing you from wasting your effort wireframing solutions that may not be practical or feasible.
Explain why solutions matter
It’s not enough to explain the rationale behind your decisions and link them to problems. You also need to be able to speak to why they matter. Stakeholders often need to understand the why so that they understand the value of what you’re proposing. One exercise that helps with this is documenting how a solution will affect users. With every decision you make, ask yourself — “how will this affect the user?”
The point of this exercise is to move your thoughts to a tangible form and preserve the history of your thinking. Ideally, it would be best to do this for all alternative design paths you explore so you can speak to why one solution is better than others. Having done all of this work in advance, you’ll be better equipped to defend decisions when responding to stakeholder concerns about your solutions.
These foundations should underpin all design presentations, regardless of who you’re sharing with. Of course, depending on stakeholder context and your specific project, there may be variations in how or what you’re sharing, but generally these four foundations should hold true across all cases. With these foundations in mind, it’s time to think about the stakeholder landscape.
Part 2: Understanding the stakeholder landscape
Many kinds of stakeholders influence our projects, and they often have very diverse priorities. Ahead of sharing your work, you should do your best to understand stakeholder priorities and tailor your sharing in a way that resonates with them. While every project has many different stakeholders, let’s assume there are three main groups.
- Your immediate team
- External stakeholders
- Leads and executives
Thinking about these groups in concentric circles can help you visualize the frequency you’ll interact with these groups, and how they may care about different things depending on which group they fall into. Depending on where the person sits in relation to you, it can be difficult to know what aspects of your work are important to them. Your focus should be to identify these people and seek to understand them as best as you can.
Your team
These are the people you interact with every day. This team likely includes developers, product managers, content designers, and other designers — but of course can include other disciplines across the organization.
In general, your team is the best source of people that can help you on your project since there are daily opportunities to collaborate. The more time you spend collaborating, describing solutions, communicating value, and establishing a shared vocabulary, the better off you’ll be at shipping real value. Part of what helps with this collaboration is understanding the priorities of your peers.
This is a simple cheat sheet I use to remind myself of discipline specific priorities.
Developers: You should always empathize with developers and their perspectives on a project. As builders, they’re constantly bombarded with a backlog of bugs and enhancements, while also trying to build out new features from the roadmap. It’s important to connect with developers early and often so that you can grow an understanding of the technical effort involved in implementing different solutions. This will help you get rid of the solutions that are overly complex relative to the value they provide.
When communicating design intent, your job is to help them understand user problems, the value that different solutions offer, and how that value makes the effort worth it.
Product managers: Similar to designers, product managers have a deep understanding of the problem space and the customers. They also ensure that projects are mapped to product objectives and help teams manage scope so that projects stay on track, on budget, and are delivered on time.
When communicating design intent to product managers, help them understand where you’re at in the design process, and alert them about concerns or changes to project scope as soon as possible.
Content designers: Content designers ensure that products have a logical information architecture that helps users accomplish a task by prioritizing the right info at the right time, and organizing it in a way that matches existing mental models. They also help teams develop a shared vocabulary and understanding of abstract concepts, and ensure products communicate these concepts consistently so that users have a consistent experience. It is important to connect with content designers early and often to grow a collective understanding of the problem space and user mental models. This will help you collaboratively craft the right information architecture and hierarchy across the product.
When communicating design intent to content designers, focus on helping them understand insights from user research, how your decisions match or fit into existing content models, how solutions are consistent with other areas of the product, and how designs reduce cognitive load for users.
External stakeholders
This group is likely less involved in your day-to-day decision making, but they can still help or hurt your efforts. For example, this may be other project teams with similar roadmaps, business stakeholders, or internal clients that use what you’re designing — the list varies and so do the things that they value. In many cases, it is valuable to get support from these parties, since they may have the ear of your leads and execs and can advocate for your solutions.
It’s hard to predict what these relationships will look like early in a project. Oftentimes, knowledge of which additional parties to involve is formed while you’re in the weeds. Rely on relationship building and default to design communication foundations when presenting design intent to them. Over time, you’ll grow an understanding of their priorities and will learn when to include them and what to focus.
Leads and executives
Finally, leads and executives are the people who have influence over your project because you need their approval. The difficult part about understanding their priorities is that you may not meet with them enough to gain that perspective. Being in leadership roles, they often span multiple teams and have packed calendars. You have to empathize with the fact that they are frequently switching contexts and may not have the mental bandwidth to devote to nitty-gritty project details.
If you’re presenting to them, it is your responsibility to bring them up to speed as quickly as possible, present solutions, and solicit their feedback. Be tactful in the communication of your design intent and focus on the things that are the most important to them. To earn their trust, you need to demonstrate that you’ve thought extensively about the problem and have made decisions that align with their vision for the product or organization.
Design communication foundations give you some basic principles to keep top of mind when sharing design work with any audience. Of course, these are foundations — you can build on top of these and adapt the list to include other communication principles.
Understanding the stakeholder landscape gives some guidance on splitting up your stakeholders into concentric circles, and some things to consider when sharing design work with different disciplines.
