8 Design Systems

Over the course of the past seven chapters, you’ve built out a fully-fledged mobile app experience, picking up the tools of the trade along the way.

You looked at existing apps for inspiration and uncovered their design foundations. You also discovered some neat patterns to address interface challenges, like navigation and forming an informational hierarchy.

Using what you learned, you built out a high-fidelity version of your app and used components to refine it. While you did all that, you also introduced a lot of flexibility in the process.

In this chapter, you’ll connect everything you’ve learned so far to understand how that information comes together in a design system.

Understanding Design Systems

At its most primitive level, a design system is simply a collection of components you can reuse and recombine to design apps built according to a standard.

Think of those components like Lego bricks, which you can combine in multiple ways to build new experiences.

Don’t confuse design systems with style guides and UI kits, which are collections of pre-styled templates for building screens. They focus on a much higher level of abstraction.

Design systems go much deeper, bringing coherence to an organization’s products. Think about it this way: In a large company, multiple designers work on the same product and features. When each designer tackles the project in their own unique way, it results in unwanted variations and inconsistencies in different features of the same product. That becomes confusing for users.

Following a guideline and reusing the same fundamental principles across features and screens brings cohesion and consistency, not only within a single product’s features, but also across multiple products offered by the same company.

An analogy that might resonate well with engineers is to think of it like extracting core pieces of business logic into reusable libraries or modules and leveraging them when building new features for your products.

Just like coding conventions and style guidelines, how you build a design system varies across different companies and teams to suit their unique needs. The process evolves over time.

Goals of a Design System

Although design systems vary dramatically from company to company, they all try to meet some common goals:

• Removing inconsistency: By breaking designs down to their most fundamental pieces — like reusable text, color styles and components — design systems ensure that the features and experiences you design have a consistent visual look and feel.

• Saving time: By investing once in building reusable components, future iterations become significantly faster than building everything from scratch.

• Introducing fluidity in the design process: Design systems are layered and interconnected. You use typography and colors to create components, and you use components to create screens. This layering makes revisions and future tweaks a breeze compared to making a change in multiple places, one at a time.

• Making collaboration and handoff seamless: By establishing consistency in lower-level details like typography, colors and components, design systems ensure that different teams can work on different parts of a product simultaneously without deviating from the brand’s essence.

If you think about these goals for a minute, you might realize that Cinematic, in the state you left it in the last chapter, already achieves most of them. You’ve been building a design system all along! Didn’t see that coming? This chapter will zoom out and help you connect the dots.

Cinematic has already decomposed colors and low-level typography details into different pages as reusable styles for your components to use. All it lacks is some cleanup and documentation. You’ll fix that next.

Organizing the Colors

Download this chapter’s materials, then open chapter-08-starter.fig in Figma. This file contains the final states of the components, typography and colors. You’ll start by organizing and documenting the colors.

Open the Colors page. Add a new frame on this page measuring 458 × 699. Name the frame Palette and give it a fill of #F1F1F1. This is where you’ll organize your color swatches.

Now, add a new text layer with the text Colors and give it a text style of Title.

Place this layer at a margin of 16 from the top and 32 from the left.

Next, move the circle representing the button/primary swatch, and place it below the title at a margin of 32 from the top and left.

Now, add a text layer to represent the color’s hex code, which you find by clicking the Edit style option next to the color style’s name.

Give this text layer a font size of 9 and use Chivo-Regular as the font. Place it at a margin of 36 from the left while aligning it horizontally with the circle.

Next, add another text layer to represent the color style name. Use the Section Header text style on this layer, and place it at a margin of 56 from the right side of the hex code.

Select the three layers you just added, and horizontally align them. For convenience, group them.

Now, move the circle representing the button/secondary swatch and place it below the group you just created at a margin of 24 from the top and 32 from the left.

Repeat the steps above to add a text layer for the hex code and another one for the style name.

Once done, tackle the remaining nine swatches in the following logical order:

• Text Primary
• Text Secondary
• Text Accent
• Text Muted
• Navigation Active
• Navigation Inactive
• Rating Positive
• Rating Neutral
• Gradient Poster

Here’s how the final version should look:

Now, delete the old palette artboard. By organizing and documenting your color palette, you’ve made it easier for your teammates to glance over the colors and their respective hex values. This type of documentation is especially beneficial for engineers, helping them use the correct colors when they build these layouts in code.

Now that you’ve cleaned up the Colors page, you’ll tweak the Typography page and make it a bit more informational.

Improving the Typography Page

Open the Typography page and add a new frame measuring 397 × 774.

Next, add a text layer to this frame with the text Typography and give it a Title text style. Place this layer at a margin of 16 from the top and 32 from the left.

Now, you’ll add information about each text style on this frame, namely the:

• Font family
• Font weight
• Font size

Start with the Rating text style. Add a new text layer to the frame and enter the Rating text style’s family weight and font size:

Note

Find information about each text style by clicking the Edit style button in the Properties panel on the right.

Place this 32px from the left of the frame and 24px from the bottom of the title. Next, place the Rating text style to the right of the new text layer at a margin of 68 from the left. Group the two layers.

Now, repeat the same for the Title text style. Add a new text layer for the style information, and place it below the group you created earlier at a margin of 24 from the top and 32 from the left. Feed the style information into the text layer, then place the text style to the right of this layer.

Similarly, tackle the remaining styles. This is how your typography layer will look when you’re done:

The typographic scale is now much more informational. The documentation eliminates the need for other teammates to inspect each style manually to figure out its specifics.

Cleaning up the Icons

For the final bit of cleanup, you’ll tidy up the icons. Open the Components page. The names of the icons and the context in which they’re used in the project are confusing.

You’ll fix that now. Change the name of the icons as follows:

• bookmarks to icon-watchlist
• remove_red_eye to icon-watched
• local_activity to icon-top-rated
• whatshot to icon-trending
• filter_list to icon-filter
• expand_more to icon-collapse

Here’s how the Layers panel for the icons should look now:

Now, anyone can see at a glance how to use the icons.

To complete the design process, you’ll look at how Figma takes care of developer handoff.

Handling Code Generation and Asset Exports

When building screens in code, developers target a multitude of device sizes and resolutions. This is difficult because they have to fit the same amount of information into a variety of screen sizes.

One of the things that’s often a mundane — yet essential — part of the process is getting the correct assets and imagery for a specific resolution and device scale.

Figma makes it relatively straightforward to export assets, like icons, in varying resolutions. You can export any UI element from Figma, but in this case, you’ll look at the icons.

Exporting Icons

Go back into the Components page and select the icons from the Icons frame.

On the Properties panel on the right, you’ll notice a section called Export.

Click the + button to add an export setting.

The export settings have three options:

• Scale: Defines how big or small the exported asset is. Use x as the suffix of a value to denote a multiplier, h for fixed height or w for fixed width.

• Suffix: Denotes the scale at which you’ll export the asset: @2x, @3x, etc.
• Filetype: The file format you’ll use to export the asset: PNG, SVG, JPG, etc.

While developers who have access to the design file can configure the export settings and obtain the assets, you’ll make their jobs easier by preconfiguring the settings as per their requirements:

For Cinematic, set the icons to 1x, 2x and 3x scales in the PNG format.

Generating Code for UI Elements

Another helpful feature from Figma is code generation for UI elements. Select any UI element — like components, shapes, frames or groups — and click the Inspect tab in the Propertiespanel on the right:

This will show you some reference UI code for the selected element:

Figma offers reference UI code for iOS, Android and the web (CSS only). Note that the code isn’t production-ready by any means. It only contains visual information like width, height, margins and spacing.

You’ll often need to do some tweaking to make that code scale across device sizes. Nevertheless, it’s a convenient way to quickly export the visual boilerplate when building the first version of the product in code.

Where to Go From Here?

Congratulations! With the tweaks and edits you made, your project is far more documented and flexible than before. Not only did you decompose your designs into their logical layers, but you also conveyed more information about lower-level details like colors and text styles.

Although the project you worked on targeted a relatively small app, the methods you learned will scale along with the complexity of your projects.

Larger apps that offer more features will have more flows to think about, more iterations to perfect and more components to build. They’ll also have more moving pieces and conventions to follow that will change as you switch between projects and teams. Still, your process will essentially boil down to the same fundamental methods you worked through in this book.

Before you wrap up this chapter, here’s an extremely helpful resource you can look to for inspiration and guidance when designing a new product. The publication from Figma, called Design Systems, dives into each aspect of building a design system, including colors, typography and iconography.

The best part about this publication is that it has a repo with design systems from popular products from GitHub, IBM, Zendesk and more publicly available for you to look at.

While not all of them are built on Figma, they offer a glimpse into how large organizations think about design and leverage their design systems. These examples show how a design system can effectively organize a company’s design strategy and also how different and unique design systems are.

Key Points

• Design systems are collections of components used to design apps according to a standard.
• Documenting the typography and colors of the design system is essential so these elements are consistent throughout the project.
• Figma’s assistive developer handoff features make exporting assets in varying resolutions easy.