Creating a design system can be a daunting task for any individual or team. While they involve some of up-front work, they'll greatly improve the overall quality of your website or product by allowing your team to communicate better, move faster, and stay consistent.
Here at UI Prep, we've developed a process for building a design system based on best practices learned from industry leaders and our own experience as product designers. In this article, I'm going to walkthrough our process of designing and documenting a design system in Figma.
A design system is a set of deliverables that facilitate the work of a team who's creating a website or product. It often includes styles, UI components, layouts, and behaviors. Each of these are designed, documented, and then turned into reusable code that's used to build a website or product. Creating a design system typically starts in a design tool like Figma, and is then handed off to developers. From here, designers and developers work together to grow and maintain the design system.
Design a few key screens in medium fidelity to better understand what your design system needs to support. If you don't know what you're designing, you won't be able to make the building blocks required to create it. This can be done in a design tool like Figma, a wire-framing tool like Whimsical, or even with pencil and paper.
From these screens, you should learn what general layouts and UI components will be needed. The designs don't need to be pixel perfect as they'll be replaced with the styles and components from the design system.
Now that you have a good sense of what you'll be designing, decide if you will be using a framework like Material Design, Bootstrap, Semantic UI, or Ant Design. Borrowing design patterns and UI components from a framework can make both the design and the development process much easier and faster. The downside is that your product may look and feel less unique, or have slower performance. If you do decide to use a framework, consult with your team about how much customization should be allowed.
Design systems and their website or product designs can all live on one design file or be split into multiple. Each method has its own strengths and weaknesses and should chosen based on project and team size.
Separating the design system from the website or product designs is a good way to keep files from becoming bloated and offers more control over who can view/edit what. If the design scope is very large you can even dedicate each major workflow to its own file. This offers a high level of control over team member access. The down side to this method is it can feel cumbersome going back and forth between multiple files to update styles and components.
✔️ Best for large design projects & teams
Keeping your design system and website or product designs on a single file makes the design process much faster and easier, especially in the early design phases. Styles and components can be edited on the spot without having to navigate to a separate file and "publish" updates. The downside to this method is your designs might eventually outgrow the single file and it can be difficult or impossible to transfer designs from one file to another. For example, in Figma, if you move a frame from one file to another, all of the styles and component instances used will become detached.
✔️ Best for small to medium design projects & teams
Create a clear naming convention that everyone on your team can agree on. This will keep your design system organized and make it easy to find, swap, or update your styles & components. An organized hierarchy can be created with a forward slash naming convention.
For example, if you have buttons with supported states, you could use the forward “/” naming convention like this:
For access to a wider subcategory of “related components” in the instance menu you can combine the last two labels, ie. button type (primary) and button status (default), by separating them with a dash instead of a slash. This is particularly useful for larger categories with many subcategories. You can see this in the example below.
Determine what frame sizes need to be supported and configure each of their layouts. These decisions should be made thoughtfully as updating the screen size or layout of 50+ screens can be very painful (even when using constrains and auto layout). Below is a good default set of frame sizes for any website or product:
Establish a color palette system and add a new style for each color variant created. Building a color palette can be an intimidating task, but at this stage, creating an organized system of colors is much more important than the colors themselves. Once created and applied to your designs, the actual colors can be updated very easily (see example below).
Every design system should have at least 5 colors: Primary, Accent, Success, Warning, and Error. Each color should then have at least 5 variants: Dark, Default, Light, Lighter, Lightest. This range of options is plenty to get started and will support all necessary states.
Black and white styles need to be set up a little differently since it's impossible to have a "darker" option for either. Each lighter variant should be created by reducing the transparency of the color (ie. Default: 100%, Light: 50%, Lighter: 25%). These variants will be used as text fill for Primary, Secondary, and Disabled states.
Below are some resources to help you get started:
Our team at UI Prep has created a LOT of design systems from scratch and we've gotten our styles down to a science. Use our free Style Guide UI Kit to learn how to generate and organize your styles, or use it as a starting point for your next design system.
Create a typography system and save each text style. Similar to color styles, defining the text properties is much more important at this stage than the font family. The font family can be easily updated, while updating line heights will likely require some refactoring work.
Every design system should have at least 5 text sizes: Headline, Title, Subheader, Body, and Caption. Each having a Light weight and Heavy weight option. When selecting the line heights, use Figma's automatic line height suggestion, then round to the nearest multiple of 4 or 8 to better align with your base unit.
Below are some resources to help you get started:
Add common icons from a large icon library that matches your branding (ie. arrows, chevrons, close, ect.). These will come in handy very quickly when you start building your master components. Add less common icons on an as-needed basis to keep your design system tidy and avoid any confusion around wether or not an icon is actually being used.
While it is possible to create your own icons, using a more established set like Material Design, Font Awesome, or Nucleo to ensure high SVG performance and easy developer handoff is recommended.
Based on the key screens you already designed, build common UI elements and turn them into "master components" so they can be reused across your designs. Front-loading this design work will quickly pay off when you start creating your website or product. All components should be built with the Atomic Design Methodology. First creating small "atomic units" then "molecules" then "organisms".
To keep everything organized, keep all master components on a separate page in you design system. Then group components by category and place them in a frame. The frame label will automatically become the first part of your mater components name. For example, if you name the frame "Input" the name of every master component on that frame will start with "Input".
Start designing entire workflows using your prepared frames sizes, layouts, styles, and components. Each workflow should be created in its own dedicated space, whether that's its own page or a separate design file.
This last step can be tempting to skip. You already know how everything works, why spend time documenting it? Documenting UI guidelines and rules will 1) force you to think more deeply about how everything should work 2) help fellow designers who might otherwise misuse or waist time figuring out the UI 3) help the developers when it's time to handoff your designs.
Documentation should be split into two areas: styles, and components. For styles, create a frame for each style type (ie. colors) and display examples of each individual style with written guidelines. For components, create a frame for each component category and (ie, buttons) and layout all the possible variations and states with written descriptions and example use cases.
Creating a design system from scratch can be challenging and takes a long time. That's why we created UI Prep, a designs system UI kit with all the necessary layouts, icons, styles, components, naming conventions, and documentation to start a new website or product. We use it as the starting point for every new project to save ourselves days of work, and so can you!
Download the UI Prep designs system to learn best practices and save valuable time on your next website or product!
🧠 Learn More about UI Prep Design System