Why design systems are implemented

When to Implement One of the design systems 

Here are some more specifics if you’re unsure of if you should put in the time to make one. This is actually the first step in creating a design system- finding a need.


When to Implement One of the design systems

Note: This article is a continuation of a previous article about what is a design system.


What does incompetence mean to designers

When you’re starting to get redundancies in your code because you have different designers who are creating a lot of the same items.

it might be a good time to create a design system.

Your organization might have multiple websites and they should all follow the same guidelines.


What is the scale for creating a design system

When your organization has been growing a lot, and you've got enough people that start touching the design is when you start to need one.

Ideally, you would want to make a design system before it’s too painful and before the output is very slow, but usually, companies only think about creating one after the fact.


Getting Buy-In 

Uphill Battle

It's hard to sell a design system because people know that the resources they spend creating it are not spent on actually building and shipping a product. So definitely expect opposition!

Find Out Who is Involved

Think of all the people who will be affected by it. This includes not only designers, but also engineers, program managers, stakeholders, the product team, and work teams such as marketing and legal.

Do Preliminary Research

Before talking to anyone, you should do your research. Print out as much documentation to back up why you think this is a good idea.

Get Consensus

Since there are so many different groups that the design system will touch, you need to get consensus from all different groups of your organization. This can be difficult for larger orgs. It only works if people use it though, so adoption is very important.

Start with Peers

Before going directly to the top, get advocacy from your peers. Find other people who are passionate about the company’s brand. Once you have strength in numbers, then you can begin to sell it to the people with a budget and authority. If you try to please too many people, you’ll lose momentum. It might be best to have one liaison from each team.

Show Value in Their Language

Start educating your initial few folks first, and train them to sell it like you. Have them explain what it is and what its benefits are. Be cognizant of who you’re talking to. Ask each team what their problems are, and make sure you’re talking in their language and what’s in it for them.

For developers, their problems are time reworking the code and confusion around what the latest UI is. For them, it’s good to show visuals of where the inconsistencies are.


For the business side, their problems are money and the image of the entire brand. Don’t say ‘we need a design system’- explain why. Show them real data of the time spent creating specs versus actually creating new designs. This would show them how you would save money in time spent on redundant efforts. And talk to them about how it’s a better experience for the user if the brand is cohesive.

Be Realistic

Show estimations of how long it will take, and be transparent about what things might be pushed back when you instead focus on this. Listen to their concerns, and meet people where they’re at.

Core Purposes

At the end of the day, you have to stick around one primary goal. Everyone wants the company to do a good job. So this would be best for business, and probably best for the user.


Design Principles & Plan

Next is where everyone converges on their ideas. In this step, you’ll want to include as many people as possible. Ask everyone for their values, vision, methods, and goals.

Determine Design Principles

These will be the thing that people reference when there’s a problem. Here you’ll want to get everyone involved. Get them started by asking some basic, open-ended questions. Ask them what they think is most important to the business. Think about what’s unique about what you’re providing.

They can answer this via polls any way you want- in email, 1:1 interviews, or google forms- anonymous or not. When you start to hear the same things, that’s where you’ll find your principles. List them in order of priority.

Determine Business Goals

Determine how your success will be measured from the beginning. This includes the cost and time required, what the priorities are, and the strategy to follow through on those priorities. Look to management for these answers.

Resources/ Who Creates It

Figure out who is going to be the team that’s making the design system. You want to have collective ownership with multiple people owning it so that when people leave, that knowledge isn’t lost. There are a few ways you can go about this: a solitary, centralized, or federated design team. Check out the list on the next page.


How will you build your design team

BRAINSTORM | Questions to Ask Your Coworkers

Use these questions as a guide to help determine your design

principles and plan:

  • What is your vision for the company?
  • What do you value most?
  • How do you measure success?
  • What are your obstacles?
  • What methods do you use to do your work?
  • What are some areas of risk that you foresee?

Use this space to brainstorm principles.


Take a UI Inventory

Next is where everyone converges on their ideas. In this step, you’ll want to include as many people as possible. Ask everyone for their values, vision, methods, and goals.

UI Inventory Tip:

Focus on things that are more specific to your organization. For instance, Netflix might focus more on advertisements, while the tax company might focus on forms and data entry.

Go Through and Audit Everything

Find out what's inconsistent. One way to do this is to find whatever is wrong. So go to every screen you have on every platform and look for the inconsistencies. Group them into different categories, such as navigations, dropdowns, headings, etc.

Then group them into subcategories, like button states. Another way to do this is to find what is right (this method works if you already have a large number of projects to search). Look at what you already have and find the styles you want.

Physical or Digital

You can either do this UI inventory digitally or physically. If you do it physically, you would print all of the pages out, cut them up, and find patterns that way.

This way is a fun tactile way to get more people involved. You can also do it digitally by taking screenshots of all of these items. There are great resources out there that you can use to help guide you, such as UI inventory worksheets.

Consolidate

Once you’re done exploring all of your existing interactions, you can consolidate what you have. Start reconfiguring them into repeating patterns. Once you do that, you can start to create one master file or URL where everything is contained to be reused.


Build It

So now you’ve done your UI inventory, and you have a list of items that you want to solve and start reconfiguring and consolidating.

Fun Tip: Give your design system a name! Trello’s is called Nachos (”It’s all about quality ingredients”), Zendesk’s is called Garden (”Where we grow UI components”), and Microsoft’s is Fluent (”The physical world is our vocabulary”). Their names relate directly to the tone of the brand, and it matches their catchphrase. So feel free to think of something that fits your company to help build comradery around it.

Organize It

Decide how to organize it while you’re building it. That might be in Jira, Trello, or Confluence for a large business. For a small business, it can be in a Google doc. It doesn’t have to be fancy at first!

Components and Processes

Create both the components and processes for how to use them. Define components based on if they can be isolated by themselves and still make sense. Provide examples wherever possible.

URL

Everyone in your org should have access to the design system for it to work well. The best way to make sure everyone is updated to the latest version is to make it one source of truth with some sort of URL.

If it’s a pdf, I can assure you that everyone will just lose it, use the wrong version, and not use it. A smaller company can use an internal wiki site if keeping up with a website is too much work.

The first version should have resources for both designers and front-end code for developers. Work directly with the teams to make sure it’s integrated into their workflows in whatever way works best for them.

Keep it Simple

The first version should be super simple. Start with the necessities like buttons and forms. Try to get to the very bottom of the hierarchy of your components. Don’t make too many rules, because teams might ignore it if there’s too much to read.

Reasoning

Make sure you remember to add the reasoning behind why you chose certain elements and how they should be used. The reasoning should align with the principles that you initially decided on.

For instance, Netflix chose their idea of “stacks” because they have a ton of different platforms, so they need to be able to expand and detract for the different sizes, whether it’s a billboard, phone, or newspaper.

Downloadable Parts

Include as many barebones downloadable parts as you can. That can be brand guidelines, individual components, a grid system, and pieces of code. The components can be parts like headers and footers and other starter templates. Make it as easy as possible for the people using your system to find things.

Agnostic

Keep the components as agnostic as you can so they work for many different cases. Technology changes very quickly, especially coding languages, so try to think about the longevity of what you’re using.

Let Everyone Know

Then let everyone know that you have this new design system! This might be different for small companies vs large companies. You might post notices around the office, use email, Basecamp or Slack. The best way is to distribute it through every channel you have in your company.


How to Iterate 

To keep your design system from slowly losing traction, you have to remember that it’s a living project and can’t be something on the side.


Create Processes

You’ve already decided who contributes at the beginning, but you might need to change that. Use one central place to file bugs, and decide who files them when you see discrepancies.

You can either update the whole system all at once or bits and pieces as you go. If you update once a year, you have to wait a while until the next update, and people might deviate from it. But if you update continuously, you get real-time updates, and it’s a bit more manageable.

Remind People to Use It

It’s inevitable that people will forget or not want to use it. That’s ok keep reminding them until it becomes a habit for them. Whenever you have new hires, you can use them as an opportunity to get people to adopt the system and act like it’s part of the protocol.

Simplify

Wherever you see problems, look for where you can simplify them. If the system is too complicated and you have a smaller team, it will be hard to keep up with and maintain. And if you have to update a lot of things manually, invest in the time to figure out how you can automate those.

Make Adjustments

Make adjustments after the different teams use the system and find places where the components you specified don’t fit. Not everything has to follow the components you made exactly. If there’s a special case and you need a new component, research to determine why it’s needed.

Act Like It’s a Product

Treat the design system itself like a product to make sure it gets iterated on. So make releases and updates a cyclical thing.

Allow Contributions

Don’t fall in love with it, so there is room for change. Allow for flexibility so that everyone can feel like they are able to contribute. Let people request components or behaviors. Reach out and ask people for feedback since they’re the users of your design system.

Keep the backlog accessible to anyone who wants to see it, and have weekly meetings to get feedback, with 1 or 2 reps from each team, or office hours or design reviews.

Company-Wide Yearly Review

Continuing to communicate frequently is very important. Make it a yearly event in the company to align with your principles. Based on how things go the first year, you might need to redefine goals and principles. Share what you’ve learned with data on the time and money you saved.

Never Done

A design system will always need to be iterated on. It’s a living, breathing thing, and just like your company grows, the design system needs to evolve and grow with it.

Some components will need to be modified and some will need to be removed. But as it continues to grow, you can tighten the loop of building, measuring, and learning.


How to Measure Success

Now you can go and implement what you did in your organization! You want to do usability testing to see if users notice, and if so, how they feel about the changes. Get both quantitative and qualitative results.

The end goal is to make the jobs of designers and engineers easier and tighten the strings between teams. Ask yourself if that was accomplished.


Quantitative Feedback

What actions are users taking, and is that different than before you implemented the system? This will help you figure out what design features are hard or easy to use.

Do this type of research when you have a working product, either at the beginning or end of a design cycle. You’ll want to have fewer participants than you would with qualitative feedback so you can have them discuss and explain their reasoning.

Qualitative Feedback

This will help you figure out if the tasks were easy to perform. You can do this at any time during the redesign, and you’ll want to have as many participants as possible since it’s more of a metrics type of research.

Branding/ Market Research

See how users feel about the actions they’re taking and the product as a whole. How do they feel about the brand itself now? Do you see a visible change in the product? When you interact with the org’s different products, does it feel like they’re from one cohesive brand?

Internal Feedback

Look inward and see how many teams actually adopted the design system. How smoothly is the product being built now, and is it sustainable from both a design and dev perspective?

Does it feel like a connected organization that communicates better? Are decisions that are made internally reflecting the brand or diverging from it? If so, what is missing from your system?


Resources

Online Examples

Google’s “Material Design”                     Trello’s “Nachos”
Salesforce’s “Lightning”                           Netflix’s “The Stack”
Shopify’s “Polaris”                                    Apple’s “Human Interface Guidelines”

Books

NASA Graphic Standards Manual
New York Metro Graphic Standards Manual
Smashing Magazine’s ‘Design Systems’





Reading Mode :
Font Size
+
16
-
lines height
+
2
-