Stop building Design Systems without a tracker
For a better system, a predictive blueprint, and a quantitative data tracker.
Hey there, hope you’re digitally detoxed! Grab your coffee and we’re good to go. This time you will probably need two cups. But hey — then you’re finally awake!
What to expect in this article: You’re in the second generation of your library or design system and got stuck in figuring out what’s the next logical step to generate that extra revenue within your company.
- The first part explains to you what system and product language we considered as milestones in our design system team in a fintech start-up.
- The second part tells you the ups and downs based on adoption and rejections, that comes with building a design system.
- And the last part explains to you how you’re making the design system more accessible in terms of usability, scoping, implementing the tracker and once you’ve normed it into your process it’s not that complicated.
We have been working with FIGMA and Storybook to create one source of truth. So, you will get an idea of how to build a tracker, and create the evolved process, ad verbum saving you tons of alignment hours on predictive insights. Let me tell you what worked and didn’t work for the design system team, which consists of that point of time of more than seven front end developers, two product designer, one product design lead, one tech lead, and I as UX design lead.
Where to start?
Start with solving actual problems. We identified the following: Running legacy apps and platforms, having duplicated components in the system on an application level, and experiencing stagnation within the enhancement process of our pattern library.
The usability of the library stopped at the documentation level and wasn't frequently used by PMs or tribes. The reason why they used the library was literally just the documentation. The solution for achieving the next generation of our library we all agreed on: The Design System Tracker!
The advantages of a tracker in a Design System:
- Make your Design System team metrics focused
- You can share a visual breakdown of your tracker with stakeholders
- The search functionalities for components in your system avoid duplicated work hours on already existent components
- Know which platform is using your Design System components
- Provide a context in between your shops and see which ones are lacking the progress of adoption
- Keeping track of the number of component releases
- Turn every team into a Design System contributor and bring them there
Before we continue, let me give you some clarification on the actual design systems and product language, that we considered ‘milestones’ in our design system’s master plan.
1) Consider the right system and language for the design system team, before you start building a tracker
(First system) Started off with a component library turned it into
(second system) a pattern library, and we are striving for
(third system) a design system.
My very own definition for those systems based on our current experience:
The component library was the necessity of our reusability of products, whereas the patterns brought the interconnectivity within our channels and communicating products. The system will come with a brand stance and knowledge, that feels worth sharing within the community.
Everyone’s talking systems but what about your product language? Shouldn’t it be well considered, too? Still felt that we were stuck in there, as you shall create unique and distinctive products, that origin from your brand and data sets. So, let’s have a look into that one:
(First language) Started off with the component language added
(second language) behavioural and purpose pattern and are forming
(third language) a design system language, which is company distinctive.
Adding behavioural (user value) and purpose (business) patterns into our product language is offering the opportunity to connect not just to the visually and UX-UI pattern-driven components with your customers — it’s connecting your products to your company itself.
Your system is now interconnected, it solves user and business problems, and is outstanding to compete within the market!
Fight for the adoption, and get rid of legacies!
2) Drive the adoption of your design system
As our team was facing a lack of adoption in our system we were also fighting for new components, that shall feed into our library. It takes time and patience to see the advantages of the library speeding up your design thinking process and delivery phase in specific.
Takeaway:
Experiencing rejections across departments when it came to contributing components into our design system, due to a complicated, nontransparent workflow for product managers and stakeholders, judged by the speed of delivery, and blocking interdependencies across tribes/squads, whether it's a PR or a design QA.
We faced an over admin burden to give stakeholders an ongoing and transparent overview of the adoption, as already mentioned, of our pattern library in our second life cycle.
Promises and expectations were predictive models, based on systems and mechanisms that worked for larger product companies, that said our design system team was just run as a chapter and layered behind product teams prioritization. How shall we even implement a tracker?
It needed an over-performing team, that values the design system itself.
3) Design Systems are coming with cross-collaborative alignments
What no one tells you: As a Design System Builder you can’t expect to run everything smoothly, as there is a huge amount of alignments and iterative feedback necessary to make or break it. Not even mentioned the extra ‘aftercare’ phases for almost everything, that come with a proof of concept for self-sufficient running teams. But you can make it!
4) The Blueprint (one week)
Create a conceptional blueprint and compare it with the actual process you’re working with. Make an audit of existing pattern libraries, methodologies, and tracker systems to pair it with your ideas. Without a revamped process comes no adoption of your system. Advantages of implementing the tracker are the greater and clearer picture of what your system and your digital products are in need. You can fill in those gaps. Our tracker metrics: library adoption, getting rid of legacy applications, and team progress.
5) Build the process first (took us three weeks)
First things first came with inviting the tech lead, product owner, and designer of each team to point out the flaws within the existing flows. Presenting a process diagram helps to socialize the adoption of your system.
We defined bottlenecks and listened carefully.
6) Iterate on the new process with the tracker (approx. one month)
We throw ourselves in the development of a carefully thought through check-in and buy-in system to include the tracker MVP, which held us accountable and gave the product owners reasonable tools to plan sprint cycles. We called the first month the ‘process beta’, and finished up this phase with a survey. Don’t forget reaching out to the tribes itself. Socialize it! One major key learning: You can't draft the perfect process, that fits everyone. But that’s totally OK.
Key takeaway: The teams resist contributing to your system at a high level of governance, and time invests if they feel they can do it easier on the application level. Your system needs to answer the why's: Legacies, scoping, and valuable usability. The tracker concept itself will help you to overcome biased pushbacks.
7) PDX + PX + DX for your tracker flow (two days)
Bring that extra knowledge of product design experience (PDX), product manager experience (PX) and developer experience (DX) into your flows. Try to take a step back and observe the current flows. What’s needed to create valuable insights for your stakeholders and what are the flows you are going to create according to the request processes within the tribes/squads.
It needed an evolved, data-driven and valuable usability overhaul of our pattern library.
Takeaway: What helped us to iterate on the tracker and process approach was mapping out the actual need from a project owner/manager, a developer, and a product experience designer/researcher
8) The tracker (four weeks, two sprints)
Conceptualize the must-haves for your tracking system, that generates the insights you were waiting for a long time. Those insights, that are based on your products and channels, that no one can generate for you besides yourself. Map out your problems, and start thinking of specific dashboards. Think of data visualizations, that can be shared easily with your stakeholders (that’s why we agreed on a dashboard look)have technical discussions within your tech team, and think about logics to pull the right data, using the API of your ticketing system. Create a simple UI, that can be reused out of existing components, to develop faster. There are no such things, that aren’t right or wrong.
9) Last but not least consider a team leaderboard in your tracker, that drives contribution engagement (one week)
Build the tracker into Storybook, ship it, and have a hidden query for your leaderboard ;)
So, what if you would create a tracker, that tracks the adoption, allows you to identify legacies, raises awareness of the performance coming from your design systems? What if you create a library that can be used by your PM, developer, designer, and researcher to plan and scope? Predictability comes a long way and if you’re getting there: Call it (just) a day, a week, a month, and the next generation of your system and make your Design System team metrics focused.
But please don't build a system without a tracker.
Thanks for reading my article. Hope you had great coffee. Tschüss, bye and until next time!
