Design System Feedback: Start with User Needs

WHY IT EXISTS To prevent design systems from becoming disconnected from reality. Without a direct line to end-users, a system can become an echo chamber of designer preferences, leading to products that are difficult or inefficient for people to use. Grounding the system in user needs ensures it solves real problems.

THE MENTAL MODEL Think of your design system not as a product for designers, but as a foundational service for end-users. The feedback that matters most comes from them. Your goal is to understand their needs, goals, and behaviors to inform every component and pattern in the system.

HOW IT WORKS This involves a continuous cycle of research and validation. First, start early with foundational research to understand user perspectives and problems. Second, use a range of qualitative and quantitative methods, like interviews and surveys, to gather data. Third, build and test prototypes with real users to validate assumptions before committing to code. Fourth, test the final components regularly to ensure they continue to meet user needs. Finally, document and share all findings widely to align the team.

WHEN TO USE IT Use this user-centered approach at all stages of the design system's lifecycle. Use it when deciding which new components to add to the roadmap. Use it during the design phase of a specific component to test variations. Use it after a component is released to measure its effectiveness in real products.

WHEN NOT TO USE IT This principle is almost universally applicable. The methods might change based on resources, but the principle of user validation should not be skipped. Don't use the lack of a formal research team as an excuse to ignore users entirely; even informal testing is better than none. The risk is building something nobody needs.

ONE CANONICAL EXAMPLE A team is considering adding a complex date range picker to their design system. Instead of just building it, they first interview users of an application that needs it. They find users struggle with picking fiscal quarters. They prototype a picker with 'quick select' buttons for Q1, Q2, etc., test it, and find it dramatically improves speed and accuracy. This user-validated design becomes the official component.