Things You Need to Know Before You Build a Design System

Girish Subramanian
Oct 14, 2020 · 9 min read

Context is everything when it comes to creating a design system. There are three things that you need to know before you attempt to build a design system:
1. Design maturity of the organization
2. Design maturity of the product
3. Design maturity of the people — sponsors, stakeholders, partners, and designers

If we say the measure of maturity is high, medium, and low for each, it is not very difficult to surmise that one size does not fit all.

For an organization that is undergoing a digital transformation, my guess would be a low-medium on all parameters with some people exhibiting a high maturity. For younger organizations that have always been digital, maturity levels are much higher.

I have built three design systems thus far and all of them have been experiments born out of my curiosity. The reason why I call them as experiments is because no other word captures the ambiguity better. This is usually an ambiguous task with an unambiguously stated outcome when it starts, for the most part. All my experiments are listed at the end of this article.

Two biggest challenges for a me when I build Design Systems are to gain clarity based on a good understanding of ground realities (opportunities, rabbit holes and risks) and communicate that to sponsors and stakeholders as soon as I can.

I am sharing my knowledge as a practical guide to create a design system based on my three experiments:

Step 0: Read Nathan Curtis’ articles multiple times. I promise you that this is the only resource you need during the first year. Thanks Nathan!

Identify what kind of Design System you want
Most organizations have three kinds of design problems that they solve for and the notion that one design system will address all three needs will be a very costly mistake. You need three design systems — one for each

  1. Marketing
  2. Consumer Apps
  3. Enterprise Solutions

For example, Polaris and Lightning Design Systems focus on enterprise solutions. Material Design focuses on consumer apps. A quick look at some of the popular Design Systems will show this difference.

However the basic foundations like grid, colours, padding and spacing can be shared between these three. (Type scale should be different). Atom level elements like buttons and form elements can also be shared between these three.

Depending upon the priority of the business, you can prioritize among these three. If you have budget and the right kind of people, you can start simultaneously on all three. (But please don’t make the rookie mistake of thinking that one size will fit all.)

Treat Design System as an organic product, that serves other products
A design system should be treated as a separate product with a separate roadmap and separate budgets for it to be successful, especially when it serves multiple brands, lines of business and product lines. If it is treated as a side project, it will remain as one.

Design system should be maintained in perpetual beta for it to be successful in its job.

If you are unable to secure budget or unable to build a roadmap, there is no need to fret. Start this as a side project. Others will see soon see benefits when you reduce your production time by almost 40%. Not having a Design System is not an option for you.

Also remember, trying to be perfect is a trap. Aiming for a continuous improvement and gaining momentum is a better idea. Start from where ever you are. Start with whatever you have.

Identify guiding principles
Guiding principles for design systems are different from design principles for the organization or the product. This is very important for all stakeholders to understand from the start. Also you need a metric for success. A Design systems without guiding principles or a success metric would end up in lot of energy wasted over arguments

There are no two ways about this. You need guiding principles that make sense in your context. I am sharing a set of principles that I created with my partners for one of the design systems that we built.

  1. Unified over Same: We create a unified experiences across brands and products within our ecosystem. Our attempt is to create unified and cohesive experiences that are meaningful from a user’s perspective and not to create ‘same’ experiences because it is quicker to build.
  2. Appropriate over Right: Our measure of quality of a solution is its appropriateness in the given context. Not how perfect it is or how fast it can be delivered.
  3. Trust over Contest: We trust and respect each others talents and abilities. We neither tell the other person how to do their job nor second guess their decision in their field of expertise.
  4. Momentum over Everything else: We work in harmony and ship every sprint. We improve sprint over sprint.

Conduct an audit
The most critical step that is often overlooked. Never underestimate the power of an audit. Even if you do not have a lot of time or budget, you should always conduct an audit of the most critical parts of the digital ecosystem. you can never go wrong with an audit. It will help you avoid a lot of quicksands, bear traps and rabbit holes.

I repeat, start from where ever you are. Start with whatever you have.

Build a roadmap (if you can)
The reason I say ‘if you can’ is because there is a good possibility that the person in the drivers seat is Business or Technology. They would have goals for which Design Systems is a means to an end. In that case, you cannot push for the design system to be a product of its own without derailing the plans of the sponsor. The only available option is to influence their roadmap to make sure that you are not rendering the design system efforts useless.

In a year(more or less) they would realize that it is critical to separate the Design System roadmap. Till then you have to evangelize. Good luck.

Just remember that internal data > external data > complaining.

Put the digital brand guidelines in place
Grids, Colours, Type scale, Iconography are foundational to any digital product but I am not surprised when it is not the case.

Don’t step an inch forward without resolving these. It is very expensive to change these later. That doesn’t mean that you need answers for everything. Start with what you have. Create placeholders for things that need more information. Your dev partners will probably recommend tokens. Work with whatever your dev partner thinks is the right way to move forward.

Make sure all foundational elements are A11Y compliant(colour contrast and type scale to start with). In addition to being the right thing to do, early focus on accessibility also has a business advantage. It cuts down Design+Dev+QA churn due to accessibility issues. (A11Y churn can be very expensive)

Build product agnostic foundational elements
Start small. Make sure that you check all the boxes without spending an enormous amount of time. The goal while building the foundational elements should be to create agnostic elements. What I mean is that the foundational elements should be so basic that any digital team in any corner of the world should be able to use them for any brand/product by changing the CSS.

If you are short on budget and time, reusing Bootstrap or Material Design for foundational elements is a great option (if they work in your organizational context). You can easily find readymade UI Kits and code libraries.

Pivot till you arrive at a Governance model that makes sense to your organization
There is a lot of material available online that can guide you towards building a Governance model for design systems. However, what is important to realize is that we can never force fit something external into our organizational structure. It requires organizational intelligence, a lot of empathy, a lot of partners and a lot of time to build a Governance model that works best for your organization. Just keep in mind that you are building a governance for people and not processes. I have captured my experiences in this article.

Encourage adoption
If steps 1 through 6 are in place, then all that remains is to open the gates of the playground for everybody in the organization and to establish momentum. At this point, the main job the design system team becomes an exercise in Marketing and Project Management.

Be Resourceful
F*** constraints. Don’t complain. Don’t cut corners. Figure out a way to do the right thing and do it the right way. Doing the right thing the right way has immense long term benefits for the organization(and your mental health).

Here are notes from my experiments:
Design System 1:
Design maturity of the organization: Low
Design maturity of the product: Medium low
Design maturity of the Sponsors: Low
Design maturity of the Business team: Low
Design maturity of the Engineering team: Low
Design maturity of the Design team: Medium High

The first one was rather easy because it involved curating patterns of an existing product so that that the future releases did not introduce any rogue patterns.

The reason why we chose to curate patterns for this product was that it was a legacy product and we were not able to support every request that came our way.

The purpose of this exercise was very simple- to allow POs and Devs to move faster on bugs, minor issues and micro-improvements(with design only providing consultation). The testimony to this fact was that the library was a powerpoint presentation hosted in a common folder that was constantly updated by the lead designer as and when they encountered new use cases.

Design System 2:
Design maturity of the organization: Medium
Design maturity of the product: High
Design maturity of the Sponsors: Medium
Design maturity of the Business team: Medium
Design maturity of the Engineering team: Medium High
Design maturity of the Design team: High

This design system was built for a new product that was being built from scratch. We used bootstrap for all core elements and created five page types — Lists, Forms, Dashboard, Settings and Custom. The resulting component library was very comprehensive and had a high adoption. The reason for its success was that the product and engineering partners trusted the design team and did not see design or the design system as another checkbox in their list.

The team that built and consumed this was small(~20). The pages and patterns were self explanatory. The product, design and dev teams had lunch everyday at the same table. All of these were the ingredients for its success. When it was completed, it still was a library where the rules of usage and other guiding principles not explicitly written but the rules for usage of patterns were ingrained in the system as a memory. However in retrospect, I feel that we should have spent some more time in formally articulating usage and guidelines to make the system scalable.

Design System 3:
Design maturity of the organization: Low
Design maturity of the product: Medium Low
Design maturity of the Sponsors: Low
Design maturity of the Business team: Low
Design maturity of the Engineering team: Medium High
Design maturity of the Design team: Medium High

By far, this has been the most complex system that I have put together. Four lines of business. Five brands. 30+ applications. Three designers. One A11Y specialist. One Design System.

What comes to my mind when I think about this experience is this scene from ‘The Wrong Trousers’ featuring Wallace and Gromit :)

Gromit from ‘Wallace and Gromit — The wrong trousers’ laying tracks ahead while the train is moving at full speed
Building a Design System while the production train is moving at full speed

The redesign of the website started without any consideration to the design system. When I inherited it, the dev team was slicing off components from mocks and adding them to a code library (The dev team were the quasi-owners of the design systems which for them was only reusable code.)

Luckily, I had great dev partners who wanted to do it the right way. Together with them, we put in place a governance model that worked for us and that allowed us to move faster than the production train. We became a truly agile team where the design and development were not two teams but two skillsets within one team. We delivered 100+ components serving 5+ brands in the first two years resulting in huge savings. (If you want to know how to be truly agile and design + develop in the same sprint this might be of interest to you.)

These are only a few things that you need to keep in mind before you get started. The actual operations of design system is quite complex. It involves figuring out ways for alignment among all stakeholders, buy-ins from designers, team formation, shared ownership, intake process, feedback from consumers, adoption, the contribution model and many other things that I am not listing here, including conflict management strategies.

Reach out to me on LinkedIN if you want to see the artefacts or want to chat more about my experiences.

How to democratize Design Systems?

How to double your velocity in sprints?

The Startup

Get smarter at building your thing. Join The Startup’s +788K followers.

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +788K followers.

Girish Subramanian

Written by

Object Maker. Experience Collector. Story Seeker. Wikipedia Glutton. Happy Sleeper.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +788K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store