Building a design system is one thing, but having people adopt it and maintain it, is another. In this blog, I’ll talk about the next steps — after a design system is built.
During my time at Juvo, we deployed our app’s designs to different markets around the world. Our partners in these markets, 8 Mobile Network Operators (MNOs) use different languages and branding. Our app needs to be in these languages and be consistent with our partner’s brand. My colleague Melissa led and built a design system that reduced our deployment time from 1 month to 10 days before I joined the team. However, once the design system was built we encountered a set of new issues: adoption and maintenance.
Improvements on the design system had come to a standstill by the time I joined Juvo. The original team that consisted of engineers and a designer no longer met. The team simply didn’t have the resources to continue working on the design system. This concerned the design team as they began to perceive problems around adoption and maintenance.
Why wasn’t the platform that documented our design system being used by QA and engineering? How can we improve engagement and create excitement around our design system?
Melissa and I teamed up to answer these questions and improve our design system.
In our initial attempt to find solutions, we recreated exercises we had participated in at workshops and reviewed Medium articles on design systems written by trusted big tech companies — but, we kept hitting a roadblock. We didn’t feel confident applying these exercises and insights to our own design system without incorporating our engineering and QA teams. Any decision we made would eventually influence their processes and that decision might not be relevant to their needs. This realization sparked other questions.
What were engineering and QA’s processes like? How do their processes and needs differ? How did they use a design system and what would they use a design system for?
It became clear that our attempt in answering these questions and improving our design system on our own wouldn’t work.
So, we took a step back and spent a couple of months conducting user research. We individually interviewed colleagues involved in deploying our products designs across product management, design, front-end, back-end, QA and upper management. We asked them questions that reflected their positions as both stakeholders and users of our design system.
As stakeholders, how did they define a design system and what could our design system do for our company? As users, what are some difficulties they’re encountering in our current design system and what are some challenges in our deployment process that our design system could solve?
All answers were very different from one another, but conducting user research on our design system proved successful and led to three results.
We initially wondered why the platform that documented our design system wasn’t being used by QA and engineering. Our interviews clarified two things regarding this. First of all, engineering and QA did use the platform that documented our design system, but rarely communicated to one another that the platform existed. So internal communication was an issue. Additionally, the design team had tunnel vision. We were so focussed on the platforms adoption that we saw the documentation of our design system as our design system whereas many of our participants saw our design system inclusive of JIRA and Zeplin. Ultimately, we had to identify the best way to communicate the platform’s existence and the design team needed to widen our perspective.
We inadvertently created a roadmap with identified needs and problems experienced in our current design system and collaborative process as users. Many of our participants had similar needs and challenges they were facing. Mapping out our interviews highlighted what exactly it was we could focus on and improve.
Finally, we formed a team with a representative of each platform and department dedicated to solving the problems in this roadmap and ensuring alignment across the users and stakeholders of our core product. We expected user research to assist us in understanding our initial concern for the platform that documented our design system and to reveal a roadmap we could work with. But, we didn’t realize how much it would impact engagement. User research is human connection and because our findings reflected individual needs, the participants, to our surprise, were very receptive to the roadmap we presented and our request for resources to create a team (once again) to maintain our design system and ensure alignment and adoption across departments.