How Design System Maintenance led to Faster Turnaround Times and a Happier UX Team
Not to be all ‘Marie Kondo,’ but this tale of tidying up resulted in very positive results for our design team.
Every product designer knows a good design system can help designers work faster and more consistently. Strong systems house a set of reusable design components that provide pieces of UI and UX that can be used in different configurations to create a variety of user interfaces. But like every important work tool, they require ongoing maintenance to remain useful. That can be tricky for busy teams to manage.
Q4’s design system is in Figma, which allows us to customize components using variants. Figma’s variants provide flexibility that enables designers to quickly create user interfaces without having to rebuild groups of components over and over again, which reduces the risk of errors. Components also help our team make quick decisions and bring consistency to our designs across all of our Q4 products. They make us faster and better.
Like all databases, it’s important for design teams to regularly groom their design system as the component list grows and as the team scales. As additional products are developed and old products enhanced, new components and variants are continuously being added to the library. As a result, things can quickly get out of hand.
Warning signs that our design system needed a clean up
We didn’t notice how bad things were until we started scaling up our team. As new designers came on board, they took longer than expected to onboard and ramp up when it came to using our new design system. They struggled with accuracy, and they were slower to complete their work than they liked. They were challenged by having to continuously ask for help.
🤔 Problems:
- Components were difficult to find
- Components were difficult to use because they included incongruent or broken variant properties
Frustration was also growing among the seasoned designers who were spending considerable time helping our new staff find their way around 😤.
What became clear was that our process would never make sense to anyone who wasn’t here before we migrated from Sketch to Figma. During the migration, there wasn’t time to correct the numerous issues created when we imported our files. Ironically, this led to designers developing time-consuming workarounds … And then we just got used to it.
But without this historical knowledge, our newer designers were lost — and would always be lost. It was time to clean up.
The main reason it was hard to find things was because the information architecture of our component library was relatively flat. Components were not grouped in a meaningful way. It needed to be rebuilt and reorganized the right way. But what was “right?”
Addressing problem #1: Making things easier to find
To make things easier to find, I deployed the following methodology:
1. Interviews with the team to understand their current process so that a new solution could map to their working styles.
I found that, for designers to find what they needed, they either scrolled through the list of components or conducted a search using a keyword.
Designers who used the list had to scroll for a long time to find what they were looking for. Designers who searched for a component had no trouble finding a ‘button’ component for instance but had a hard time finding less obviously named components.
2. Researched well-known design systems, like Shopify Polaris and IBM Carbon, to understand the taxonomy these companies used for naming components, how they grouped components together and what those groups were named to aid in finding the right one. This involved reviewing Figma’s best practices documents to understand recommended ways to file components in the tool.
3. Created a proof of concept, using Frames in Figma to group components together, and provided a name for that group that would help designers find components more easily. Using Frames to group components provided a folder-like structure in Figma.
4. Shared the proof of concept with the larger team and gathered their feedback to refine our new filing structure and proposed naming conventions. I published these changes to the design system. The team was ecstatic because it was immediately easier to find the components they needed. One hurdle had been overcome!
Addressing problem #2: Difficult to use components
It took the fresh eyes of the new team members to help us identify all of our many, many workarounds — that’s how ingrained they were in our process.
Designers were readily sharing their pain points with funky components, but it was hard to capture all of the elements necessary to evaluate and fix anything on the fly. Sometimes I’d see things raised in internal communication channels or hear about them on team calls in a one-off and sometimes undocumented manner, but we needed a process to share and capture all the relevant information.
Here are the steps I took:
1. I created an error-reporting template using our task management toolkit. This allowed designers to report issues in a way that enabled anyone on the design team to begin working on that task without requiring any additional context. Each task required:
- Add the reproduction steps you took to come across this issue.
- Document what you expected to happen.
- Include the component name and screenshot for visual context
This was a great start because it provided a comprehensive record of known issues. Still, we weren’t making progress on them because they weren’t being fixed in a timely manner. There were still too many unknowns to grapple with. We lacked guiding principles about how to plan and organize our components from a holistic and consistent standpoint.
The situation required designers to review unresolved tasks to determine if their issue had already been reported, which added steps to their process. I knew there had to be a more efficient way to get a higher-level view of the problems that the whole team was experiencing.
2. A comprehensive review of component issues was in order. Another product designer, Shreyak Shah, jumped in to help. He devised an asynchronous activity where designers were paired up to stress test the design system and document their pain points. Each pair worked together to test for unexpected behavior when resizing, changing variants, and overrides, or modifying colors and states.
3. Next, I conducted a workshop to discuss the issues and find themes. Learn more about design workshops at Q4
4. From here, we created problem statements that clearly identified all the issues. The problem statements provided principles that we could apply across the design system to bring consistency to how each component’s variants and properties worked.
This was the missing link! These principles were just what we needed to start streamlining our fixes and speeding up our work!
A clearly defined path 🚀
Our design system maintenance backlog now includes a comprehensive set of design tasks that encompasses all the improvements we need to make to our components.
Each task includes principles to follow and what components they apply to. And because the whole team participated in our big-picture workshop, we now have all the context we need to address our backlog faster than before.
Finding time to save time
Next on the horizon for our team is working on a way to prevent this backlog of issues from happening again. We’re now looking at building regular maintenance of our design system into our usual process, no matter how busy we are.
If you’re interested in learning more about our process and toolkit, please reach out to me directly 📬
🤓 Interested in joining our Product Design team and working together with us on challenges like these? Visit our Careers page and find out more.
