Shot by #<User:0x0000559f20abc150>

Art by Cody Cai

How to build a Design System from scratch

Mokriya is a user-centric design and development team helping top businesses like AT&T, Twitter, Salesforce, Intel, Google, and Verizon build technology that revolutionizes how customers use their digital products. Today, Product Designer Cody Cai shares Mokriya’s general process and approach to building out Design Systems from the ground up.

Mokriya has been receiving a lot of work regarding Design Systems, especially from enterprise companies with multiple products within their portfolio. Design Systems are becoming increasingly valuable because they create one coherent experience across multiple products and platforms — enabling consistency, speeding up workflow, and improving user experience. It’s a way for disparate product teams within a company to design and develop product experiences in alignment to a set of core principles, styles, and patterns — in other words, an official design language.

Getting Started — Design and Development Audit

To begin building a Design System, we first work with a company to identify the users of the system. By speaking with the users, (i.e. product designers and developers) we are able to understand the extent in which they want to leverage a Design System within their day-to-day workflow. From here we can assess the type of Design System best suited for their company (Is it strict or loose? Is it modular or integrated? Is it centralized or distributed?).

Although the requirements of a Design System may change from company to company, at its core, a Design System is comprised of three elements:

  • Design Principles: A shared set of criteria on how to approach design across the organization.
  • Style Guide: A comprehensive set of usage guidelines regarding the brand identity (i.e. color, typography, spacing, grid/layout, icons, illustration, motion, etc.)
  • Component Library: A glossary of commonly used interface elements that can be scaled to multiple products.

In order to inquire about what elements of the Design System a company may already possess as well as additional elements they need developed, we run a design and development audit on their existing products. This audit works as a way to keep track of existing styles and components that could be a part of the Design System and to understand the context in which these elements are being used. Once we have a strong grasp of the existing styles and components, we can fill in any gaps and prioritize these into a Design System development plan.

Our Approach — Prioritizing Components

Our development plan starts by prioritizing the atomic levels of a Design System such as typography styles, color styles, and spacing rules. We refine these style rules first because they ultimately affect molecular elements of a Design System such as basic ui components (which can be made by a combination of typography, color, and spacing styles). We then build out the basic reusable components (i.e. buttons, dropdowns, input fields, etc.) because these would be the building blocks for more complex components which may contain multiple basic components within them. For example, a modal component can be a combination of a card component, text input component, and button group component.

Atomic Design — a methodology by Brad Frost.

By starting with the smallest ui elements we build the essential foundation for a robust Design System. Before we realize it, the Design System will grow to host over hundreds of different components with permutations.

Testing the System — Make it & Break it

Whenever a component is built, it goes through extensive testing to make sure it follows the design principles set forth by the company as well as meeting the following criteria:

  • Fluid: The component can be scaled to the designer, developer, and user’s needs.
  • Accessible: The most common components and design patterns are accessible to all users.
  • Consistent: The existing atomic foundation of colors and styles are used. Evaluate if particular variations are necessary or could be simplified.
  • Function: The component has ease-of-use; therefore, simplify the anatomy of each component as much as possible so that every design decision is purposeful.

With this guiding criteria we can ensure that the Design System meets both design and development expectations.

After extensive iterative testing, each component upon approval is added into the Design System and polished to make sure the layer names, layer ordering, symbol structure, and symbol hierarchy are easily understood by designers who did not build the patterns. Simultaneously, these components will also be taken by a developer and converted into reusable frontend code that will be deployed to future products.

Documentation — Be Thorough

Documentation is a critical step during the development process because it acts as a medium to empower other designers and developers within a company to utilize the Design System. After a component is complete, we provide any additional design notes explaining the purpose, intended behavior, and best practices of each component. This is supplemented with additional development documentation such as component code snippets.

Tools like InVision DSM allow designers to simultaneously create and document components.

It’s important to note that documentation shouldn’t just be written once and then left alone forever. Design System documentation should be a living and breathing document that evolves over time.


Balance: A design system needs to have the appropriate amount of balance between offering a comprehensive set of rules, guides, and documentation while also leaving more space for experimentation.

Integration: Create a design system that meets with designer’s and developer’s workflow. The more integrated the design system, the more likely it will be adopted and widely-used.

Organization: Plan the organization and structure of the design system early in the process. Maintain a glossary or some sort of way to keep track of the components and prioritize through a road map. Documenting throughout the development process drives adoption and clarification.

Overall, Design Systems create a bridge between designers and developers that allow for faster ideation at a fraction of the cost. Rather than focusing on the nitty gritty details of design or development, product teams can focus on building quality user experiences that remain consistent across a portfolio of products. Design Systems are quintessential in developing evolving products that are scalable and everlasting.

Building a Design System components design systems dsm illustration mokriya pattern product shape style guide system ui ui kit

Building a Design System

by Cody Cai for Nagarro

An illustration I did for our latest Medium article about Design Systems. @Mokriya has been receiving a lot of work regarding Design Systems. Learn more about our general process and approach in our latest Medium article—Building a Design System from S...

View on Dribbble

Want to learn more about Design Systems? Check out What are Design Systems?.

Find Mokriya on Dribbble, Twitter, Instagram, and at This post was originally published on Medium.

Find more Process stories on our blog Courtside. Have a suggestion? Contact