How to name UI components

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…