Often we can explain them in technical terms, but we aren’t as good at defending and validating them to non-technical stakeholders. This is an important skill and we need to do this quickly and clearly in order to get buy-in.
I’ve been working on a framework to do UX Audits using AI. It guides you through presenting design decisions clearly for mixed audiences of designers, business analysts, and developers. Let me know what you think!
The Framework
Step 1: Establish Your Research Context
Ground your audience in the user research that informs your decisions. Include key behavioural patterns, user needs, pain points, and how different segments interact with your product. This research foundation justifies all subsequent design decisions.
Nothing is more convincing for making design changes than users either 1. not using a feature or 2. being frustrated by it, finding it too difficult to use.
Lastly, connect these findings to achievable results and data. Will it increase revenue by 25%? Will it keep key customers happy? Will making this change save us time in the long run?
Step 2: Frame the Design Question
Clearly articulate the specific design challenge. Make it concrete (not “improve navigation” but “relocate the sharing functionality”), connected to a user goal, and framed as a problem to solve.
You’re starting with an inkling of what to do, and you can’t go rogue. Not everyone has to agree with the change, but the more people understand it the better the chance is you can act.
A UX Audit needs to be tight and focused, and should relate to an existing design, not a fresh, new design. For that you want to do qualitative user testing and build a base of understanding first before you do a UX Audit.
This helps your audience stay focused. You don’t want them changing button colours, you want them to be in sync with your findings and design decisions on a UX level. Your button colours should already be decided, in fact, due to your amazing design system!
Step 3: Explain the Reason for Change
Connect your proposed change to research using established design principles. Reference specific Laws of UX that support the change and link them to your findings. Keep this concise—2 to 4 sentences maximum.
Critical adaptation: If stakeholders are non-technical, replace formal UX laws with plain language. Instead of “Fitts’s Law,” explain that “placing frequently used controls closer to where users are looking reduces time and effort.”
Many think they understand human psychology better than they do, hence the “I’ll know it when I see it” design approach we often hear. Help your stakeholders understand why this is, and this will go much smoother.
You want better, clearer feedback. This is the way.
Step 4: Define Your Terms
Create a simple two-column glossary table for any technical terms or UX laws you’ve referenced:
| Term | Definition |
| Technical term | Plain language explanation |
This ensures everyone can follow your reasoning. You want your audience to weight the different options, not be confused by them. Context is everything with this exercise.
Step 5: Present Options as a Comparison Table
Show you’ve considered alternatives with a structured comparison:
| Option | Pros | Cons |
| Option 1 | Benefit | Drawback |
| Option 2 (preferred) | Benefit | Drawback |
| Option 3 | Benefit | Drawback |
| Option 4 | Benefit | Drawback |
Keep each cell concise with bullet points or short phrases. It’s important that your audience understands not only your thinking but also how to decide between the options. Highlight which one is preferred and explain why.
Since I’m the designer I can be relied on to have an opinion! As with any negotiation you come at this with equal parts expertise and curiosity. Your audience might just come up with great ideas as a result of this interaction. Let them come.
Step 6: Elaborate on Each Option
Provide additional detail for each option covering implementation considerations, edge cases, technical feasibility, and any dependencies or risks.
Hopefully you are always considering the “Unhappy Path” in your designs. Things don’t always go to plan! This is part of it: What does it mean if we pick an option? Does this capability currently exist in the system? If not, how much effort would be required to implement it?
You want to focus on effort vs reward here. If an option has high effort/low reward, scrap it unless users are calling out for it and will leave if you don’t do it (pretty rare but it does happen).
Step 7: Summarise Your Recommendation
State which option you prefer, reference the UX principles (or plain language equivalent) supporting this choice, and connect back to your research. Three sentences max!
Don’t oversell your findings. This is the best way to cause confusion and to stop you from getting any sort of clear decision. With this framework your goal is to get in sync on decisions.
Why This Works
This framework builds credibility through research, demonstrates rigour by showing multiple options, enables informed decisions through clear comparisons, and accommodates diverse audiences through accessible language.
When you teach your stakeholders and include them in the process, design becomes collaborative rather than mysterious and combative.
Don’t be afraid to lean on everyone’s expertise. This is how a good company culture is built.
Key Takeaways
- Start with research, not solutions
- Show your working through options analysis
- Keep it concise at every step
- Adapt terminology to your audience’s fluency
- End decisively with a clear recommendation
- Be the Designer, and also a Facilitator
