Dummy’s Guide to Building a Design System
So you want to build a design system? Good, we all should because they’re amazing! But what the heck is a Design System, anyway?
A design system is the entirety of your standard UI patterns, framework, assets, and documentation, as well as the processes and people involved. It is the ecosystem that drives and supports the unified evolution of your products.
There are some pre-production steps that need to take place before you get started building anything. If you’re completely new to Design Systems, take a while to digest all the incredible information posted by Nathan Curtis. He even has some clearly outlined exercises that can help your team get the ball rolling.
Get in the Right State of Mind
You and your team needs to be aware of systems-oriented, or object-oriented design. Brad Frost’s Atomic Design methodology is a great place to start. There’s an understanding that you’re not designing pages, features, or templates. You’re create a visual language based on relationships between interface elements.
Your visual language should embody your brand and should support your users’ goals. The language is easily seen as the aesthetic personality of our products, but it is also the fundamental level of communication between your users and your product. Systems-oriented design should be thought of as literal as creating a language. What elements are derivatives of other elements? How does context change meaning? How does intonation emphasize elements of communication?
Your team needs to be firmly in the state of mind of creating modular, reusable design elements that group together to form common relationships. On top of that, your team needs to see this effort as a continuous relationship between people in your company. Your goals are to serve one another in order to help, encourage, and enable everyone to make better products.
Identify Everyone’s Needs and Goals
Define these clearly. Write them down and speak with as many people internally and externally as you can. Some questions you need to ask are:
- What do our designers need?
- What do our developers need?
- What do our users need?
- What does the company need?
Each of these are a little different, but you should be solving for each of them. From a basic sense, each group has value in reducing duplicate work by creating reusable assets (design assets & code assets). That saves everyone time, and the company money. It allows your product the agility to evolve quickly as well, which also saves the company money. For your users, consistency and a cohesive visual language makes your entire product suite more intuitive.
Take a Personnel Inventory
How many people is your company willing to devote to this effort? This is a really important aspect to any Design Systems effort. You need to have representatives from a variety of departments within your company in order to ensure your solving for each internal user the best way possible. A small team is good, but if you’re by yourself it may be completely impossible. It can be done with a core team of 2 (one designer and one developer), but even then you will need coordination from other departments in the organization.
Do a Design Inventory
Do you have a standard repository of UI patterns? If not, you may want to start off with a fully-fledged UI Inventory. Find out what exists in your applications, identify the inconsistencies and the consistencies, and then present the findings and raise the case for creating a standard pattern library.
If you already have some basic standard patterns, that’s all you need for a (dare I say it) MVP. If you already have a robust pattern library, you’re already ahead of the game!
Discover your Technology Landscape
Don’t overlook this one lightly. Every company will have it’s own unique technological challenges, and you need to know every one of yours. This landscape is an outline for supporting your entire product suite.
You may find in this discovery phase that you’re able to support every product easily. You may also find that some products are being deprecated in the near future, so you don’t need to support them.
Define Your Target Solutions
Now you get together and synthesize what you’ve learned. Take insights from all your users’ needs, goals, challenges, and and expectations (sounds familiar, right?). Formulate solution statements in order to be clear what you intend to make, who it will help, and how it will help them. It’s nice to have a solution statement for each user type, but it’s also good to have an overarching statement of the goals and intentions of the Design System for elevator pitches and internal marketing.
For example, for the designers you could say:
We intend to build a sketch symbol library and template using nested symbols and a common color palette in order to share assets with the design team to create consistent UI designs quickly and easily.
Strategize the Solutions
Now you start going into detail… what do those target solutions look like and how will you get there? What work needs to be done, and what is the acceptance criteria for each? A few things you’ll need to know are:
- What tools do we currently use?
- What other tools should we use?
- Are new tools going to affect our solution?
- Does our strategy align with the company’s technology roadmap?
- How long will these solutions take to create?
- Do we need to adjust personnel or scope of the initial design system?
Without a doubt, you will not capture everything. That’s ok, just be nimble and adjust your goals as you progress :-)
Additional Research
Now that you have a plan, you need to verify that it’s a viable solution. Research possible taxonomies for your UI Patterns. If you’re building a documentation site, begin wire-framing and prototyping solutions. Continue speaking with your internal users to identify whether the solution you have planned will benefit them, and try to identify room for improvement.
Do some collaborative exercises with a broad team in order to make sure everyone has their goals and expectations aligned.
Simply naming things can be a major hurdle at this stage. Need help figuring out how to name things? — Here’s another helpful article from Nathan Curtis.
There may be additional conversations and interviews to help identify the granular details of how to implement the technology solution you’re aiming for. For example, do you deliver CSS over a CDN, and if so, what needs to happen in order to get the CDN setup?
Future Planning
You need to start thinking about the future before you begin. How will these tools evolve? How do people contribute to the Design System? Setting up a clear process early on can help to avoid frustration and confusion down the road, but it could also ultimately affect the success of your Design System.
And Now You Build It
This is going to be unique for everyone. Read up on how other teams have built their Design Systems, and see if you can gain any insights from how they tackle similar problems.
We built our first Design System using Sass, Gulp, and Jenkins, as well as Sketch and Balsamiq. It’s a continual process, but the impacts and ROI are immediately evident.
Good luck!
