“You keep using that word, I do not think it means what you think it means” — Inigo Montoya
User experience terminology is often learned on the job. You’re not going to win any friends at a party correcting people calling the visual treatment of a button an “affordance” instead of a “signifier”. Even if the confusion over those two terms is widespread enough that Don Norman commented on it in the newer editions of “The Design of Everyday Things”. Language is a game, and no one likes playing (or working!) with a pedant.
That said, the rules of the game we play by, do matter. The distinction between affordance and signifier matters. Conflating the two decreases the nuance of analysis one can apply to the problem. Russian has two words for blue. Goluboy (lighter blues), and siniy (darker blues), while English speakers just call both “blue”. English speakers perform worse on perceptual discrimination tasks than Russian speakers, presumably because they lack as strong a category distinction in their native language. Similar effects have been measured in other language pairings.
A visual example of goluboy and siniy:
https://richardnilsen.com/tag/goluboy/
Perhaps one of the most widespread conflations in language I see in UX circles surrounds the term “Design System”. It’s no wonder this term gets used in diverse ways. What is a “Design System” anyway? It’s a buzzy word. It’s use evolved over years, coming out of the convergence of several different design trend threads. I’m going to offer a definition for it, and why I think it matters.
Let’s look at some overlapping terms that get thrown around and often used interchangeably in this context:
- Atomic Design
- Pattern library
- Component library
- Design pattern
- Style guide
- Design language
- UI kit
- Visual language
- UX framework
- Design toolkit
- Theming system
- Human Interface Guidelines
- Widget toolkit
- Stylesheet
- React library
- Storybook docs
Or some other combination of the above words. There’s a lot of terms here and I could write an entire article trying to dissect the different nuances and contexts of these terms or how they arose. But I won’t.
I’m going to focus on Design System because it is the most generalizable term, and that generality of it is powerful.
Join a new product team and you’ll be told by devs “We have a Design System!” and you pull that thread and what they mean is “we have a CSS file that defines a set of styles or variables used across our UI” or “we have a React library that we import and leverage to build out our interfaces”.
And sure if that’s how you want to use the term no one is going to knock down your door and take you to UX jail, but doing so can reduce the capacity to address a fundamental coordination problem with Design Systems.
Design Systems are best thought of as a social contract. Your Design System is not the specific key value pairs in a CSS file, it’s not the code you import in to a project, it’s not even the UI kit you reference in your figma/XD/sketch file or the documentation outlining the voice of your content or the right and wrong ways to use components. Rather, the Design System is the actual existing and immanent system that organizes your product, however well or badly that may be.
To quote Stafford Beer:
“The purpose of the system is what it does.”
You may have some docs that say “Buttons have a border radius of 5px and are this hex-code of blue”. But your Design System IS what the actual full existing collection of buttons in your products, and the social agreement between stakeholders that has produced it.
This definition of Design Systems as the actually existing social contract between stakeholders is important because it allows us to more clearly understand and discuss Design System work as it happens in real product teams, and not just in the abstract presentation of some powerpoint on the speaker circuit.
If a Design System is the Figma UI Kit, what does the dev team do when they’ve inherited a disorganized collection of products that doesn’t adhere to this standard passed from on high? If the Design System is just the React library that the devs chose to implement an interface through, how does a designer contribute or extend that system, especially if the devs mix and match across libraries as suits their needs or ease of development? What does a product owner do when trying to coordinate across products with other product owners?
Conceiving of a Design System as a social contract puts everyone on the same page. This social contract is tech agnostic. It allows coordination across product contexts, whether that’s a Drupal website, a collection of CRM internal tools, branded email templates, a native IOS application, or a React web application. A Design System doesn’t even have to be restricted to the digital space either, industrial design, content guidance, all these things can be included!
A Design System is at root, a political animal. Not political in the sense of partisan government operations, but in the sense of the coordination and governance of interpersonal work.
Understanding this is important because it moves our focus away from the distractions of the technical or aesthetic. People have all kinds of taste in UI, and resolving those issues is primarily a matter of negotiating between human beings. No amount of A/B testing, or pointing to “well Apple does it this way” will resolve this. At the end of the day you will have to work with the people on your team/s.
What should I do? The first step of organizing your Design System is to document it. The second step should be to establish a governance process to manage it. Nathan Curtis has an excellent piece of writing I recommend for figuring out which model is right for you. I also created a design token focused design operations hack-pack for federated design system governance here. This process requires the involvement of stakeholders. Rather than thinking of the work of a designer as that of a lone creative genius, it’s best to think of it as the role of a facilitator.
Navigating the complex terrain of user experience terminology and the concept of a Design System necessitates both precision and adaptability. Understanding a Design System as a broad, socially constructed agreement rather than a mere collection of components or documentation underscores the importance of collaboration and governance in creating cohesive and effective design solutions. This conceptualization highlights that a Design System, much like language itself, is not just about the technical details but about how it facilitates coordination, governance, and shared understanding among diverse stakeholders. By focusing on documentation and establishing a governance process, teams can navigate the complexities of design work more effectively, transcending technical and aesthetic disagreements through robust sense-making processes.
