Today, we hardly ever build anything from scratch. Legacy artifacts, in the form of code or UI elements, surround us. We’ve worked with design systems of varying maturity for multiple years. It’s a booming domain as the majority of design systems are under 3 years old according to Zeroheight’s recent survey. Between the organically evolved and multi-versioned constructs of enterprises and the open-sourced (of which a good collection is accessible here), there’s a custom solution for every company. And that’s the way it should be as there’s no master system that fits every unique need. Yet, what’s common is the notion that design systems keep falling behind in delivery – in other words, not fulfilling the promise of efficiency in collaboration. Secondary signs of poorly performing systems are unsatisfied contributors (usually designers and engineers) and end-customers faced with confusing experiences with the brand.
I believe that the main reason why our expectations are not being fulfilled is due to our narrow conception of a design system. When shaping digital product design development such as retail software, we tend to downplay the human factor – the mindsets of people, their customary workflows, and the plethora of tacit knowledge of company politics that affect daily work. When we face problems with the process, we rush to iterate the files or other artifacts in the system and often fail to notice the root causes.
In this blog I’ll suggest four important topics to consider when embarking on the next iteration of a design system. Written from a design consultant’s point of view, it also caters to in-house perspectives. Instead of step-by-step instructions on how to create the best system (you’ll find a good guide for that here), I encourage you to take a holistic view and consider the design system as the framework for best practices to solve customer problems in your organization. Continuing this line of thought, you might see an AI-assisted future where the product team innovates and prompts solutions to be tested directly in production – Brad Frost recently wrote on this subject. But as we’re not there yet, let’s concentrate on the present.
Imagine you’ve been given the task of reworking, refactoring, or rebuilding an existing design system. It doesn’t matter whether you are a designer or an engineer. What were the selling points to get the green light for the project – is the revamping necessary due to outdated technology or drastic changes in the organization? Or are you going to optimize something that already works, such as making the delivery cycle/time to market faster, increasing the frequency of releases, or accommodating continuous discovery in production? With more design-mature organizations, you might even be tasked to concentrate on employee experience or the carbon footprint of the digital product in question. Consider this task as the precursory goal but be ready to tweak it as you progress through the following four areas:
1. Consider why the system exists
Whatever the goal or task, I suggest you start by collecting information on the system to understand the reason for its existence: what is it, who is it for, who uses it, and how? Try to map out connections throughout the organization. For instance, depending on your product or service, the system might have undervalued or even ignored stakeholders outside of product management. By finding these hidden connections, you might begin to understand why the design system is not living up to expectations.
In a recent client project, this inspection led us to define novel use cases for A/B testing in production. The system only needed minor tweaks to enable this, but the potential had been ignored nevertheless.
2. Audit the design and code
Having a clear understanding of the initial goals compared to how people currently perceive and use the system, you can proceed to the design and code audit. The idea is to review everything in the system and assess its consistency, uniformity, and how streamlined the processes are. This task is daunting for one person, so plan before executing and talk to people! As a result, you’ll have completed an inventory of the system and will begin to understand the deviations in customer experience throughout all channels and touchpoints. In addition, you’ll have gathered knowledge on the technological ecosystem – how the design system really works in day-to-day use.
Auditing was a real game-changer in a migration project where we rebuilt the Sketch components in Figma. The refactoring of the system’s core elements over the years had resulted in outdated documentation and a mismatch between design and production. By doing the inventory, we were finally building design components that matched the code. The components’ new structure had another positive effect – designers didn’t feel the need to detach components as much as before.
3. Map out the overall workflow
When you begin to recognize the points where expectations and reality do not match, you might be inclined to pick the lowest-hanging fruit – and these might have been on your to-do’s already from the beginning. For instance, migrating design assets from Sketch to Figma or refactoring components to a state-of-the-art level might give an extra boost in productivity and make contributors a little bit happier. Concrete actions are also easier to rationalize and get buy-in for. But even though Figma provides a lot, it is simply a tool and your files are merely design kits, not the system itself.
Don’t get fooled by clever automation if there are bottlenecks in the process. It doesn’t matter how clever or in sync with the code design components are if the designers end up detaching components from the system. Investigate why this happens. Concentrate on understanding the flow from discovery to delivery through the perspective of various stakeholders. Take a holistic look at the system and aim for better workflows! Needless to say, this is a collaborative effort that you can facilitate. You might end up with a blueprint for the system that reflects your organization and its culture. However insignificant this document might appear compared to the megabytes of design and code, the blueprint depicts how to organize the elements in the system.
The aforementioned bottlenecks can come in the form of people’s attitudes, software, or badly aligned processes. We’ve all met professionals who feel systems are restrictive and take pride in fighting them. I’m not suggesting any DS penalty box and would tackle this issue with positive reinforcement. The misalignment between different software and in the processes should be visualized in your blueprint, helping you to fix the issue.
4. Evangelize to make it happen
Reaching the initial goal might require different solutions than what you were recruited to work on. Imagine your task was to introduce design tokens to fix inconsistencies in customer experience. Instead, you realized the best way to address the CX problem in this unique environment is to decentralize the governance of the design system and distribute design system contributors across the organization. During discussions with various stakeholders, you also made the right contacts to test your assumptions. As design systems are often cross-functional efforts penetrating the organizational matrix you might need to convince multiple stakeholders to be able to enact change. This is one of the reasons why design system contributors often need some evangelizing powers.
Finally, don’t get crushed by the complexity inherent in systems – often the best approach is learning by doing. Find a way to test your initial idea rapidly on a small scale. Join different teams or groups to experience their problems first-hand. Create a small success case and spread the word. There might also be some enthusiastic people to act as your advocates. Instead of doing drastic and expensive changes to the system artifacts, you may find ways to address the goals by tweaking the ways of working.
