Evolving design systems from research repository learning — to get more done with insights
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.
Great design teams are always looking for opportunities to systematize their outputs into a consistent language for their products. These teams continually evolve their own design systems, which can include documented design patterns; usage examples and guidance; design tools and templates; and even standardized, coded components.
Whether research is a centralized function or a highly decentralized practice, research repositories can grow compelling content for systemic design. Synthesized insights can surface usability issues, accessibility challenges, and unmet design opportunities — all of which can fuel more consistent, usable, and equitable design systems.
One of my favorite parts of owning research repositories has been working with folks who build design systems. Whether forging new commonalities across a problematically varied product or proposing new interaction patterns where the industry has not yet tread, evangelists of systemic design can become enthusiastic and impactful users of existing research.
More often than not, researchers in your organization are already impacting design systems — establishing an impact footprint that research operations can expand upon. We can collect those impacts as a foundational proof of concept, then scour our repositories for additional learning that could evolve product-wide design. And once the people working on your design systems have seen the value of our repositories as a basis for their efforts, we can continue to send them evidence-based problems as new insights come in.
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.
Using existing research to advance system-wide design is about more than forging another avenue for research impact. By preserving and communicating insights about particular design approaches, we can increase the frequency of successful customer and business outcomes, while at the same time reducing harm. And by folding insights into the standards that designers use in their everyday work — while keeping that underlying research rationale present and visible — we can continue to establish known insights as a commonplace part of product thinking and work products.
Improving your insight operations
Get more done with your research community’s insights by:
- 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
Driving new product design systems and guidelines from existing research is part of having envisioned solution ideas to address insights. It’s also related to prioritizing plans of action and maintaining product quality in execution.
If you’ve read this far, please don’t be a stranger. I’m curious to hear about your challenges and successes connecting research repositories into things like design principles, patterns, and components in your organization. Thank you!
- G2. Enlisting design dreamers to explore solutions for unaddressed needs in research repositories — and get more done with insights
- C4. Meta analyzing across existing research to inform strategic product uncertainties — and get more done with insights
- A5. Activating insights to overcome common barriers to product impact
- C3. Adding ‘echo read outs’ to re-engage product teams with research projects — and get more done with insights
- View list of all ‘Integrating Research’ posts (and upcoming topics)
- “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