COMPONENT LIBRARY REFRESH
a design systems project for Understood (2021)
Understanding the problem
identifying navigational pain points
As Understood moves towards a new, more consistent brand across our product suite, I’d begun to notice a large area of opportunity in component reuse. Our designers were building large new features completely from scratch despite complex components existing in our design tools. In monitoring the dev side, I also noticed that we had no compunctions about growing our library, but very infrequently took opportunities to reuse components.
In order to learn more about my observations, and get to the root of the problems, I included the entire UX and front-end teams (and one intern) in usability tests. These tests measured time to task for finding components, as well as sentiment and level of understanding around the component library.
Architectural challenges
Styles and components were Difficult to locate
The most common complaint from both designers and developers was that our components were spread across not one, but four differently-named libraries divided by programming language. While this made sense for developers, it made component reuse impossible for our design team. And, if designers don’t reuse components, developers receive no indication of what components to include.
It’s important to note that Understood is an organization especially dedicated to accessibility and inclusivity, as well as one that makes liberal use of lean experimentation. By not reusing components, we’d robbed ourselves of all the consistency, accessibility, and efficiency benefits that design systems are meant to provide in situations like ours.
Response breakdown from first-round usability tests in Dovetail. It’s important to note that “understands where to find components” and “found component quickly” was usually either a developer response, or was coupled with “found component by accident”
System restructuring, success metrics
Alignment of taxonomy across the whole system
To solve this problem, I audited our existing components and mapped them into a single-repository structure broken down using Atomic Design-style classifications. Though a single repo was the most common request during my tests, I felt at least some subdivision was important in helping designers and devs wade through our huge collection of components.
In order to confirm that this was the best solution for us, I created a prototype version of this mapping using Zeroheight and used it to repeat my initial usability tests. To my surprise, time-to-task decreased by 72% between tests, and the new system scored a perfect 5/5 in sentiment score.
Process of reorganizing components using post-its (my favorite).
Making it happen
A brand new library structure
To solve for design concerns, I decided to organize all of our components into a single, atomically-divided library in Figma. On the engineering side, the atomic structure would be repeated across libraries by way of a library refactor.
In order to bridge the disparities between design and dev, I linked each component in Figma to its documentation page in Zeroheight, which guides engineers to where components live in code.
Cleaning this way allows developers to transfer components from languages we’re deprecating in our stack to our current framework project-by-project instead of wholesale, saving us cleanup work later on.
Proactive refinements (WIP)
Synthesizing, refactoring, and pruning
Once what we already have is cleaned up, the final step is to combine duplicates and near-duplicates into master components based on function rather than form. When these are identified, variations on components will be differentiated within the master component using parameters.
