Maintain design quality and velocity in agile teams using minimum viable design, progressive elaboration, continuous discovery, and lightweight design documentation practices.
Waterfall design — spending months designing everything before any development begins — fails in agile environments. But pure agile without design discipline produces inconsistent, inaccessible UIs with high technical debt.
Agile design finds the middle ground: enough design to guide good implementation, delivered at the pace the team needs it, with flexibility to evolve as the product learns from users. The techniques in this lesson — minimum viable design, progressive elaboration, and continuous discovery — come from teams that have made agile design work at scale.
Minimum Viable Design (MVD) defines the minimum fidelity of design artifacts needed for a developer to implement correctly. More fidelity than MVD is waste; less is risk.
Fidelity levels and when to use each:
1Level 1: Text description
2 When: exploring whether a feature is worth designing
3 Example: 'Button that shows enrollment status and triggers enrollment'
4 Time: 5 minutes | Risk: high implementation variance
5
6Level 2: Wireframe sketch
7 When: validating information hierarchy before visual design
8 Example: rough Figma frame showing layout without final values
9 Time: 30 minutes | Risk: moderate variance, some rework
10
11Level 3: Hi-fi mockup (single state)
12 When: new pattern with clear precedent in design system
13 Example: new page using existing components in new arrangement
14 Time: 2 hours | Risk: low variance if design system is mature
15
16Level 4: Hi-fi mockup (all states)
17 When: new component or complex interaction
18 Example: new form with validation, loading, error, success states
19 Time: 4-8 hours | Risk: very low variance
20
21Level 5: Prototype
22 When: complex animation or interaction flow
23 Example: drag-and-drop reordering, multi-step checkout
24 Time: 8-16 hours | Risk: near-zero variance (but expensive)MVD by component type:
1New page using existing components → Level 3 (single state hi-fi)
2New component → Level 4 (all states hi-fi)
3Simple text/layout change → Level 1-2 (wireframe or description)
4Animation/transition → Level 5 (prototype)
5Content change → Level 1 (description only)Why MVD matters for developers:
Over-designed specs (Level 5 for every change) slow down delivery.
Under-designed specs (Level 1 for complex interactions) create rework.
Matching fidelity to need keeps velocity high without quality loss.
Progressive elaboration delivers design in stages — starting rough and adding detail only as needed, validated by developer feedback and user testing.
Progressive elaboration cycle:
1Week 1: Wireframe
2 - Defines information hierarchy, content structure, layout
3 - Low visual fidelity (no colors, real typography, or spacing)
4 - Developer can start building page structure (semantic HTML, layout)
5 - Design questions answered at this stage: what is on the page?
6
7Week 2: Visual Design (first pass)
8 - Adds colors, typography, spacing from design system
9 - Covers primary path only (happy path)
10 - Developer can implement primary UI with placeholder states
11 - Design questions answered: what does success look like?
12
13Week 3: State Design
14 - Adds hover, focus, loading, error, empty, disabled states
15 - Responsive breakpoints defined
16 - Developer completes implementation with all interactive states
17 - Design questions answered: what does each state look like?
18
19Week 4: Edge Cases
20 - Long content, truncation, overflow
21 - Accessibility annotations
22 - Animation timing and easing
23 - Developer handles edge casesProgressive elaboration in practice:
Developer does not wait for Week 3 designs to start:
This requires trust between designers and developers:
Continuous discovery keeps user research running alongside design and development — not as a pre-project phase, but as a constant weekly practice.
Continuous discovery framework (Teresa Torres):
Weekly discovery cadence:
1Monday: Review last week's interview notes
2 Identify 3 key insights from the interviews
3 Update opportunity map with new findings
4
5Tuesday: Recruit participants for Thursday's interviews
6 Design the interview script or prototype to test
7
8Thursday: 2-3 user interviews (60 min each)
9 At least one team member observes each interview
10
11Friday: Debrief (30 min with designer + PM)
12 'What did we learn?'
13 'What assumption was challenged?'
14 'What should we test next week?'What continuous discovery catches:
Design decisions informed by discovery:
1Without discovery: 'Users want a dashboard' (assumption)
2With discovery: 'Users want to see their progress in one place' (observed)
3
4Without discovery: 'The filter UI is clear enough' (designer opinion)
5With discovery: '4 of 5 users could not find the filter button' (evidence)
6
7Without discovery: 'We should add more features to the homepage'
8With discovery: 'Users skip the homepage entirely — they bookmark course pages'Developer's role in continuous discovery:
a different approach would be simpler to build'
(e.g., analytics shows users clicking non-clickable elements)
Design documentation accumulates debt — pages nobody reads, decision logs nobody updates, specs that diverge from the final implementation. Lightweight documentation captures what matters without maintenance burden.
What to document (always):
Example: 'Used 3-column grid instead of 4 because analytics shows users
scan vertically, not horizontally — 4 columns had worse engagement'
Example: 'Considered infinite scroll for course list — rejected because
it prevents users from bookmarking their position'
Example: 'Course title truncated at 60 chars due to SEO metadata length limit'
What NOT to document:
Lightweight documentation formats:
1 # ADR-012: Single-column layout for mobile checkout
2 Date: 2026-05-15
3 Status: Accepted
4 Context: Checkout conversion rate 23% lower on mobile than desktop
5 Decision: Force single-column layout on mobile, disable two-column
6 Consequences: Simpler mobile implementation, longer form scroll
7 Rejected alternatives: Accordion sections, wizard stepsApplying minimum viable design, progressive elaboration, and continuous discovery to design a course recommendation feature.
1/* COURSE RECOMMENDATION FEATURE: Agile Design Workflow
2
3=== WEEK 1: DISCOVERY AND WIREFRAME ===
4
5Discovery insight (from 3 user interviews):
6 'I don't know what to learn next. I finish a course and
7 feel lost about where to go.'
8
9Opportunity: Help users identify their next step after course completion
10
11MVD decision: Level 3 (hi-fi single state)
12 Rationale: Uses existing course cards, just needs new recommendation logic
13
14Wireframe (Figma, 30 minutes):
15 - 'Continue your learning path' section below current course
16 - 3 recommended course cards
17 - Simple horizontal scroll on mobile
18
19Developer week 1 action:
20 - Build semantic HTML structure from wireframe
21 - Implement horizontal scroll container (CSS snap scrolling)
22 - Placeholder recommendation data (hardcoded for now)
23
24Code from wireframe stage:
25 <!-- Structure from wireframe, no final values yet -->
26 <section class="learning-path">
27 <h2>Continue your learning path</h2>
28 <div class="recommendation-scroll">
29 <!-- CourseCard components -->
30 </div>
31 </section>
32
33=== WEEK 2: VISUAL DESIGN ===
34
35Designer adds:
36 - Section header: 24px/600/#111827
37 - Subtitle: 'Based on your progress in CSS Mastery'
38 - Card spacing: gap 16px
39 - Section padding: 48px 40px
40 - 'See all recommendations' link
41
42Figma named version: 'Recommendations — Primary Path v1'
43
44Developer week 2 action:
45 - Apply visual design values from Figma Inspect
46 - Connect to API: GET /recommendations?userId=X&courseId=Y
47 - Real recommendation data replaces placeholders
48
49New CSS from week 2:
50 .learning-path {
51 padding: 3rem 2.5rem; /* 48px 40px */
52 }
53 .learning-path__title {
54 font-size: 1.5rem; /* 24px */
55 font-weight: 600;
56 color: #111827;
57 }
58 .learning-path__subtitle {
59 font-size: 0.9375rem;
60 color: #6b7280;
61 margin-top: 0.25rem;
62 }
63 .recommendation-scroll {
64 display: flex;
65 gap: 1rem; /* 16px */
66 overflow-x: auto;
67 scroll-snap-type: x mandatory;
68 -webkit-overflow-scrolling: touch;
69 }
70
71=== WEEK 3: ALL STATES ===
72
73Designer adds:
74 - Loading skeleton: 3 gray placeholder cards
75 - Empty state: 'No recommendations yet — complete more lessons'
76 - Error state: 'Could not load recommendations' + retry button
77 - 'Not interested' dismiss button on each card
78
79Figma named version: 'Recommendations — All States v1'
80
81Developer week 3 action:
82 - Implement skeleton loading (CSS animation)
83 - Implement empty and error states
84 - Add dismiss functionality (POST /recommendations/:id/dismiss)
85
86=== WEEK 4: DISCOVERY VALIDATION ===
87
88User test with 3 users:
89 - Task: 'After finishing CSS Mastery, what would you do next?'
90 - All 3 users clicked on recommendations immediately
91 - 2/3 users dismissed an irrelevant recommendation
92 - 1 user confused by 'Continue your learning path' (expected a playlist)
93
94Design adjustment:
95 - Title changed: 'You might also like' (clearer intent)
96 - Dismiss button: added 'Not for me' label (was icon-only)
97
98Figma update: 'Recommendations — User Test Revisions'
99
100Developer week 4 action:
101 - Update title text
102 - Add text label to dismiss button (aria-label already present)
103 - No structural changes needed
104
105=== RETROSPECTIVE ===
106
107Time invested:
108 Design: 8 hours total across 4 weeks
109 Dev: 12 hours total across 4 weeks
110 Discovery: 2 hours (3 interviews + debrief)
111 Total: 22 hours
112
113Value delivered:
114 - Feature users wanted (validated by discovery)
115 - All states implemented (no emergency hotfixes after launch)
116 - User-test validated title (reduced confusion)
117 - Dismiss feature (user-requested, caught in testing not analytics)
118*/Progressive elaboration let the developer start in Week 1 from a wireframe — building HTML structure and CSS layout without waiting for final visual design. The MVD decision (Level 3, not Level 5 prototype) was correct because the recommendation cards use existing components. The discovery practice found the title confusion in Week 4 testing — changing 'Continue your learning path' to 'You might also like' took 5 minutes in Figma and 30 seconds in code. Without user testing, this confusion would have been discovered after launch through support tickets.
The next lesson covers Agile Design QA Process — how to run rapid design QA sessions that fit within sprint cycles without becoming a bottleneck, using automated visual regression to catch regressions before they reach QA.
Your progress is saved in this browser, on this device only.