A Guide to Building a Design System Beyond Primitive Elements

Design systems should address these key principles to build complex components: discovery for composability, building for extensibility and driving consistent layouts.

You have heard the button story. There are several consumer-facing digital products across the organization. Designers and engineers are designing and building the buttons for these apps. Branding and marketing teams are not happy because these buttons never look the same across all products.

You add the time spent by the engineers and the designers to create the same (but different) things, and those buttons turn out to be costly.

A design system tries to solve this problem. Many design systems start out to primarily focus on basic elements such as buttons, inputs, radio buttons or links. But like any other system, a design system evolves past those primitive elements.

Complexity grows if you have several products within your organization. But a design system should solve for complexity based on shared values and language. It should not steer away from building a complex UI. Complex components such as cards, data tables, layout grids or charts are common among user interfaces, and a design system can drive the discipline required to create consistency in these complex UIs.

One example of a complex UI component is a card.

A card is more than a container with content. A card can be described as a UI design pattern that groups related information—think of a playing card. A card can be static, containing an image and/or a caption. It can also be interactive, with a button or a link. It can contain metadata such as date or tags and can come in different shapes and sizes. It can also have variations such as a full-bleed image or a default image with spacing around it.

Using a card UI component, let’s explore how a design system should address a few key principles to build complex components—discovery for composability, building for extensibility and driving consistent layouts.

Discovery for Composability

Discovery is the first step to building your design system component. Building a complex UI requires understanding shared values and language in your organizational ecosystem. Should the image in a card offer variations such as top or bottom? Should a card have a full-bleed image or be evenly spaced from a card container? Do all products use cards consistently? If not, how can a design system team push for shared language?

Below are some of the ways you can gather the design needs and help various groups recognize a shared vision:

1. Identify primitive components of a card—title, image, button, label, icon—these will serve as building blocks

2. Identify core content of a card—title, description, image, caption, content and metadata

3. Identify the gaps within your library by scanning your repository of components

4. Identify variations of a card component by auditing products consuming the component

By carrying out the steps above, you will understand the shared need of a card component.

Once the team has identified core elements of a card, the team should assess edge cases by casting a wide net across the organization to avoid missed areas.

Remember, a design system should give flexibility to adopters for composability. Discovery is the first step to identify those edge cases because if you don’t get adoption, building a design system can be a wasted effort. Make it as inclusive as possible by casting a wider net to understand the needs of your organization.

Below are some of the discovery questions that you should investigate:

1. Do products use cards as a list?

2. Do products use data tables within a card?

3. Is a card interactive, using a link or a button?

4. Can a card contain both an icon and a button or only one interactive element?

5. What happens when there is more than one interactive element leading a user to click on the wrong element?

6. Do cards look and feel the same on mobile vs web, or different?

7. Can the entire card be clickable? Or, in other words, wrapped around a hyperlink <a href="url">I am a fun interactive card,</a>?

8. Should the image of a card be zoomable?

These investigative questions should yield results that have shared needs across your organization’s product portfolio. Building a card goes beyond visual representation, and your discovery should also distill cards’ behavior.

Apply inversion to your discovery sessions. What happens if a design system does not give affordance to a use case? Will adopters extend the component by building their own components or by using the existing components within a library?

Giving allowance to adopters to extend components or not depends on your organization’s needs. It is worth exploring the extensibility of your components—your adopters will be thankful!

Building for Extensibility

Components need to be extended when a design system does not support or offer a variation a product needs. Extensibility plays a key role in the growth of a design system. This is because when a variation is extended by an adopter, it can be contributed back to the system for other teams to use. This helps scale and maintain the system. In other words, extensibility offers versatility that allows the product team to alter the design of a core component.

To ensure consistency in the structure and pattern, a design system team should have thorough documentation on Dos and Don’ts. Thorough documentation around design guidelines helps build and extend the core components of a library.

Let’s build upon our previous example of a card by listing Dos and Don’ts of design guidelines.

• Do use the card template when summarizing a small set of information.

• Don’t use it when grouping a large set of information.

• Don’t use it when providing more than one kind of interaction. A card can act as a link or should have a button to interact with.

• Do apply custom height and width based on your product’s needs.

Listing these types of design guidelines helps the product team extend the core components. Depending on how the library is built and used, provide all applicable guidelines, such as what can and cannot be imported in cards. Should all heading levels be imported or only certain ones? Removing any ambiguity will help drive consistency in user experience. Your branding team will be happy and thank you for conducting and documenting this exercise!

Driving Consistent Layouts

Sub-elements of a core component are separated via margin and padding. On top of spacing, you have to worry about the layout grid. Some of the questions to ask to drive a uniform layout of cards:

• How many cards can you have in a grid?

• Should all cards be of an equal height on a single row?

• What if the content for each layout is not consistent?

• Should the content be vertically and horizontally aligned?

• Should content within cards be responsive?

• Should you have fixed margins or padding?

Defining the relationship between spacing and layout is critical to creating a consistent user experience.

Wrapping up

To summarize, discovery is a key component to building complex user interfaces. This makes maintaining your design system easier once the component is built because there is a set of processes defined by the principles we discussed—composability, extensibility and layout consistency.