Most enterprises build systems for several reasons - starting with system scalability, UX accessibility, user recall on pattern usage externally - and finishing with proper resource division, efficiency as well as collaboration internally.
The extent to which the system should inform the enterprise differs on individual business needs, of course. In this article, I want to focus on medium to large-scale design systems and how to build them successfully in order for the company to benefit from them and measure their success.
There is a large amount of different types of design systems out there on the Internet. However, there are a few industry front-runners. Some of the most case-study-worth systems I've added to a list here.
Google has built its own design system with additional resources included.
Newest Microsoft design system update - Fluent 2.
A system that adapts to various use-cases created for Salesforce.
Atlassian has built an extensive design hub that includes everything design-related.
Thorough guidelines to smoothen the workflow of Github users.
Adobe's comprehensive design system creates cohesive experiences across products.
UI audit is created to analyze all your products and the design elements they're using (Yes, especially that same button in all different shapes and colours), compare them, break them apart, and see what functionalities each element fulfills. Once you find more than one element that has the same functionality, make sure you group them accordingly to find inconsistencies and insights.
Based on the audit results, see what types of components your product uses currently and what design elements should be added to the design system for common usage across your teams. Once you've gained some insight into these design elements, you can start to structure your design system team's backlog.
Once you've identified your stakeholders, create communication channels for all involved. For now, most likely, not a lot of involvement from external teams will happen until you've launched your system, but make sure your users (business teams) are well informed about when to expect the new system, so they can plan their own roadmaps accordingly.
In this stage, try and find out all the technical requirements of your teams.
E.g. What coding language are the products coded in? Are there any framework limitations that exist? In what type of environment should we maintain our system? Etc.
One tip I found extremely useful when I started working with my first design system was to keep your designers and developers close but keep your POs closer. Higher-up stakeholders need to be on your side in this process, they need to advocate for your team and the result you are striking for.
I would even suggest showing them the results of your audit and explaining how the inconsistencies adversely affect the user experience in your business and how a new system can help to soothe those UX issues.
In the previous steps you have defined technical as well as product requirements, now it's time to combine all your knowledge. Choose the right design tool, choose the right development environment, and let's get to work.
The first thing when starting your design work is usually setting your atoms in place. Things like brand colours, system typography scale, component effects, and different grid types should be considered and set, so you can create your components based on this system definition, meaning scalably. I strongly suggest that in this phase you also work on your system Design Tokens, which essentially are a set of consistent and reusable design variables that store visual and functional properties, such as colours, typography, spacing, and more.
Side note - Tokens deserve their own article, I'll be publishing it soon.
Let's get to it, once you have your system atoms set in place, component development is arguably the most straightforward process in this whole journey. It usually takes two to three components for the team to get into a good workflow.
If your company has never had a design system before, it's likely that they will have a bunch of questions and lack of clarity about how to use the system correctly, how to know when a component is being updated, how to ask for a new component or an update of an exiting component and many more questions regarding your internal product.
For a more complex design system and enterprise structure, I like to create a communication channel with sub-channels for different goals. For example,
Newsletter (one-way communication)- challenges in which the design system team informs the enterprise about newest additions, updates, upcoming events and many more.
Development issues (two-way communication) - it can be that some components do not work as they are intended, make sure your users can reach you and ask you to fix what is not working.
Design issues (two-way communication) - similar to the development channel, this has the same intention, however, it will be for your design environment rather than code.
You can also think of creating communication channels meant for specific user groups or teams in your enterprise.
Side note - you can also create other transparent practices around your team's work. For example, having an open agile work board, which is updated as often as stand-ups happen. Or finding a way to inform the users about component updates right on your design system pages.
Make sure you measure your design system success with different metrics.
Firstly, you can measure your design system's general performance. E.g. Which components have the highest and lowest performance rate? How many times is one component detached? Which is the most detached component etc.
Secondly, measure whether you have actually reached your business goals with your design system. Think of how well it helps to fix UX inconsistencies for your users in your products. Are your products more aligned with each other? How consistent is the usage of components across products? In this step you can take the results of your UI audit and try to compare the results to your current statistics.
According to different time scales you will have different results, do not worry if in the first quarter after launching your design system team has, for example, an increase of requests from different teams regarding components. It takes time for your users to understand how to use new systems, your user curiosity does not automatically equal a bad design system, be aware of your users learning curve.
Regarding tools that you can use to measure your design system success, this will of course be an extensive conversation that will depend on what you're trying to measure. Is it your design environment or code? Is it an external or internal success? Are you looking for qualitative or quantitative data on your system's performance?
There are a ton of tools out there, that can help you automate and perform your research, having all these considerations in mind when looking for your ways of measuring, will help you to define the best methodology for researching your system.
Design system extent and size as well as application will largely depend on the enterprise needs for which the system is requested.
Primarily, your design system will be created to increase the efficiency of your product teams as well as increase your enterprise UX and visual representation all-in-all. It's crucial to measure your design system success, otherwise, what's the point of implementing something you do not know (don't measure) the impact of?
Additionally, most likely if your design system team has been successful in system implementation, it's very likely that the team will become a sort of main point for further business development team collaboration, communication, and innovation. This can of course be scary and time-consuming, but with elaborate and transparent processes in place, your success is almost guaranteed.
Good luck!
