Actionable Strategies To Implement In Your Design System

Why should your agency have a design system?

Design is more important than ever and scaling design without setting standards is a myth. With every new hire, new ideas for color palettes, typography, and patterns appear in the product, leading to inconsistency and increased maintenance costs. Every new designer increases the design entropy.

A gradual increase in a design methodology equates to a gradual decrease in inconsistency and a gradual increase in the speed of software development. There is only one way to stop the growth of anarchy is committed to run a design systems process.

In this post, we are going to discuss the various strategies that should be included in a design system.

The Inventory

To begin the process of scaling your Design Systems, you must understand the current state of your design and development ecosphere.

If you think the experience your product provides is internally inconsistent and confusing, or the code takes too long to maintain – you need to prove it to get your team and stakeholders on board.

The best way to start is by making a list of all the different patterns, colors, text styles, and assets used in the product. The list is going to show all the inconsistencies and hopefully build you a design system case. Building a complete list takes time. You may want to select only a few activities to get the team and stakeholders on board and then continue when you have the entire team focused on the task.

Create the Patterns Inventory

• Take screenshots of design patterns or collect design patterns from design projects to list all the different versions of the pattern.

Start by collecting various examples of patterns from your product(s). Either take screenshots and paste them in one place. For example, your presentation tool, your prototyping tool, or project files and collect patterns directly from there.

• Examine the frontend code and talk to the developers about the architectural approach used in the codebase. Try to identify if the frontend architecture is modular and if you can use it to categorize the patterns in the inventory.

Often frontend developers work using a modular architecture that can be used to organize patterns in a design system. You can approach it with caution and a critical mindset, but never ignore what's already there.

For example, at Think360, our front-end developers break down CSS into elements, modules, and components. Modularity helped in ‘LESS’ files. We build a strong foundation for the system and make the inventory more actionable as our reference document for future sprints.

• If a modular frontend architecture exists, categorize your patterns in the inventory using categories from the architecture.

Take the patterns you've gathered from products and group them into categories. For example, if the lowest level of the frontend architecture is an element, then collect all the buttons and put them under the category 'Element Button'. You can also document a link to all the styling files associated with a given element. Doing so, you will not just communicate with front-end developers in the same language, but also expose yourself to a whole realm of inconsistencies.

• If the modular frontend architecture categorizes the pattern in the inventory.

Even if your ecosystem doesn't have a modular front-end architecture, you need to classify all the patterns you collect into inventory. You don't need to decide on the overall architecture of your design system yet. Simply find common categories for elements (buttons, form fields, sign-up forms, etc…) so the team and stakeholders can quickly notice where discrepancies exist.

Create the Colors Inventory

A typical source of design inconsistency is the set of colors used in a product portfolio. For example, inventory management of colors in our agency showed massive redundancies; slowing down the development process. Before the advent of our design system, we used 105 color variables with 40 shades of red.

1. Go through the code files and list all the color variables or all the colors used in the CSS files.
2. Note the number of places where a particular color appears.
3. Arrange the colors by a common denominator. Color can be as simple as hue, tone, and tint or uniformity (all grey, red, green, etc.)
4. Sum the number of different colors and note interesting anomalies (such as the number of different shades of red)

Create Typography Inventory

In a complex project, typography can be more complicated. The lack of a consistent typographic scale used throughout the project makes information architecture complex and difficult to understand for users. It also increases the cost of product maintenance due to code fragmentation.

1. By creating a list of text styles, you can show your team and stakeholders where styles become inconsistent. Walk through the UI and check all text styles through the browser console.
2. Pay attention to any inconsistencies in text styles across a project. Create a typographic scale by ranking text styles in order of informational importance (from H1 to small text). Create multiple scales if necessary.
3. If using a CSS preprocessor - note the mixins and variables used to generate the text styles and try to match them with the styles in the inventory.
4. In modern front-end development, CSS preprocessors are often used to generate ready-made text styles through the use of mixins (such as Sass mixins). Taking these simple actions outlined in the inventory helps you communicate with developers and makes the implementation of new typographic scales much easier.

Create the Icons Inventory

Icons provide essential context for the user experience and speed up the recognition of key actions in most interfaces. Inconsistent use of icons can cause extreme confusion among users and increase maintenance costs.

By creating a list of icons, you can help your team and stakeholders understand the pain of not having a design system.

1. Identify all icon libraries used throughout the product.
2. Flag inconsistencies in icons (eg; two icons from different families used in one UI, two identical icons assigned to different actions, two different icons assigned to the same action, etc.)
3. Check whether there are different ways to place icons in a product portfolio.

There are many ways to use icons. Inline SVG, SVG data as URLs, and icon fonts - talk to the development team, or browse through the code to understand what methods are used in your design and development ecosystem.

If different methods are being used, it is worth noting as this is likely to lead to incompatibilities and will further slow down the software development process.

Create Space Inventory

Space is the key component of any UI; designers and developers have to manage it efficiently. Add the different types of grids used in the products in your inventory and perhaps dive deeper into the padding in the containers to spot any discrepancies.

• List and document the grid system (if any) used in the product portfolio.

Get The Support of the Organization

Before moving forward with the system, you will need the support of your team and stakeholders.

Presentation to The Team

1. The interface describes the process of creating an inventory.
2. Present the major inconsistencies from each category.
3. Explain why these inconsistencies are detrimental to the user experience or can harm the software development process.
4. Present the creation of a design system as a response to the challenge.
5. Explain that building a design system is an ongoing process and you want to form a small team to manage the process.
6. Make it clear that all designers and developers will have the right to contribute to the system.
7. Get a clear 'yes' from the team members.

Presentation to Stakeholders

1. Explain the process of creating an interface inventory.
2. Pay attention to the numbers and their effect on process speed (shades of red, types of buttons, icon libraries, etc.)
3. Present the major inconsistencies from each category.
4. Explain why these inconsistencies are detrimental to the user experience or increase the cost of software development (average cost per hour).
5. Present the creation of a design system as a response to the challenge.
6. Explain that building a design system is an ongoing process and you want to form a small team to manage the process.
7. Emphasize that building a design system will help the company bring great experiences to market faster.
8. Get a clear 'yes' from the team members.

Build a Multidisciplinary Systems Team

You can build the inventory on your own, but you need a team to drive the design system as a continuous process. The team not only plans the system, but also builds it, implements it, and promotes it across the team.

Start by planning what you need to efficiently fix the inconsistencies listed on the list, and then consider which skills will help you manage the process in the long run. Initially, you may not have a team of full-time contributors, so be prepared to manage the team with part-time allocations.

1. List all the skills needed to successfully fix the listed anomalies.
2. List all the skills needed for the long-term success of the system (maintenance + administration)
3. Find people with the required skills.

You'll probably need well-rounded designers and front-end engineers, but some teams will also need the PM's help implementing certain tools in the development process or running sprints. There's no perfect structure, so you'll need to think about your team, product, and external constraints.

1. See the real-time allocation you can get from your team. Many organizations, in the beginning, do not commit full-time staff to the team driving the design systems process. You need a realistic time allocation that you can expect from each team member.
2. Clarify roles on the team and decision-making process. Make sure the team understands who is leading the team, who is making important decisions about different aspects of the system, and what the overall decision-making process will look like.
3. Decide on the length of the sprint.
4. Decide team meetings for planning and post-sprint meetings.

Finalize by bringing clarity to the agile process required for a design system.

Make Crucial Decisions and Establish Key Rules and Principles

Before your first sprint, assemble the team and discuss the most important decisions that need to be taken as part of the design system. Make sure the entire organization understands where you stand by finding solutions to each problem.

• Decide whether you are going to use existing technologies or introduce new technologies.

The design system may use a technology stack used in the product portfolio, in one of the products, or in some entirely new technology. Naturally, the less popular the technique, the less popular it is in implementing the system and getting teams on board will be more difficult.

For example - writing a React.JS system with CSS in JS when a company uses Angular with the LESS preprocessor. At Think360, we are building systems on React.js and LESS, which means that the Angular part of the application will eventually have to be refactored.

1. The distribution of the system is important. Decide how you are going to deliver the system. Are you starting with one team and one product ‘Or’ working in a product portfolio and taking care of special features? decide and committed to a point of view.
2. Decide what the KPIs of the system are. Communicate key rules, principles, and decisions to the entire team gather all decisions, rules, and principles and communicate them clearly to the rest of the team organization. Consider putting them all in a wiki, or listing them directly in your documentation Design System.

Build and Organize the Color Palette

Begin your design system process with dedicated sprints for integrating and implementing the color palette. Colors affect all parts of the system, so you'll need to organize them first.

1. Use a color list to identify primary/base colors. To identify base colors, examine which colors are associated with the brand and which colors are most prevalent in the UI. Aim to create a complete palette that has no accent colors associated with the primary color and no colors in the UI that are not represented in the palette.
2. Decide on the system of creation of accent palette colors. You can create a palette of accent (secondary) colors by making a series of arbitrary decisions (which can be very time consuming and difficult in some cases) or using some sort of functional approach. In Think360, we have used LESS functions (darken and lighten) to extract accent colors from base colors. This approach lets us create a comprehensive palette with human-readable, clean, nomenclature.
3. Test the color palette with contrast colors in the inventory. Make sure you match, replace, or merge all of the colors used in the current version of the UI to ensure that your new palette will serve the entire design team well. As stated in the Design System, there should be no colors in the UI outside of the color palette.
4. Apply a new color palette in CSS on a test server (consider using the preprocessor and create a list of variables). Plan an extensive QA to test how the new palette affects the UI. Make sure you follow WCAG guidelines. Ensure that all UI elements have sufficient contrast even after the introduction of the new palette as regulated by the Web Content Accessibility Guidelines.
5. Present the new palette and UI influenced by the palette to all product designers. Let product designers participate by testing new palettes and suggesting changes. You need them onboard to ensure that the new palette is being implemented and used in future projects. Remember - a design system not used by the product team is dead and unusable.

Finalize the palette

1. After testing and gathering feedback, finalize the palette and present it to the company. Add the palette to your design system document.
2. If you're using variables in the CSS preprocessor, make sure the names of the variables are documented in the design system's documentation.
3. Deliver new color palettes to tools used by product designers.
4. Make sure the new palette is going to be applied to Design tools used by your team (Figma, Sketch, etc.). For example, you can use our Design System library to ensure and manage consistency.

Build the Typographic Scale

The next part of the system that affects all the other parts is the typography. Not only do you have to decide which typefaces will become a standard, but you also have to create a consistent scale that will generate a predictable information structure across the product portfolio.

• Choose an Accepted Typeface and create a compatible type scale.

There are different approaches to creating a typographic scale. You can adapt the scale to serve existing styles, or you can try to create a harmonious scale using golden hues. Ultimately though your goal is to create a scale that will be enforced the existing and future inconsistencies will be corrected. When creating a scale, don't forget you are setting not only the font size but also the weight, line height, and other properties.

1. If you are using the CSS preprocessor then build mixins text styles. Mixins (Sass, in LESS) can be an awesome tool for managing typographic scale and generating the right styles in code.
2. Test the new typographic scale against the text style in the inventory Test whether you've covered all current styles. You must either match, replace, or merge the existing styles so that the new scale applies to the UI without leaving any text styles out of scale.
3. Implement the new typographic scale palette in CSS on a test server (consider using a preprocessor and building mixins). Create a test environment for the new scale to check its effects on the interface. Check out how the new scale affected the UI. Are all text styles covered by the new scale? Is everything easily readable? Does the new scale reinforce the correct information structure?
4. Introduce a new typographic scale and scale-influenced UI for all product designers. Invite product designers to test the interface and suggest changes at scale. Involve product designers in the process – as is the case with the color palette. Invite them to review the scale and ask them for feedback.
5. Finalize the typographic scale. After collecting feedback, testing, and iterating extensively - finalize it, make it part of your design system documentation and communicate it to the company.

If you're using mixins, make sure the names of the mixins are documented in the design system's documentation. Provide a new typographic scale for the tools used by product designers. Make sure the scale is reflected in the design tools your team uses.

Implement Icons Library

Icons are a crucial part of the visual language and should become part of the system. Finalize the library, choose an implementation method, and make sure all team members have easy access to all icons.

1. Decide which icons should be part of the system from the interface inventory
2. Decide what method of managing icons should be used to implement icons in the design system.
3. Discuss with the team what is the ideal way to manage and implement icons in your design system.
4. If you are changing the technology used to deploy the icons, deploy the icons to a test server and test them thoroughly.
5. Finalize the icon library to be used in the design system and add it to the design system documentation.
6. Distribute icons for tools used by product designers. Make sure the icons are easily accessible from the design tools your team uses.

Standardize Other Style Properties

The process for adding grids, space definitions, and basic style properties is going to be nearly identical to the procedure described for standardizing color palettes, typography, and iconography. When running this in your Sprint, make sure that:

1. Each standard part of the system solves the problem of inconsistencies presented in the inventory.
2. Testing involves product designers. Every change is thoroughly tested on the test server before implementation.
3. The final part of the system becomes part of the system's documentation and is communicated to the entire company.
4. Every part of the system is directly accessible in the tools used by product designers (Sketch, Figma, etc.).

Build the First Design System Pattern

Once all the building blocks of the system have been built, tested, implemented, and accepted by the product designers and developers, you can start creating patterns. It is a neverending procedure. The pattern should always reflect either the truth about the product or the aspirational state of the product in the future. Products continually evolve patterns in the design system.

Don't aim to finalize all patterns in one sprint or a series of sprints. Take them one by one and make sure they are implemented by the product teams so that you can gradually fix all the inconsistencies and increase the speed of product development.

1. Decide on the best architecture for the pattern in your design system. You can use various models of architecture or create your own. Atomic Web Design is a popular way of organizing patterns in a system. At Think360, we break down our patterns into elements, components, and modules, which reflects the modular architecture of our front-end code. No matter your naming conventions, make sure the architecture is modular and the terminology is understood by the design system team and the product team.
2. Choose a pattern that you will work on during the sprint (Example - Button). Make sure the pattern is using the right colors, typography, iconography, etc.
3. Make changes if necessary. Review code. If necessary, make changes to ensure that the component providing the pattern is fully encapsulated and can be implemented in any part of the product. Ask members of the design system and developers working on the product to conduct code reviews.
4. List all patterns that are being replaced by patterns in the system. Consult the product developers and designers and see if any are suggested. Deploy the pattern to a test server and thoroughly test it with designers and developers from the product team.
5. Finalize the pattern. Add patterns to your design system documentation. Document use and implementation guidelines. Test the documentation with members of the product team to make sure everything is easy to understand. Make sure the pattern is available in the design tool used by the product designers (Sketch, Figma). Make sure the pattern is easily accessible from the design tools your team uses.

Run a Sprint Retrospective

You should organize regular retrospectives of your Design System Sprint. Make sure your team is learning and improving.

Summarize KPIs for the first sprint

Include team discussion questions like

• What did we do well?
• What did we learn?
• What should we do differently next time?
• What can help us succeed as a team?

Questions for sharing individuals

• How did you do this sprint?
• What's Your Biggest Hurdle?
• Which things would be changed?
• What was keeping you up at night?

Final Words

In the past few years, design systems have become a hot topic among designers. Many businesses are investing more in design. Having a design system can be extremely beneficial for companies and teams that are growing and need to keep track of everything.

Because good customer experience is important. Using the above guide to design systems can help you achieve better customer retention and a better user experience. Implementing the above strategies also helps reduce design debt, speed up the design process, and build awareness and brand accountability across different teams.

Hopefully, applying the above strategies to your design system can help you see an increase in software development velocity and user satisfaction.