Naming is hard: creating with intent and purpose
Dan Donald
It’s long been known, not just in the design systems community that naming things can be really difficult. I’d often refer people to Nathan Curtis’ article around the naming of design tokens as evidence of that and how you might form a strategy that can help.
Part of the friction we have in design systems specifically is between being too abstract or too prescriptive to initial use cases of our component. Too abstract and the meaning of a component can be lost, too prescriptive and we have nomenclature that doesn’t work at a systems level. There’s also a balance between the fear that our choices are set in stone and cannot be changed with being able to recognise that change is possible but may come at a cost. On our design systems journeys, we all learn about what works to solve our problems in our organisations so it’s fine to start with something, question it and refine as different or better methods come to light.
Maybe there’s a difference in approach that we can explore further…
We’ve got to start somewhere
A component might originate from solving a problem; building part or whole of a user journey. It’s not unreasonable when naming it to come up with something that fits that use case like “newsletter subscription form” or “more information card.” Only when we look to share these components as part of a system and deconstruct them that the naming can become cumbersome. That process too can sometimes become borderline existential as we look to find an appropriate abstraction that people can understand. A good place to start is thinking of it’s purpose beyond it’s initial use case. That might not be that easy if a component only has one use case so starting with what it is and what problem it solves is better than naming after how it looks or it’s current placement.
Intent and purpose
For flexibility, reuse, and potentially theming, we need our design system entities to be able to cope with change and have a degree of permanence about them; names that communicate more than what a thing currently is but also what it’s to be used for. One key thing you can do is consider your components as solutions to problems. In doing so they should start with a clear purpose; why do they exist? What problems do they solve?
In our documentation, having this as the first paragraph gives us content that cuts across our audience that may be composed of many specialisms. Starting with a name and purpose already gives everyone clarity before we’ve talked about brand, UI, or code. Fundamentally, what is this thing and why is it here?
Following from that we can be more intentional with our use cases. At times when working in a product team it can be tempting to see a component that almost does the job…maybe if we tweak it, a little… but this can end up with Frankenstein-like components that now try to do too much and contain too much logic for all their use cases. Having clear use cases doesn’t mean a component can’t be amended or improved upon but that needs to be a more considered system-level part of the process.
You could be too abstract like:
Box
Generic container to put things in, used for pretty much any component
…and this may be too limited:
News article summary card wrapper
This provides a styled container for us to put an image and news headline in for showing on the highlights panel on the homepage
What does good look like?
Finding your language and arriving at a consensus in your team/group around the design system is the most important thing as these are the people working with the system every day. Starting with some simple prompts might help:
- What does this component do today?
- What problem(s) does it solve?
- Does it currently have any other use cases?
- Is there anything it shouldn’t be used for?
- Are there any dependencies (other components it’s composed of or that consume it)?
Some of this can form part of your contribution model and guidance for any new components that may be created, should they emerge from product streams. This shared structure can help with integration into the system as the same basic methodology has been applied.
You might then end up with something more like:
Summary card
This should help the user to browse a number of summaries at a time in a visual way, encouraging them to click through to the full story.
Current use cases:
- For news headlines on the homepage and search results
- When showing recipes in the cooking section (see variant below)
But it looks the same as…
One common situation that can happen is when a component is needed and one if chosen because it looks right. A component’s appearance might only be similar in the short term, so careful thought needs to be taken around the purpose over appearance. Two components might start life looking almost identical but having them as distinct components gives clarity of their intent and use cases but more importantly leaves them room to evolve over time without impacting the other. A design system can and should allow for creativity so allowing new ideas or research findings to improve and help evolve a component may take those that start similar in different directions. In time, they might not resemble each other at all.
In this example, we have two components that have a lot in common in that they appear to share the same card-like base that have a space for an image and an area for some content. They have different jobs to do – one is a clickable summary for a news article and the other is a newsletter sign-up form. In the short term then may share the same base component but should be distinct so they can detach from using that if one needs to at some point, allowing for change.
Being bound by how elements of our systems are today can embed short-term thinking in our practices that starts with how we think about and name our components. There’s a sweet spot between this and the too-generic abstractions that lose meaning but it starts from clarity of purpose and being clear with our intent. Encouraging this line of thinking can help align people around the fact that our design system contains a collection of solved problems. As a consumer of components from the system, the thinking should be more around whether a solution already exists for the problem you need to solve, or part of it rather than whether a component exists that looks a certain way.
What naming conventions have you used? Where have you struggled or been successful? Where might you need help? Join zheroes, our Slack community, to discuss this, see how others have approached solutions, and chat about all things design systems. Sign up today for free at: bit.ly/zheroes-signup