Present design work effectively to non-technical stakeholders — structure design reviews, handle conflicting feedback, build consensus without design-by-committee, and frame technical constraints in business terms.
Design stakeholders — executives, product managers, marketing, legal — have opinions about design but do not have design expertise. Without structure, stakeholder reviews become 'design by committee' where the final product reflects the preferences of the most vocal person rather than user needs and design principles.
Effective stakeholder communication starts with framing: what problem are we solving, who is the user, and what does success look like? When stakeholders share a problem frame, their feedback becomes more focused and more useful. When they see only the visual without the context, they critique aesthetics.
This lesson covers how to present design decisions, handle conflicting feedback, and frame technical constraints in language stakeholders understand.
The most effective design presentation structure leads with context, not with the design. Stakeholders who understand the problem and user goals before seeing the design give more relevant feedback.
Presentation structure:
11. Context (2 min)
2 - Who is the user?
3 - What problem are we solving?
4 - What does success look like?
5 'We are designing for learners who have just finished their first course
6 and feel lost about what to learn next. Success means they enroll in
7 a second course within 7 days.'
8
92. Constraints (1 min)
10 - What are we NOT solving today?
11 - What constraints are we working within?
12 'We are focused on the course detail page — not the home page or search.
13 We have a 2-week implementation timeline and mobile-first constraint.'
14
153. Design presentation (10-15 min)
16 - Show the design
17 - Explain decisions as you walk through it
18 - Connect each decision to the user goal
19 'We kept the enrollment CTA above the fold because users who are ready
20 to enroll should not need to scroll to act on that intent.'
21
224. Feedback invitation (10 min)
23 - Ask specific questions, not open-ended ones
24 Bad: 'Any thoughts?' → Opens aesthetic debate
25 Good: 'Does the progress visualization help returning learners?
26 Do you feel confident about the enrollment flow?'
27
285. Decision log (2 min)
29 - Briefly note alternatives you considered
30 'We considered a horizontal course carousel — user research showed
31 vertical lists have better engagement for course discovery.'Design walkthrough language:
Connect every visual decision to user behavior:
Presentation anti-patterns:
In stakeholder reviews with multiple people, feedback often conflicts. Sales wants more promotional copy. Engineering wants simpler implementation. Legal wants more disclaimers. Marketing wants the logo bigger. All of these cannot be accommodated without destroying the design.
Conflict resolution framework — the RICE method:
1R — Reach: how many users does this affect?
2I — Impact: how significantly does it affect them?
3C — Confidence: how certain are we? (user data vs opinion)
4E — Effort: how much implementation work?
5
6RICE score = (Reach × Impact × Confidence) / EffortApplying RICE to conflicting feedback:
1Conflict: Marketing wants promotional banner vs Legal wants disclaimer
2
3Marketing: 'Limited time offer' banner above fold
4 Reach: all users who see homepage
5 Impact: drives urgency (medium — we have no data on urgency effectiveness)
6 Confidence: low (opinion-based)
7 Effort: 2 hours
8 RICE: (high × medium × low) / 2 = medium
9
10Legal: GDPR disclaimer on data collection
11 Reach: all users in EU
12 Impact: legal compliance (required by law)
13 Confidence: high (legal requirement, not opinion)
14 Effort: 1 hour
15 RICE: (high × high × high) / 1 = very high
16
17Decision: GDPR disclaimer first (required), promotional banner deprioritized
18 Rationale: legal compliance is non-negotiable; urgency banner has no data supportHandling 'the HiPPO' (Highest Paid Person's Opinion):
('In user testing, 4 of 5 users looked for the button at the top of the page')
('Note: executive requested orange button despite #111827 on orange failing WCAG AA. Accessibility override logged.')
Feedback response framework:
1Receiving feedback in real-time:
21. 'Thank you, I heard [X].' (acknowledge, do not immediately agree)
32. 'Can you help me understand the goal behind that?' (find the underlying need)
43. 'I can explore that — let me understand the priority first' (avoid committing immediately)
54. After session: assess all feedback against RICE, decide what to change
65. Communicate decisions back: 'We considered this and here is what we are changing / not changing and why'Developers often need to explain why a design request is technically problematic. Saying 'that is too complex' or 'it will take too long' lands poorly. Framing constraints in business impact language makes them comprehensible and actionable.
Translating technical constraints to business language:
1Technical: 'That animation will cause layout thrashing and degrade INP'
2Business: 'That animation would make the page feel slow on mid-range phones,
3 which are 60% of our mobile audience. It could reduce mobile
4 conversions by reducing perceived performance.'
5
6Technical: 'That button does not meet WCAG AA contrast requirements'
7Business: 'Users with visual impairments — approximately 8% of our users —
8 would not be able to read that button. In markets like the EU,
9 accessibility failures can also expose us to legal risk.'
10
11Technical: 'Implementing that would require a complete rewrite of the
12 checkout state management'
13Business: 'This would require 3-4 sprints of development work and pauses
14 all other checkout improvements during that time. We would delay
15 the A/B test campaign by 6-8 weeks.'
16
17Technical: 'That third-party component is not accessible and violates CSP'
18Business: 'This would violate our Content Security Policy, which protects
19 users from XSS attacks. Legal and security have flagged this
20 as a blocker. An accessible alternative exists.'Presenting alternatives alongside constraints:
Never present a constraint without an alternative:
Business impact language cheat sheet:
1Instead of... Say...
2'That is not accessible' 'That would exclude [X%] of users + legal risk'
3'Too slow to implement' 'That would delay [business objective] by [time]'
4'Technical complexity' 'Higher development risk of bugs and regressions'
5'Expensive to build' 'Would require [N] sprints = delaying [feature] by [weeks]'
6'Browser incompatibility' 'Would not work for [X%] of users on [browser]'
7'Security risk' 'Potential [GDPR/XSS/CSRF] exposure that requires legal sign-off'Stakeholders often add requests during design review that expand scope beyond what was planned. 'While you are at it, can you add...' is the beginning of scope creep.
Scope management framework:
In-scope: changes that improve the original problem without adding new ones
Out-of-scope: changes that add new problems to solve
Responding to out-of-scope requests:
1Stakeholder: 'Can you also add a course comparison feature to this page?'
2
3Response: 'That is a great idea and worth building. Adding a comparison
4 feature would require significant design work — defining how users
5 select courses to compare, how the comparison view works, and testing
6 the interaction model. That is a separate project scope.
7
8 I am logging it as a priority request for the next sprint planning
9 session. Can you share more about what triggered this idea? That will
10 help us scope it correctly.'
11
12Actions after the meeting:
131. Log the request in the product backlog with the requestor and date
142. Do not add it to current sprint scope
153. Include it in next sprint planning with an effort estimate
164. Send stakeholder: 'I logged course comparison as [JIRA-xxx].
17 It is scheduled for sprint planning on [date].
18 Please add any context to the ticket.'Change request template for post-design-freeze changes:
1## Design Change Request
2**Requested by**: [name]
3**Sprint affected**: Sprint N (currently in implementation)
4**Change**: [what they want changed]
5
6**Impact assessment**:
7- Implementation hours affected: [estimate]
8- Other sprint work delayed: [list]
9- QA time added: [estimate]
10- Total sprint impact: [days]
11
12**Options**:
13A) Implement in current sprint: delays [feature] by [X days]
14B) Implement in Sprint N+1: no current sprint impact
15C) Reject: reason [why this is not worth the cost]
16
17**Recommended**: Option [A/B/C] because [reason]
18**Decision by**: [name] by [deadline]A complete stakeholder design presentation for the course enrollment redesign, including handling conflicting feedback and scope creep.
1/* STAKEHOLDER PRESENTATION SCRIPT: Enrollment Redesign
2 Attendees: CEO (Kim), Head of Marketing (Raj), CTO (Alex)
3 Duration: 30 minutes
4
5=== CONTEXT SLIDE ===
6
7Presenter: 'Before I show the design, I want to frame the problem.
8
9We have a 23% lower enrollment conversion on mobile than desktop.
10User interviews revealed three main causes:
11 1. The enrollment button requires scrolling past 3 screens of content
12 2. The price is not visible when the CTA is visible
13 3. Users are unsure if they get access immediately or need to wait
14
15Success for this redesign: mobile enrollment conversion improves by
16at least 15%, bringing it within 8 points of desktop.
17
18What we are NOT solving: the actual checkout experience (a separate project).
19We are solving: what users see before they decide to click Enroll.'
20
21=== DESIGN WALKTHROUGH ===
22
23Presenter: 'The sticky enrollment bar at the bottom fixes cause #1
24— the button is always visible. It shows price, enrollment status,
25and the CTA button regardless of scroll position.
26
27The price is now shown in three places: top of page, sticky bar, and
28final summary. This addresses the 'unsure of price' behavior we saw
29in testing.
30
31The 'Instant access after enrollment' badge directly addresses the
32third concern — users were uncertain about wait times.'
33
34=== STAKEHOLDER FEEDBACK (actual quotes) ===
35
36Kim (CEO): 'This looks good. Can we add our promotional badge for
37 the annual subscription up-sell here?'
38
39Raj (Marketing): 'I agree with Kim. Also, can we make the logo bigger?
40 Brand visibility on this page is important for SEO.'
41
42Alex (CTO): 'I need to flag that the sticky bar will have
43 performance implications on iOS Safari because of the known
44 bug with position:fixed inside overflow:scroll containers.'
45
46=== PRESENTER RESPONSES ===
47
48To Kim (scope request — annual sub badge):
49'That is a good instinct — the annual subscription up-sell has
50high potential on this page since users are already considering
51a purchase. I want to make sure we do this well rather than rushing it.
52
53Adding the badge design and testing the right moment to show it
54(before or after price) would add 3-4 days of design and implementation.
55That would push the current sprint past the deadline.
56
57I am logging this as sprint priority JIRA-382 and proposing we add
58it to Sprint 5, which starts in two weeks. Can you confirm the priority?'
59
60To Raj (out-of-scope request — logo size):
61'Logo size is managed through the design system header component.
62Changing it affects the entire site, not just this page.
63Increasing the logo size would require a design system update and
64a cross-browser regression test across all pages.
65
66I would recommend discussing logo size separately with the brand team.
67For this sprint, I am keeping the current header to stay on scope.
68
69Would you be OK with logging the logo feedback as a separate design
70system discussion item for the quarterly brand review?'
71
72To Alex (technical constraint):
73'Alex — can you quantify the iOS Safari impact? How many of our
74mobile users are on iOS Safari, and what does the bug cause?
75A jank/flicker on scroll would be visible to all of them.'
76
77Alex: 'About 35% of mobile users are on iOS Safari. The bug causes
78the fixed bar to jump when the keyboard appears on input focus.'
79
80Presenter: 'That is significant. Alex, can we explore a CSS Grid
81or flexbox sticky approach as an alternative that avoids the position:fixed
82bug? I would rather find a better technical solution than show 35% of
83users a broken experience.'
84
85Alex: 'Yes — safe-area-inset-bottom + scroll-padding-bottom might
86work. I can prototype it.'
87
88Presenter: 'Let us add a half-day for Alex to prototype the Safari-safe
89sticky bar. That is worth it to protect 35% of our users.'
90
91=== POST-MEETING SUMMARY (sent to all attendees) ===
92
93Decisions:
94- Annual subscription badge: logged as JIRA-382, Sprint 5
95- Logo size: separate brand review discussion (out of sprint scope)
96- iOS Safari sticky bar: Alex prototyping CSS alternative in sprint
97
98Design proceeding: sticky enrollment bar + price visibility + instant
99access badge, with Safari-safe implementation.
100
101Next review: Wednesday 14:00 with Alex's Safari prototype results.
102*/The presentation leads with user data (23% lower mobile conversion, specific causes identified in research) before showing the design — stakeholders have a problem frame before seeing solutions. Kim's scope request (annual sub badge) gets a positive response ('good instinct') with a specific delay impact ($estimate) and a concrete alternative (Sprint 5 with JIRA ticket). Raj's brand request gets redirected to the correct process (brand review). Alex's technical flag gets taken seriously and becomes a collaborative problem-solving moment, not a blocker. The post-meeting summary closes the loop so nothing is lost.
The next lesson covers Storybook and Chromatic — how to build a living component library that designers can reference, developers can test, and stakeholders can review without code access.
Your progress is saved in this browser, on this device only.