Give constructive, principle-based design feedback as a developer — frame critiques using design vocabulary, contribute implementation insights to design decisions, and communicate design quality standards to non-design stakeholders.
Design critique is a skill that developers rarely practice but frequently need. As a developer who has worked through this module, you now have a vocabulary of design principles — CRAP, visual hierarchy, Gestalt, typography, color, psychology — that enables principled critique rather than subjective preference.
The difference between 'I don't like this design' and 'The primary CTA has insufficient contrast against secondary buttons — both are visually equal weight, which creates decision paralysis (Hick's Law)' is the difference between unhelpful feedback and feedback that actually improves the design.
This lesson covers how to give principled design feedback, how to contribute implementation perspectives to design decisions, and how to explain design quality to people who do not have design training.
The most important distinction in design critique is between principled feedback (based on observable principles and measurable standards) and preference-based feedback (based on personal aesthetic taste).
Preference-based feedback (avoid):
Principled feedback (use):
Principle-to-feedback template:
1Observation + Principle + Measurable evidence + Suggestion
2
3Example:
4 Observation: 'The filter dropdown appears at the same visual depth as the page'
5 Principle: 'Figure-Ground principle: overlaid elements need elevation cues'
6 Evidence: 'The dropdown has no box-shadow, so it blends with the page surface'
7 Suggestion: 'Adding box-shadow: 0 8px 24px rgb(0 0 0 / 0.12) would
8 establish the dropdown as a foreground figure'
9
10Result: 'The filter dropdown blends with the page content (no elevation cues).
11 By Gestalt Figure-Ground principle, overlay elements need shadows or
12 backdrop to establish themselves as foreground. Suggest:
13 .dropdown { box-shadow: 0 8px 24px rgb(0 0 0 / 0.12); }'Developers see design through an implementation lens — they notice patterns that are complex to build, animations that will harm performance, and accessibility gaps that static designs cannot show. This is valuable design feedback when framed correctly.
Converting implementation concerns to design feedback:
Complexity concern:
1Weak: 'That animation is too complex to build'
2
3Strong: 'The accordion animation as designed uses max-height transition,
4 which causes layout thrashing and degrades Interaction to Next Paint (INP).
5 The same visual effect can be achieved with grid-template-rows animation,
6 which is GPU-composited and maintains 60fps on all devices.
7 Should I implement the design with the more performant approach, or
8 is the specific animation behavior important enough to use max-height?'Accessibility concern:
1Weak: 'This isn't accessible'
2
3Strong: 'The filter button row has no visible focus ring — clicking focuses
4 the first button, but keyboard users cannot see which button is focused.
5 For WCAG 2.4.7, keyboard focus must be visible. Adding
6 .filter-btn:focus-visible { outline: 2px solid var(--color-action); }
7 fixes this without changing the visual design for mouse users.'Performance concern:
1Weak: 'Those images will make the page slow'
2
3Strong: 'The hero section currently loads the background image without
4 a specified width and height. This causes Cumulative Layout Shift (CLS)
5 as the image loads. WCAG 1.3.4 and Core Web Vitals require stable layouts.
6 Adding width and height attributes to the img element eliminates this shift:
7 <img width="1440" height="480" loading="lazy" src="hero.jpg">'Pattern concern:
1Weak: 'This doesn't work on mobile'
2
3Strong: 'The data table layout uses horizontal columns that become unreadable
4 at 375px — the leftmost column is only 60px wide for content that needs
5 120px. A card-based layout for mobile (each row becomes a card with
6 key: value pairs) is a standard accessible pattern for this case.
7 Should I implement a responsive card fallback at < 640px?'Having the same vocabulary as designers enables faster, more precise design conversations. Without shared vocabulary, both sides describe the same thing in different words and misunderstand each other.
Core vocabulary for developer-designer conversations:
1Hierarchy: the visual ordering of elements by importance
2Contrast: the difference in visual weight between elements
3Alignment: the consistent positioning of elements along shared lines
4Proximity: spatial grouping of related elements
5Repetition: consistent use of visual elements throughout a design
6Rhythm: regular variation of design elements creating visual flow
7Balance: equal distribution of visual weight across the composition
8Unity: all design elements feeling part of one coherent system
9
10Specific terms:
11Baseline: the imaginary line on which text sits
12Kerning: spacing between specific letter pairs
13Tracking: uniform spacing across all letters in text
14Leading: vertical spacing between lines of text (= line-height)
15Ascender: the part of a letter that extends above the cap height (h, l)
16Descender: the part that extends below the baseline (g, p, y)
17Cap height: the height of uppercase letters
18X-height: the height of lowercase letters without ascenders/descenders
19
20Color:
21Hue: the pure color (red, blue, yellow — the 'what color')
22Saturation: the intensity of the color (vivid vs gray)
23Lightness: the amount of white or black in the color
24Value: the lightness/darkness of the color (= Lightness in HSL)
25Tint: color + white (lighter version)
26Shade: color + black (darker version)Using vocabulary in conversations:
1Designer: 'The button needs more visual weight'
2Developer with vocabulary: 'I can increase visual weight through:
3 (a) larger padding — increases the button area
4 (b) heavier font-weight — currently 400, can go to 600
5 (c) higher color saturation — current #3b82f6 is medium saturation
6 (d) adding a box-shadow — creates elevation
7 Which dimension did you want to adjust?'
8
9Designer: 'The card feels too light'
10Developer: 'Light as in visual weight or light as in color lightness?
11 If visual weight: I can add a border or increase padding
12 If color: I can darken the background from #f9fafb to #f3f4f6'Stakeholders without design training often question design decisions that seem 'too simple' or 'too expensive.' Explaining design quality in terms of user impact and business outcomes makes these conversations productive.
Explaining design principles to stakeholders:
On whitespace:
1Stakeholder: 'There is too much empty space — can we fit more content?'
2
3Design-informed response:
4'The current whitespace is functional — it creates the visual separation
5that lets users scan and find what they need quickly. Reducing it by 50%
6would require users to slow down to parse content that currently scans
7in seconds.
8
9In usability testing, pages with appropriate whitespace show 20-30%
10better task completion rates than dense alternatives. The tradeoff:
11content density vs user comprehension and conversion rate.
12
13If you need to fit more content: we can consider reducing padding
14in the less-critical secondary sections while preserving whitespace
15around the enrollment CTA, which directly drives conversion.'On simplicity:
1Stakeholder: 'The design is too simple — our competitors have more features'
2
3Design-informed response:
4'The current design applies Hick's Law — fewer options means faster
5decisions. Our checkout has 3 form fields; competitor X has 8.
6Formstack research shows every additional form field reduces
7completion rate by approximately 11%.
8
9Simplicity here is a competitive advantage, not a limitation.
10If we add fields, we should add only those with data showing
11they improve downstream quality (e.g., job title for B2B leads).'On color choices:
1Stakeholder: 'Can we make the button more colorful? It's very plain'
2
3Design-informed response:
4'The current blue meets WCAG AA contrast (4.8:1) for the text inside.
5A more saturated or brighter color might fail this threshold, which
6creates legal accessibility risk.
7
8If we want more visual impact while maintaining accessibility:
9options include adding an arrow icon to the button (adds energy
10without changing color), or adding a subtle drop shadow
11(creates depth without changing the base color).'Providing principled design feedback on a filter UI redesign proposal, combining principle-based critique with implementation insights.
1/* DESIGN CRITIQUE: Filter UI Redesign Proposal
2 Reviewer: Developer (principle-based)
3 Design: New sidebar filter panel replacing top filter bar
4
5=== PROPOSED DESIGN DESCRIPTION ===
6
7Design proposes:
8 - Move filters from top horizontal bar to left sidebar
9 - Sidebar: 280px wide, always visible on desktop
10 - Course grid: right of sidebar, 3 columns → 2 columns with sidebar
11 - All 24 filter options visible simultaneously in sidebar
12 - Sidebar has no close/hide option on desktop
13
14=== CRITIQUE ===
15
16FINDING 1 — Hick's Law violation (High)
17
18Principle: Hick's Law — decision time increases with number of choices
19
20Current proposal: all 24 filter options visible simultaneously
21
22Evidence from research:
23 - NNGroup usability research: filter panels with > 6-8 options require
24 progressive disclosure for efficient use
25 - Current top-bar approach: 5 visible + '+7 more' = 2 decisions
26 - New sidebar: 24 simultaneous decisions
27
28Suggestion:
29 Group filters into 4-6 collapsible categories:
30 - Level (5 options) — default collapsed
31 - Topic (8 options) — default collapsed
32 - Duration (3 options) — default expanded
33 - Type (2 options) — default expanded
34 - Price (3 options) — default expanded
35
36 This applies progressive disclosure:
37 .filter-category.collapsed .filter-options { display: none; }
38 .filter-category .category-toggle { /* expand on click */ }
39
40FINDING 2 — Layout shift from 3 → 2 columns (High)
41
42Principle: Visual hierarchy and information density
43
44Current design: 3-column grid at desktop (comfortable browsing)
45New sidebar design: 2-column grid (25% fewer courses visible)
46
47Evidence:
48 At 1280px wide:
49 - Sidebar (280px) + gap (24px) + content area = 976px
50 - 2 columns at 976px = 466px per card
51 - 3 columns at 1280px = 405px per card
52 - Users see 33% fewer courses per page with sidebar
53
54Suggestion:
55 Option A: Auto-hide sidebar at 1024px (sidebar applies when open, float over content)
56 Advantages: maintains 3-column grid when sidebar closed (default state)
57 Implementation: position: fixed sidebar with 3-column grid always maintained
58
59 Option B: Use 4 narrow columns with sidebar (smaller cards)
60 Advantages: same course count visible
61 Risk: cards too narrow for quality thumbnail display (< 220px)
62
63 Recommend Option A:
64 .sidebar { position: fixed; left: 0; top: 4rem; width: 17.5rem; /* 280px */}
65 .courses-grid { margin-left: 0; } /* sidebar floats OVER grid, not beside it */
66 .sidebar-backdrop { /* dims grid when sidebar open */ }
67
68FINDING 3 — Desktop sidebar cannot be hidden (Medium)
69
70Principle: Cognitive load, Focus
71
72Issue: sidebar always visible means always consuming left visual attention
73 Even when user has already filtered and is now browsing results,
74 the sidebar continues to draw eye attention (visual weight on left)
75
76Suggestion: Add collapse to narrow (48px) rail with icons only
77 .sidebar.collapsed { width: 3rem; }
78 .sidebar.collapsed .filter-label { display: none; }
79 .sidebar.collapsed .filter-icon { display: flex; }
80
81 This maintains navigation presence (Fitts: target available)
82 without constant visual weight from label text.
83
84FINDING 4 — Positive: Consistent with design principles ✓
85
86 The sidebar card style (white bg, 1px border, 12px radius, 16px padding)
87 matches the main course card design language — Unity maintained.
88
89 The filter group headings use the same uppercase label style as the
90 rest of the product — Repetition maintained.
91
92=== RECOMMENDED APPROACH ===
93
94Modified sidebar design with:
95 1. Progressive disclosure (collapsible categories, max 6 open at once)
96 2. Float-over positioning (preserves 3-column grid)
97 3. Collapsible to 48px rail (reduces persistent visual weight)
98
99Estimated implementation: same complexity as original proposal
100 (sidebar already required; only float positioning and collapse added)
101
102Would this direction work within the sprint scope, or is the
103full sidebar a stakeholder requirement that I need to implement as designed?
104*/The critique focuses exclusively on measurable principles: Hick's Law violation (24 choices vs recommended 8), layout density loss (33% fewer courses visible, calculated from actual pixel values), and persistent visual weight from non-hideable sidebar. Each finding cites the relevant principle, provides evidence (pixel values, research citations), and offers a specific CSS approach. Finding 4 explicitly acknowledges what the design gets right — unity and repetition are maintained — demonstrating that critique means evaluating against principles, not defaulting to negativity. The final question ('stakeholder requirement or negotiable?') respects the design decision hierarchy without blocking implementation.
The final lesson is the Complete Design Principles Project — a capstone implementation applying all principles from this module to build and review a complete web interface from scratch.
Your progress is saved in this browser, on this device only.