Finding your language
Dan Donald
Design systems can be a powerful vehicle to improve communication and collaboration. They’re also aspects that can take a lot of time and effort, not just at the beginning of creating a design system but how well it’s understood, adopted, contributed to, and evolves over time.
Great communication doesn’t just happen and can take many forms, from the methods used to the types of content we use to get our messages across. One of the roots not just of communication but the design system itself is the language we use and build up over time.
Starting with a shared understanding
It’s easy to make assumptions at the best of times but when dealing with a system that crosses specialisms and has many people that need to be involved either in creating it or on the periphery or as a stakeholder. The lexicon of language we build up around our work can bring people together as much as it can create a barrier to people getting involved.
After scoping the design system itself, it’s useful to give everyone clarity on what your design system actually is, so that initial term is well understood around the organization – what the design system is as much as what it isn’t. Over time, this taxonomy of terms will grow, so right from the beginning, you might want to think about using a glossary of some kind in your documentation. Does everyone know what a component is? Some terms we as designers or developers might talk about might not be known to people less familiar with the work that we do. Material has a good example of this and SuperFriendly has some useful definitions to get you started.
Going atomic?
As we look at how we might structure our system, we might look at Atomic Design as a potential method. Here, the levels of complexity take inspiration from the Periodic Table of Elements, starting with atoms building into molecules, becoming organisms then used in templates and pages. Using this terminology might work really well for you, or it may add confusion. Bringing people together to discuss naming is often a preferred way of reaching a consensus, but equally, having something to critique and have people’s feedback can get you a good result. At a previous workplace, we had layers from foundations, elements, patterns, and collections, you might have your own terminology for a similar structure. Adopting language can be a conscious choice as it becomes baked into the systems we create. Once people have learned this language, it becomes harder to change in the future.
How we talk about process
With the more engineering-based part of our solutions, there’s a lot of domain-specific language used already. Does everyone know what stages a component might go through from the problem space to live code? Is there a shared understanding of what a pipeline is, a build process, and types of testing? As we bring people together through working on or using a design system, there’s an opportunity to better understand each other’s worlds – not just designers having greater awareness of areas they might not’ve encountered before but developers considering the use of brand or concepts originating in design that might be new to them. This doesn’t assume a deep level of knowledge but gives us the capability to bridge domains more easily, ensuring that everyone feels a part of what’s happening around them.
Tokenization and abstraction
Design tokens factor into the understanding of language as they can at times have a taxonomy of their own. When naming tokens values more semantically, we often describe a value’s use case or intent. That means instead of a color palette of pink, red, blues, and so on, we might have a range from success, warning, error, feedback, structure, and copy. If we look at the BBC’s typography definitions, these use terms that originated from the roots of printed typography and so while not common everyday terms, they have a relationship to the values they represent. They are new terms to learn, as many abstractions can be. Within your team or organization, you can get feedback as to whether an abstraction is well understood or people are happy to learn. With that example, over time both designers and developers can know that an article heading should be set as ‘trafalgar’ and the tooling is in place to have the values associated with that. This abstraction then implicitly contains its use case font size, line height, tracking, etc, and makes this aspect of communication and execution pretty quick.
Consistency
By being more consciously aware of the language we use and providing people help with any terms they’re not familiar with, we’re looking to build bridges between all of the people involved in or using the design system. One inconsistency that can happen is in the components themselves. Sometimes differences in what a component is called can be mismatched between design and development through best intentions. That consistency is really key in ensuring we’re always talking about the same things. If a component is named ‘Button’ and there’s agreement that’s what it is, then regardless of technical execution (which may not always be a <button> tag), it becomes part of the system’s taxonomy. There’s no translation between domains that a button in design is a CTA component in code or may actually be multiple components.
In some ways, the language we use almost feels to me like geology in that there are layers of it that form the basis of everything else that we do. It’s easy to overlook but when done with intent, this is something we can design. How consensus is made may well differ between teams and organizations but knowing we’re talking about the same thing and reducing the barrier of entry for those engaging with the design system is incredibly worthwhile.