Unit 1: Intro to Design
Unit 2: Figma Fundamentals
Unit 3: The Creative Process
Unit 4: Color Theory
Unit 5: Introduction to Illustrator
Unit 6: Typography
Unit 7: Layout
Unit 8: Typesetting
Unit 9: User Interface Design
Unit 10: Design Systems
1 of 2

Components in Design System

Have you ever go back and forth copying and pasting the same design elements because they appear again and again but with slight variations in style and content? Think a blog article card, a button or a dropdown menu.

To save time and streamline the design process, we have to stop going to page 1 of our design document to copy and paste reusable design elements. In modern digital design programs, there are helpful tools for designers to save reusable elements in an easy-to-access and centralized library. These reusable elements are now more commonly-known as components.

In this lesson, we will learn how to establish a comprehensive component guideline for your design system.

Components can be seen as LEGO blocks that are built out of all the other parts covered above. They’re the interface and UI elements – for example, call-to-action buttons, form fields, and checkboxes – that make up the heart of the design system. Created by designers and coded by developers, they minimize the effort required to build a product. By reusing as many parts as possible, you can speed up the workflow, save time and avoid duplication, as interface elements don’t need to be recreated from scratch.

Let’s take a look at how we can start identifying components and document them in a design system. We will use Google’s Material Design system as an example.

Identify Usable Elements As Components

If we look at the “components” section in any design system, we will notice that they are all slightly different.

This is what the Google Material Design system looks like in the components section. Because Google operates under an significant amount of product variations, it needed categorization to filter the kind of components that are relevant to different platforms or product line.

The first step to documenting components is always doing interface audits and see which elements seem to appear again and again. Even styling might be slightly different depending on product lines, designers can document the most bare bone layout that the elements share.

For example. there might be different variations to the styling of buttons, but if the button is always supposed to be rectangular with a 5px radius, then the component library can represent the button in such a way.

Some companies, like Atlassian, even use black, white and gray to document components because it eliminates any distractions of styling variations.

Describe The “Anatomy” of Each Component

After components have been identified and categorized, each component must be given more detailed descriptions. One of the first ways to do this is showing the “anatomy” of the component – in other ways, show what smaller elements make up the component.

In the case of the bottom “App Bar” in Google’s Material Design system, there are 5 common sub-elements: 1. Container, which is the rectangular bar that goes across containing all of the other smaller elements; 2. Navigation drawer control, which is more commonly-referred to as the hamburger menu icon; 3. Floating action button, which is a plus sign that sits in a popped up position that contains action items when users tap on it; 4. Action icon, which is a search icon; and 5. Overflow menu control, which is a vertically-aligned group of 3 dots and usually indicates “more options”.

By documenting the “anatomy” of a component, the design system leaves little to no ambiguity for designers to implement standardized and reusable elements for future design across the board.

Show Variations of Components

Some components have variations that are best suited for different interaction scenarios and it is important to document them.

For example, the floating action bar can be moved to the right side instead of positioning in the center if content above it calls it calls for the button to be set aside rather than in the middle.

The floating action bar can also be eliminated when there is no action required for a particular screen.

When the floating action bar appears on landscape mobile orientation, developers need to make sure that the hamburger menu, search bar and the “more options” icon stick to either edge of the screen so that users can easily access them with hands.

These type of variations will need to be documented for each component that is used for variations interaction scenarios.

Document How They Are Used

It is also important to document when a component should be used. In the case of Google Material Design, the bottom app bar should be used on mobile applications only; and it should only appear where there are 2 to 5 actions available. It should not be used when the application already has a bottom navigation bar built-in or a screen has only one or zero actions available for users to perform.

Specify the Behaviors of Each Component

When a component is used, there may be variations of behaviors in different interaction scenarios.

For example, in Google’s Material Design system, it is specified that the bottom app bar can hide when users are scrolling downward as they focus on consuming content.

However, scrolling upward reveals the bottom app bar.

Providing Spacing Specs If Relevant

Although not necessary for all components, if possible, provide spacing requirements between inner parts of the component and with other elements if it is significant. This requires extended efforts at standardizing spacing and meticulous documentation, which may not be feasible for all design systems. A design team and company needs to evaluate how much it matters to have these type of standardization and be prepared to allocate ample time for the process.

Scroll to Top