Last week, we covered how to build a design system foundation - tokens, typography, spacing, and component architecture. But here's the question that keeps getting skipped: where do those decisions actually come from?
The Missing Link Between Research and Your Design System
A design system without research is just an opinion at scale.
Every token you define, every component state you document, every spacing rule you enforce - it either maps to a real user behavior, or it doesn't. And when it doesn't, your system quietly accumulates debt: components nobody uses, patterns that confuse, states that were never the right states.
User research is not a phase that happens before design. It's the continuous input layer that keeps your system honest.
What Research Actually Tells Your Design System
1. Tokens Come From Mental Models, Not Mood Boards
When you define color.feedback.error or spacing.component.gap, you're making a claim about how users perceive and process information.
Research validates that claim.
According to NN/G, user interviews are most powerful in the discovery phase - revealing who your users are, what their experiences are like, and what they need.
That's token-level signal. If users consistently misread a warning state as an error, your color.feedback.warning token is doing the wrong job - no matter how elegant the hex value.
Research input → Token decision:
What Users Tell You
What Changes in the System
"I didn't know it was clickable"
Review color.interactive.default contrast ratio
"The spacing felt cluttered on mobile"
Audit spacing.layout.dense against real viewport behavior
"I ignored that - I thought it was a label"
Reconsider typography.label vs typography.caption distinction
2. Component States Are Defined by Real Edge Cases
Last week's design.md documented component states: default, hover, active, disabled, loading, error.
But here's what research adds: the states users actually encounter vs. the states we assume they encounter are rarely the same.
NN/G notes that the distinction between "what people say" and "what people do" is one of the most critical tensions in research - and very often, the two are quite different.
A loading state that lasts 200ms in your test environment might last 4 seconds on a user's actual network. That changes everything about how your component should behave. Research surfaces those real-world conditions that documentation alone never will.
Before adding a component state → ask: Has a user ever encountered this? What did they do?
3. Patterns Are Validated, Not Assumed
Your design system documents patterns - form layouts, navigation structures, empty states, error flows. Research tells you if those patterns actually reduce friction or just look clean in Figma.
NN/G found that open-ended questions in interviews result in deeper insights - the kind that closed questions and analytics dashboards simply can't surface.
That depth is what separates a pattern that converts from a pattern that gets abandoned. Analytics tells you that users dropped off. Interviews tell you why - and that why is what you encode into your system.
The Prerequisites: What You Need Before Research Informs the System
Getting research to actually feed your design system requires more than good intentions. It requires a process.
Step 1 - Define the research question tied to a system decision. Don't do generalist research. Ask: "We're defining our notification component. What do users actually need to know, and how urgently?" That's a system-level question.
Discussion
0 comments