Design System- Grouping and naming components
Today, most professionals working in the digital space are familiar with a Design System. Just in case you are curious about what a design system is?
A design system is a portal that contains guidelines, principles, and best practices that inform components and patterns to formulate an organization’s identity. Here is what it looks like:
- Visual identity: brand color, images, typography ….
- Principles: Voice and tone, brand values, objectives…
- Best practices: Accessibility, UX, training documents….
- Components and patterns: the building block of digital products
If you want to learn a bit more about Design System, here’s a really good article by Audrey Hacq on what is Design System?
Here are some design systems by different organizations to build their digital space:
Private sector:
- Adobe — Spectrum
- Google- Material Design
- Saleforce- Lightning Design System
- Audi — UI
- Apple — Human Interface Guidelines
- Shopify — Polaris
- Microsoft — Fluent
- BBC — Global Experience Language (GEL)
- Atlassian Design System
Pubic sector:
- Gov.uk — Design System
- Australian Government — Design System
- U.S. Web Design System (USWDS)
- NSW — Government
- Canada Post- Mercury
- Government of Canada
These are just to name a few and there are many others that are just as good.
Components and patterns
Before we talk about the different ways to group components, let’s clarify what a component is and how are they different from patterns, so we can get on the same page since different organizations use them differently.
Components are reusable UI elements that form the basic building blocks of digital space. E.g., Banner, Button, Checkbox, Spinner, Tooltip.
Patterns are repeatable, reusable combination of components that solve common user problems. E.g., ‘Cards’ as pointed out by Adobe is made up of Card container, Preview (image/ illustration), Avatar or logo, Action menu, Footer, etc.
Although design systems have a lot of information that makes them unique to every organization, components are an integral part of it. And that is what I will discuss today. Grab your coffee and let me show you:
- different ways to group components with pros and cons for each
- naming the groups
All from a UX/ product designer perspective who needs to use such systems to work every day.
Grouping components
Organizations, dependent on their size in the digital space, may contain anywhere from as little as 10 to 100+ library of components. Here are three different, most common ways to group them:
- Alphabetical order
- Complexity based grouping
- Functional grouping
1. Alphabetical order
Listing your components in alphabetical order is the simplest way. This is technically not a “grouping” of components, but worth a mention as it’s seen quite often.
Pros:
a. It’s a simple list in alphabetical order that is a no-brainer for the design system gatekeepers and its frequent users.
b. It is easy to scale.
c. It keeps the organization of the library simple.
d. It’s the best for the findability of components.
Cons:
a. You need to know what you’re looking for.
b. You need to be familiar with the naming of each component.
c. It can be a nightmare for a new member joining your organization.
c. It’s not the best for the discoverability of an alternate solution.
Findability and discoverability are two separate things. Learn more on it with this great article by Sumeet.
2. Complexity based grouping
This is classifying the components based on their ability to be broken down into smaller identifiable parts. This is a methodology proposed by Brad Frost in his book Atomic Design. This method is based on a framework of nested taxonomy as pointed out in this book.
Pros:
a. It works wonder for a mature design system and design system teams which has set rules and tight governance in place.
b. They’re an excellent choice for creative flexibility by combining atomic level items to form molecular and organism level components. Hence they need to be governed with very tight rules and a clearly defined vision.
c. It also requires a deep understanding of how the levels are defined; which needs to be understood by every team member of any given project (you need to know how the Lego blocks work together before you start making a building or a spaceship out of it. Hence a clearly defined vision- a building vs spaceship)
d. They are also a great choice when the teams are either relatively small or not as diverse.
Cons:
a. It needs tight governance.
b. It needs a clearly defined organizational level vision that everyone is familiar with.
c. The question of “what goes where?” can easily creep up as the organization grows. As companies grow, hire new programers, designers, planners, different business units, new ideas for color pallets, typography, patterns, page templates, marketing solutions appear in the digital product, grows inconsistencies, and increases maintenance costs. Every new hire increases entropy.
d. They run the risk of being a ‘dumping ground’ if not managed extremely tight.
3. Functional grouping
This is based on the usage of the component, the problem they are trying to collectively solve, AKA the function they provide.
Pros:
a. They are clearly defined by the common problem they are trying to solve.
b. They leave less room for misuse of a component and encourage consistency of user experience on a similar digital product no matter the medium/ device. Although Labelling theory in psychology is applied to people but is relevant in this case too.
c. They help findability and discoverability of an alternate solution (other similar components) that may be under the common (problem) umbrella.
d. The groups can be scaled in the future.
e. The familiarity with the name of groups coupled with the problem that you are trying to find a solution to; helps get to the solution faster.
f. Any project member, designer, or non-designer can get to the right solution to their problem as it is a very ‘fail-proof’ way of grouping.
Cons:
a. It requires oversight to make sure components are being assigned to the right functional groups.
Conclusion on the grouping of components
- Setting the users up for success is what the real challenge is. Our main job as UX professionals is to provide ‘fail-proof’ solutions to any problem.
2. Decreasing user's cognitive load is another main task we are forever responsible for. As clearly stated by Hick’s law
The time it takes to make a decision increases with the number and complexity of choices.
We need to reduce the cognitive load for the user by simplifying their choices. A user may or may not understand what the difference between an Atomic component vs Molecular component is.
3. Users always gravitate to things that they are familiar with as explained by the Mere exposure effect
Our tendency to develop preferences for things simply because we are familiar with them.
Give users the options they are already familiar with. Ideally based on the problem they are trying to solve. Every organization addresses the same component with different names. E.g., Bottom navigation vs Footer. It makes it very difficult for new members of an organization to find what they need. But, as a designer, for example, if it’s a navigation issue you are trying to resolve; identifying it with an issue you are familiar with, makes it very easy to find the solution.
A final recommendation for component grouping
Although the solution you may choose for your organization may be based on parameters that are unique to your setting but in most cases, Functional grouping will always make it easier and faster for users to navigate to the component they are looking for.
Naming the (functional) groups
Here are some considerations to keep in mind before picking names for a functional group.
- The name chosen for categories is how users will end up working with the components inside it.
2. An effective name of a category determines how the component will be used and helps to ensure that it’s used consistently by everyone.
3. Effective category names help the team use the components inside correctly and consistently.
So, what makes an effective category name?
- Avoid presentational names for groups.
- Describe the function of the components inside.
Closing notes
Grouping and naming components are unique to every organization’s structure, the size of their teams, their aspirations to scale and so much more. There is no ‘one size fits all’ solution. Designing a design system that can grow with time while keeping the entropy as low as possible will always be the challenge. A solution on basic cognitive principles will always result in a product that does not need re-thinking and revamping every time a new component is added.