User research + design systems = ?

Broadly speaking, user research evaluates user needs and recommends new products and services or changes to existing products and services based on that research.

Design system work evaluates an organization’s workflow and helps teams get common design decisions into software at scale.

Someone recently asked me: what (if any) is the overlap between the two?

The answer surfaces a tension that sometimes exists between design systems work and product design work. Does your design system serve your org’s in-house teams, or does it serve your org’s customers?

I would say: primarily in-house teams, but it serves them by helping them deliver usable, consistent customer experiences.

So what would it look like to incorporate user research into a design systems team?

New Teams

If you’re a new team with no tools or products yet, user research might be more generative or need-finding.

  • Interview designers and engineers to understand the existing product landscape, current build processes and tooling, pain points, and wish lists;
  • Interview org leadership and management to get insight about organizational priorities and goals, and develop a stakeholder map;
  • Interview design system teams from similar orgs (as subject matter experts) to get ideas for tackling challenges specific to your org type or vertical;
  • Validate existing assumptions about customer needs;

In addition to framing problems and generating ideas for possible solutions, research like this can build relationships with your DS users (product designers/engineers), stretch your teams UXR muscles, generate empathy and interest among leadership, and generally promote the value of the work the team is doing until you actually release something.

Mature Teams

If you’re a mature team with a suite of tools and resources, user research might be more evaluative and iterative.

  • Conduct usability studies to evaluate the usability of existing components and recommend improvements;
  • Work with designers and engineers to create case studies for tools and resources that can instruct other teams who could use them;
  • Use research insights to create higher-order component usage patterns, educating teams who build with components how to combine them in meaningful ways to create better user experiences;
  • Interview teams for continuous improvements of internal tools and processes;
  • Standardize user research methods and practices across the org;

Google’s Material Design is a good example of evaluating and iterating existing components. Their team ran an extensive study with forms and changed the form styles based on what they found. This important work didn't just benefit the people who build products using Material, it helped the people who use products built with Material.

Research insights that lead to improving shared resources will benefit everyone who uses them. Improve the building blocks, and you improve what's built with them.

But research can do more than just improve tools. By sharing insights about the real needs of customers and focusing attention on the entire user journey, not just the pathway of a single service or application, user research can improve the entire organization.


Cheers,
Jesse Gardner

Up Next: Design system as leverage.

← Full Archives

Design Systems Daily

Sign up to get daily bite-sized insights in your inbox about design systems, product design, and team-building:

New to design systems?
Start with my free 30-day email course →