We’ve all dealt with the issues when someone is trying to talk about “that light blue button just below the thing with the sliding images” or when you feel the need to open the design document just to make people understand which component you are talking about.
The main reason we have these issues is the lack of proper names for the things we are trying to refer to. What starts with a small annoyance in daily discussions can turn into one of the biggest contributors to the poor communication between product, design and engineering teams.
A solid design system is a key factor to establish common understanding within the entire set of product teams, having a shared language in addition to that will make it function to its full potential. Although it takes effort and contributions from each product team, it is well worth the effort spent when the communication improves and the discussions go smoother.
Yes, it is no secret that naming things is one of the hardest problems in our industry. This article aims to give you some best practices and guidelines that will help you on your journey to come up with better names. Or if I can just make you re-consider your component/pattern names, I would still take that as a win.
What makes a “good name”?
Before we begin throwing ideas out to come up with names to different interface pieces, we should first define what makes a good name. The criteria for a good name can change based on your team culture and preferences, but we will go through some example points to give an idea for you to create your own definition of a good name. These are just my ideas and some suggestions from the literature I’ve read, though naming is subjective to some extend, so consider whether you want to use these based on your team culture.
Good names help team members who did not design or build the patterns understand their use. It doesn’t necessarily mean that just telling the name of a component should make people know everything about the component but it should give an idea about which use cases the component is designed for and what purpose does it fulfill.
As a very simple example, if a component is named “CTA button”, it is pretty clear that it’s not meant to be used multiple times in one screen. If you were designing the table you see below, the “CTA button” component would very likely not be your choice of component to use for the “Edit” and “Contact” buttons.
Good names help onboard new hires faster. Yes, we want to build a shared language, but we don’t want it to be a foreign language that takes months for a new hire to understand. A good name should ease the onboarding process of newcomers.
Let’s say you’ve decided to name your components after the Beatles song names (please don’t ?). It might take a long time before the new hire knows what to do with the “Hey Jude” component.
Though if we follow the advice from the previous point about purpose, we can get away with component names called “Lennon”, “McCartney”, “Ringo”, and “George” if for example these components always need to stay together as a group of four. You can even call the separator between these components “Yoko” but let’s not get into that ?.
Okay back to serious.
Good names are memorable. If you need to look up the name of a component every time, that name won’t solve your initial problem. One way to achieve this could be to limit the length of the names you assign, and try to keep them less technical. This way you can avoid having a component named “Prominent checkout box with thin borders”.