Articulating design decisions
#65: About making thoughtful decisions and defending design rationale
Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community. Join 2,200+ readers and grow as a UX and product designer with us!
Articulating design decisions
Countless times, I’ve heard stories of designers who, when asked why they did what they did in their projects, answered with “I don’t know” or “it just looked good this way.” If that ever happened to you, this article will help you skill up in defending your design rationale and speaking about your designs with confidence, authority, and competence.
In other words, you’ll start sounding like a design expert, and your design decisions will defend themselves.
Everything begins with making the right tactical calls while keeping the strategy in mind, rather than randomly throwing design system components on the canvas. There are a few core elements of preparing yourself for a big meeting with stakeholders who can be asking difficult questions:
Following the design process smartly
Backing decisions with evidence
Exposing yourself to feedback often
Speaking the language of the audience
Let’s look at each one in detail.
Following the design process smartly
I may sound like a broken record, but there’s no single design process that fits all projects, and you should already know that. That’s why knowing what you’re doing to solve a design problem and being able to explain it later to stakeholders and colleagues is all about adapting the design process to the particular project.
If you’re a recent uni grad or just finished a design bootcamp, you may believe that the process that you were taught has to be replicated and followed strictly in every single project, no matter what – that’s untrue. It’s rather the first step to not having the correct answers about your decision-making.
Just imagine this conversation:
- Why did you do that?
- This is the process I was taught, so I’m following it.
Your stakeholder probably won’t be happy to hear this.
So, how do you not forget about the processes, make smart decisions, and not lose your soul in the meantime?
✅ Do more of this:
Adapt the process to your project. Make a plan in the very beginning. List the core questions you need to answer to cut through uncertainty, reduce the level of ambiguity, and move the needle.
Be able to jump on ideation and fail quickly. We are currently living in an era of big shift. Jumping into the solutions space is now much cheaper than it used to be and opens up new ways of discovering insights.
Document your steps and decisions. It will be much easier to track back why you did what you did when the project is long and extensive, and some details are already forgotten. When a stakeholder asks you a tough question, you can recall your notes and say, “Research suggested to use this variant over others we tested”, or “This is the standard way of building a form that users are familiar with by using other tools.”
❌ And avoid doing this:
If you are working on a project for an existing and quite mature product that people already use, you’ll not need to create personas or an empathy map – you most likely already have this figured out.
An extensive research when working on a highly ambiguous project? Yes, but only to the point when you're ready to propose a potential solution to gather more insights quicker and have a conversation about a tangible thing.
Writing user stories and shaping MVP? Yes, but only when a solution is validated with the customers and users, stakeholders are more or less aligned, and the engineering team is involved in discussing the scope.
Backing decisions with evidence
It shouldn’t be surprising to anyone if I tell you that data is the ultimate argument when discussing design with tough stakeholders. If you have ever found yourself in a room with a stakeholder asking difficult questions about certain decisions made in the design, and you struggled to find a good answer, the reason was most likely a lack of data.
While intuition is extremely important, it can only be trained with experience. You probably shouldn’t trust your gut feeling every time when you've just started out in your career in design. Once you do more projects, talk to hundreds of users, ship useful features, and gain more experience, you’ll get better at making some decisions with zero or little data.
✅ However, if you are starting your career or the project you’re working on has many unknowns and requires gathering data to move the needle, here’s what you can do:
Always start with desk research. Look out for information online. Try the competitor’s product. Use AI to help you cut through market reports or scientific papers.
Cooperate with your product manager, internal researchers, and data analytics specialists. Look for the trends in your product analytics data. Ask account managers and customer support folks to hear what the voice of customers is about.
If you have the internal capability to run research with real users or a budget to hire an agency, create a research plan and use the time and money wisely. Avoid doing research just for the sake of research.
Once you create a mockup or prototype, test it with users or conduct guerrilla tests with your colleagues to verify that what you have created is usable, intuitive, and easy to use. Track metrics such as Error Rate, Time Spent on Task, or Success Rate, and use these numbers in conversations with stakeholders.
Exposing yourself to feedback often
Have you ever locked yourself down for a few weeks in your safe place and returned with a beautiful and almost perfect prototype, only to find that after presenting it to the product team and stakeholders, you needed to redo most of it, and you feel like you've lost weeks of work? I’ve done this a couple of times in my early days, and I know it can be super discouraging.
A much better approach is to expose your work to feedback often. Feedback is a gift, and it has to be treated like one. Feedback allows us to grow as designers and make our products better.
✅ Here’s how to make this work in practice:
Schedule a recurring design feedback session with your product team and show them what you’re working on regularly. This will help you probe if you’re moving in the right direction.
If there are other designers in your organization but you don’t really cooperate on projects, ask them for feedback, too. Design crits are super useful – hearing from other designers is not much less important than hearing from customers and users.
Get prepared for a big meeting with stakeholders. After a few initial rounds of feedback with your colleagues and product team members, schedule a call with stakeholders. Record a short loom about what you’re going to present in a couple of days, so they are not totally surprised when you hit the present button. Write a short spec and attach it to the invitation, which will inform them what this is all about and what is expected from them.
A small caveat or a prerequisite, if you will, is needed to make good use of feedback: you must detach yourself emotionally from the work you’re doing.
You are not your work.
The best thing to do is to stop thinking about your work as something precious that you spend so much time and energy on. Otherwise, every little piece of feedback or change request will hurt you to the core, and you’ll cry a river after every meeting with opinionated stakeholders.
Speaking the language of the audience
Imagine this. You walk into a room full of C-level executives, domain experts, and sales reps. You are going to make a big presentation of a new shiny functionality that you have been exploring in the last couple of months. The project is still in the discovery phase, and not a single line of code has yet been pushed. Market has been probed, and you’ve spoken to customers, so you know their needs, and you’re pretty sure that this is the way. The goal is to get a seal of approval and make the audience excited.
❌ What is the worst thing to do during this presentation?
Talking about the specifics of the user flow and visual attributes of the proposed solution. This would be super exciting for other designers when presented on a design crit kind of meeting, but not when demonstrated to the business people.
Speaking in design language and using design-specific acronyms that stakeholders won’t understand.
Neglecting business priorities and failing to connect your solution to KPIs.
✅ Instead, do more of this:
Explain the identified user need and market opportunity, and connect it to the presented solution. Get them excited by saying that this functionality will improve a specific business metric, such as retention, stickiness, or ARR, by addressing the identified opportunity.
Use clear language that stakeholders and product experts will understand and care about. Demonstrate how your design impacts business goals, priorities, and KPIs.
Try to quantify the value of the change that your project is going to make. For example, if it automates a process, calculate beforehand how much money your solution may save the company.
Join the challenge!
Hopefully, the tips I covered in this article will help you grow and make your big presentations less stressful. Bear in mind that it’s not an overnight change. There are lots of components that will click someday and eventually make everything smoother, but in the meantime, starting today, try to learn and implement small improvements.
My friend, Miranda Slayter from
has prepared something that will help you make your first step toward the journey of becoming a designer who articulates their decisions like a pro.Why Before UI is an 8-week design challenge focused on getting designers ready to go beyond pixels and design for real change. The challenge is free and starts in a couple of weeks.
I will be judging one of the prompts in the seventh week of the challenge – expect an article in November covering my solution for the given prompt!
Support our work
If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.
Follow us on other channels
Arek’s LinkedIn, Instagram, TikTok, and Twitter (X).
Mateusz’s LinkedIn and Twitter (X).