Tools, not rules
Crafting a design system that evolves with its users
Products are a reflection of the methods, processes, and cultures that produce them. A siloed company can create product experiences that feel disjointed. A thoughtfully crafted Design System solves for this, creating a commonality and cohesion across products and ensuring that decisions aren’t being made in a vacuum.
While a typical first step is for an organization to build and adopt a Design System (DS), that’s just the beginning — design systems don’t take care of themselves. They need to be maintained, updated, and evolved, just as products, customers, and businesses must evolve. How do you support your DS, ensuring that it grows as a true reflection of those that use it, and the customers it serves?
In the process of developing several significant Design Systems in recent months, argodesign teams arrived at informative findings as to what works, what doesn’t, and how end users benefit when a solid structure is established from the get-go.
Treat your DS like a product
In design, we often think about how the methods and mediums we leverage affect the work we produce. The least appropriate and least resilient solutions tend to be a result of a dearth of competing approaches. They come from a lack of exploration, and are an expression of “default” solutions.
If you don’t institute the protocols that ensure consistent execution of a DS, then it’s worthless. In short, you must design the DS for the medium(s) in which you will build and implement.
- Francis Carbone, argo Designer
In conversations with Forrester Research this year, we emphasized the importance of a product approach to developing a DLS and their resulting report agrees: “Smart design teams assign dedicated permanent resources, promote the system, and create ongoing feedback loops with product teams.”
Determine your audience
Identifying the primary users of your DS seems a logical assumption at first glance; it’s tempting to think of them as designers, with an additional consideration of how the components will manifest in products. However, there are usually many more potential audiences, so it’s important to consider each of those audiences’ needs and plan the growth of the system against those needs.
Who will be using it — designers, engineers, product and business owners? Do they need freshness or repeatability? What is their capacity for command and control, as well as driving compliance? The level of fidelity should be highly targeted, toward a goal of driving adoption and integration internally while also building for extensibility.
In our work with Sam’s Club, for example, we facilitated a workshop to capture how design, development, and product teams would need to leverage components, which mediums would fit best in their workflows, and how their needs would be represented in the ownership, decision making, and accountability of the DS.
It’s important to point out that a Design System team doesn’t necessarily need to include a member of every audience it is designing for. Instead, it needs principles and constraints built on the needs of those audiences, and that means treating the building of a design system just like a product. Consider the primary use cases first and build it to work well for those workflows.
In many cases that means trying to understand how a company’s product teams collaborate, and thinking about how a design system can help standardize practice and evolve with the teams over time. Just like any product, that means the DS needs an MVP prioritized around the most important use cases and product timeline to map out the growth of refinement of the system. You’ll know you’re winning when the non-designers in your product team start using the vernacular of the DS when assessing and making product and engineering decisions.
Develop a common language
When your DS is treated like a product, you therefore must have buy-in from engineering, product, and design. As any seasoned project manager knows, this is easier said than done and can benefit from unique approaches.
argo’s work with DreamWorks provides a strong example of what a successful system can look like within a creative context. While developing a visualization tool for the company, we needed to ensure the client could efficiently monitor progress and that the development and design teams could easily communicate — all remotely across 11 time zones.
The resulting tool we implemented, Storybook, sits in between the DS and the final product, translating between the two to ensure effective execution of the rules that were developed for the design system. A robust and confident combination of Jira, Figma, and Storybook provided an operating system for the design, a QA and documentation resource for development, and guaranteed a single source of truth between both. We now have a tightly integrated process between these entities and the live app, setting us up with a strong foundation and framework as we begin even more projects within DreamWorks.
More codified standards toward inclusivity
We are at a moment when our practices need to become more inclusive, but also navigating a time when there is even greater tension between exploration and expedience.
To be clear, this tension isn’t going anywhere. But we’ve made much more progress on base-effort accessibility of a system in the last decade than on more nuanced questions, like how to create easily navigable menu systems for screen readers or how to account for differences in attention or cognition. Considerations like these arguably account for much more of our perceived experiences with products, systems, and services.
- Scott Gerlach, argo Designer
Design systems could benefit from more codified standards. Naming standards as well as more extensive base libraries would go a long way toward helping design systems consider deeper questions of inclusivity. As it is right now, most systems get caught up trying to make themselves from scratch and questions of “what’s a component”. We won’t address any additional challenges until we stop addressing those challenges over and over.
Ultimately, with all Design Systems, it’s important to understand that they are never finished. They require maintenance, there will be updates to requirements, patterns will fall out of usage, and more. It is a constant practice of making and remaking.
- Cathryn Rowe, argo Associate Creative Director
It is an ongoing conversation that will continue not only in the design space, but within product teams inclusive of the varied disciplines that they constitute, as we strive to remove unintended negative bias in the products, systems, and services that are integral to our society.
