Evolving design systems from research repository learning — to get more done with insights

Research repository insights fueling iteration of a design system’s principles, standards, and components. Illustration depicts a research repository, composed of abstracted documents, with insights pointing into a design system, represented abstractly as a series of bubbles representing different elements.

Bridging from point solutions to systemic needs. When teams address insights about product-wide design problems with feature-specific solutions, they can create needless variation that becomes expensive-to-fix ‘UX debt.’

To drive consistency and usability, research repository programs can collate and push insights with direct implications for overarching design systems. Over time, stakeholders in design systems can become core advocates for existing insights, grounding their standards and experimentation in evidence-based problems to solve.

Q: “I have an experiment to try to fix that one customer misunderstanding about what we were trying to let them modify existing items.” A: “Great! Aren’t there a lot of other places where that appears in different features?” Q: “Yeah, it’s all over the place. If the experiment works, we can update the design system and try it across the board” A: “That sounds like a great impact to shoot for.”

Regardless of whether design guidelines are just getting started as a passion project or your products’ design system is owned by a dedicated design operations team, research repositories can become essential for identifying problems to target, prioritizing those problems, and making the case for systemic change.

Improving your insight operations

  • Identifying examples where research has previously impacted design systems
    Connect with individual researchers and design leaders about past systemic wins that made big impacts. Track down cases from across your contributor community where research has impacted design systems, whether formally, through a centralized campaign, or informally, as something gradually propagated through various product teams.
  • Scouring existing research to find more insights that could fuel systemic design
    Take another look at your repositories’ contents with the goal of finding problems that could be solved with design systems, as well as any positive design findings that could be replicated across your products. Consider defining metadata that could enable the ongoing discovery of these insights over time (e.g. ‘Design-Systems-team’ label). Cast a wide net, but flag a ‘top’ set of insights that has clear, high-value implications for creating or iterating patterns.
  • Aligning with leaders about using existing insights as an input to design systems
    Meet with whomever is responsible for systemic design, be it a few passionate leaders just getting started or a dedicated team that’s continuously advancing product-wide design considerations. Invite researchers who can immerse leaders in past wins, as well as your ‘top’ set of unaddressed insights that could drive what’s next. Ask about how decision making works for design systems, and seek out any established backlog or prioritization processes. Grow buy in for some initial experiments, targeting insights that are sure to lead to measurable benefits that will be clearly attributable to the improved design system.
  • Piloting design system experiments grounded in existing, high-value insights
    Invest in shepherding initial pilots along, increasing the likelihood of positive outcomes. Ensure that research remains a visible part of the experiment, as well as the resulting documentation for the iterated design system. Continue investing just enough involvement to ‘prime the pump,’ normalizing existing research as a common driver of systemic design work. Share resulting wins broadly, building a virtuous feedback loop among researchers, designers, and implementers.
  • Routing incoming insights for ongoing iteration and growth of design systems
    Develop ‘just enough’ process to ensure an ongoing connection between existing research and design systems workstreams. Given that these systems can represent long-term, architectural work — ask for visibility into progress to date, as well as areas that have not been prioritized as of yet. Advocate for any cases where changing design systems could prevent harm or unblock customer success. In some cases, this may mean scheduling ‘echo’ research readouts to influence ‘hold out’ engineering teams who need to prioritize implementations.
  • Your idea here…

On the path from insight to product impact

A diagram of seven stages on the path from insight to product impact: Category called “Integrating research content” 1) Sufficient evidence (grayed out), 2) Usefully articulated insight (grayed out), 3) Awareness of possible planning target (grayed out), Category called “Integrating into product planning” 4) Envisioned solution ideas (highlighted), 5) Prioritized plan (partially highlighted), 6) Quality execution (partially highlighted), 7) Understood results (grayed out).

Let’s connect

Related posts

Selected references

  • “The DesignOps team is very focused on the design system as a whole, from the library of components to guidelines to principles. We’re in the process of building out that gigantic component library, which is a necessary centerpiece for all of this. Every design, before it goes into development, goes through a DesignOps review. This means that all of the components in the design are reviewed, to make sure we’re following the standards for each component individually and the components together.” Bret Scofield, Sofia Quintero
  • “You’ll see that most conversations about design systems today centre around our component libraries, our documentation, how we integrate our systems with design tools, and our contribution mechanisms. And whilst these things are usually critical to how we cultivate effective design systems (today at least), what concerns me is that we tend to focus on them at the expense of the human impact.” Amy Hupe
  • “Using a user-centered design process, he talked to designers using their design system. They wanted to know what the right pattern to use, and when. And they wanted the latest version from optimization and testing. Developers wanted their own instance so they could see the patterns without disrupting things more broadly. They also wanted to know what was official, and who made the decision so they could negotiate it.” Eniola Oluwole



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jake Burghardt

Jake Burghardt

Focused on integrating streams of customer-centered research and data analyses into product operations, plans, and designs. www.linkedin.com/in/jakeburghardt