Are you thinking about building a design system but have no clue where to start? You’re not alone! I’ve been building design systems for a while, but when I started out I sorely lacked some guidance, and made (many) mistakes so this is going to be a list of learnings & things I wish I’d known before I jumped in.

Note: This is the first blog in a multi-part series! As I go I’ll slowly tackle more specific areas in design systems such as building standardised styles and responsive components in Figma.

What is a Design System?

A set of cohesive standards, styles, patterns and components to enable designing at scale.

In some ways, it's analogous to a good old brand guide but it’s a lot more functional.  Just so we’re on the same page, let’s break down what's typically included in a comprehensive design system:

• Styleguide: standard styles and their application such as imagery, colour, typography etc.
• Component Library: every standard individual component used in your interface such as buttons, tables etc.
• Pattern Library: a set of reusable patterns and templates for grouped components that guide interface layouts.
• Documentation: accessible documentation on the above styles, components and patterns for developers or designers to easily understand.

Do you actually need one?

As passionate designers who love designing, we can easily get carried away and forget to ask important questions which could save us (or our clients) a lot of time and money. Building a design system is no easy feat and shouldn’t be rushed. It has an upfront time cost that can (if done well) massively pay off many times over later down the road.

Here’s a list of things to consider before making your decision:

• Does the product or website interface reuse multiple elements across the experience? If so, you have a good argument for a design system especially if there are plans for the product to scale in the future. If not, seriously consider a simple styleguide instead.
• Does the wider team understand the benefits? Please don’t go rogue. Discuss how a design system could allow you to design at scale, maintain consistency and speed up your processes with all relevant teams before hitting the go button.
• Does the existing brand lack styles or guidelines? Be aware that building the initial styleguide is going to take longer without a solid starting point like brand guidelines so allow plenty of time for exploration/iteration.
• Do you have the resources to implement a system? Don’t underestimate how much work the design system will take to put in place, if you do, you might create an insurmountable amount of work for one poor developer. You can always consider a simple styleguide and an out-of-the-box component library like Semantics UI instead.

‍

Ok, hopefully, I haven’t scared you off and you’ve made the decision to move forward and you’re ready to build a beautiful design system. What’s next?

Work with the brand, not against it

Brands come in all shapes and sizes and if they’re not a tech-based company, they're most likely using design in a way that doesn't align with UI/UX standards. For example, a print company, wanting to make a full self-serve experience for customised prints probably won’t have design guidelines appropriate for an accessible digital product. This is one of the first challenges you’ll encounter but fear not! if any guidelines are in place already that’s already a massive help and should be your starting point. Remember to treat existing branding guidelines with respect and dignity(even if you think they suck).

Design systems are a natural extension of the brand and should never undermine the integrity of its identity

Here are a few tips to get the most out of the brand:

• Dig into the guidelines and try your best to understand the design intentions and philosophy, and if you can, set up chats with whoever worked on them.
• Book meetings with key stakeholders to understand the brand and its core values thoroughly.
• If there is a design team in place, chat about their design philosophy and how that can be translated into the system.
• Let the brand guidelines influence your approach and initial moodboarding.

Don’t reinvent the wheel

Designing components from the ground up with full creative freedom may sound like a fun challenge but in reality, it’s very impractical for implementation and will sound like a nightmare to your developers for a couple of reasons:

• Inefficient use of time. Designing components and their behaviours from the ground up is already a time-sink but implementing a custom framework for those components is even more time-consuming.
• High maintenance. Maintaining a custom component framework is resource intensive, requiring constant debugging, updating and refining.
• Might lead to unconventional components. Research has taught us that users love familiarity when it comes to the fundamentals (like input fields) so building unique components with their own unconventional behaviours is usually going to do more harm than good.

The ultimate purpose of any product is the ability to solve the problem effectively. As long as it happens, the product doesn’t need to have unique details that make it stand out from the crowd.- Nick Babich

So…what’s the answer? Open-source UI libraries! like Material UI. These libraries are really comprehensive and are also usually customisable with properties, styles and animations that can be tweaked to your heart’s content.

It’s worth pointing out that choosing a base library doesn’t have to limit your design, it’s simply a starting point for components and their behaviours, you’re going to mould it (sometimes beyond recognition) into something that fits your product and its use cases but it’s going to save your implementation so much time. It also doesn’t mean putting yourself in a position where you’re completely reliant on the entire library but rather picking and choosing modules of the library to integrate into yours. There will still be times when you need a custom component that doesn’t exist in the library and that’s fine but the chosen library should cover most of your needs.

‍

Choose the right foundation

Choosing a base UI library is always one of the very first things you should tackle but with so many options how do you choose one? Your choice needs to be carefully considered for your application. Here are some suggestions to think about:

• Refine the shortlist with your development team. It’s only fair that the people that are going to implement your components have a say on which library is chosen, and they’ll probably have worked with some of the popular frameworks like Bootstrap in the past and know details that we’ll overlook as designers.
• Gather a list of components needed. Crystallise the goal of the product with your product owner so you have a clear understanding of the core functionality and scope of the product and that’ll help you know what components you’ll need. This step is a lot easier if you have wireframes or basic screens for the product ready.
• Check the library is actively being updated. Not all libraries are equal. Some are fully fledged systems with a dedicated team working on bugs & improvements while others are abandoned side-projects. You definitely want to avoid the latter or you’ll run into a lot of problems so do your research (with the help of your developers).
• Ensure the components are flexible enough. Some libraries are built to be used as-is and don't offer many properties or put up barriers to changing styling. Do a design/implementation test run with one of the components to make sure it’s customisable enough for your needs.
• You might need more than one. Most UI libraries don’t have solutions for charts, if you’re building or working on a data visualization product you may need to consider a separate chart library.

Thank you for reading!

Click here to read part 2

‍