How to Present a UX Audit to Stakeholders

A UX audit surfaces problems. The presentation determines whether those problems get fixed.

Most audit presentations fail not because the findings are wrong, but because they're presented as a list of complaints rather than a prioritized repair plan. Stakeholders leave feeling criticized and unclear on what to do. The framing matters as much as the findings.

Before You Build the Deck

Answer two questions before you open a slide editor:

Who is in the room? An engineering lead, a product manager, and a CEO have different tolerances for detail and different definitions of "priority." Know who you're presenting to and what they care about.

What decisions does this presentation need to drive? A UX audit that ends without a clear output — a prioritized backlog item, a design sprint commitment, a budget request — has not succeeded. Know the desired outcome before you structure the content.

Slide Structure

Slide 1: Scope and Method

One slide. What was included in the audit (which flows, which platforms, which user types), what evaluation method you used (heuristic evaluation, expert review, session recording analysis, user interviews), and the time period. This gives findings credibility and prevents scope questions from derailing the presentation.

Slide 2: Executive Summary

Three to five bullets. The most critical findings and their business implications. This slide is for stakeholders who will skim the rest — make sure they can understand the situation from this slide alone. Include the total number of issues identified, broken down by severity.

Slides 3–5: Critical Issues

Start with the highest-severity problems. For each issue:

• What the problem is — specific, observable behavior or interface failure
• Where it occurs — the specific screen, flow, or interaction
• User impact — what it costs the user (time, confusion, abandonment)
• Business impact — conversion loss, support volume, churn risk
• Screenshot or recording — visual evidence is more persuasive than text descriptions

Limit critical issues to the top 3–5. If you found 40 problems, your job is to triage them before the presentation, not during it.

Slides 6–8: Medium-Priority Issues

Same format as critical issues but briefer. Group related issues together. A navigation problem on three different screens is one systemic issue, not three separate items.

Slide 9: Issue Inventory Summary

A visual summary of all issues by category and severity. A simple table or matrix works well here. This gives stakeholders a sense of scope without requiring them to process every individual finding.

Categories might include: navigation, information architecture, form design, error handling, onboarding, empty states, mobile responsiveness, accessibility.

Slide 10: Prioritized Recommendations

The most important slide. Recommendations ordered by impact and effort. A simple 2x2 or ordered list works. Each recommendation should have:

• Clear action (redesign X, add Y, remove Z)
• Estimated effort (small/medium/large or T-shirt sizing)
• Expected impact on user experience or business metric
• Suggested owner or team

Slide 11: Quick Wins

Separately call out changes that are low-effort and high-impact. These are the items that should go into the next sprint. Specific, actionable, achievable without a major design initiative.

Slide 12: Proposed Next Steps

What happens after this meeting? Options: schedule a design sprint to address the critical issues, add specific items to the product backlog, run usability testing to validate proposed solutions, or commission a follow-up audit after fixes are implemented.

How to Frame the Findings

Tie every issue to user behavior or business outcome. "The filter controls are confusing" is weak. "Users spend an average of 45 seconds navigating the filter panel before abandoning the search — contributing to a 23% drop-off at this step" is actionable.

Avoid blame framing. "The team made poor choices on X" closes stakeholders down. "The current design creates friction for users trying to do X" opens a conversation about solutions.

Be specific about severity. Not all UX problems are equal. A stakeholder who hears "we have a lot of issues" doesn't know whether to cancel the sprint or reschedule one meeting. Use a clear severity scale (Critical, High, Medium, Low) and define each level.

Handling Pushback

"We don't have the resources to fix this." Acknowledge, then focus the conversation on the critical issues only. A single well-framed critical issue with a clear business case is more likely to get resources than a 40-item list.

"Our users haven't complained about this." Users don't always report friction — they abandon. If you have analytics data showing drop-off at the problem area, use it. If not, propose a short usability test to validate the finding.

"We have bigger priorities right now." Offer to size the quick wins. Five improvements that each take two hours of development time are easier to schedule than a three-week redesign.