#design #designOps - 7 mins read

Design systems for non-designers

While reusable patterns in digital product design can be traced back to the 1960s, modern design systems have risen in popularity significantly over the last decade. This was in part due to the increasing complexity and scale of digital products, but also the opportunity organisations saw to speed up their development process and enhance their users’ experience. Not to mention the proliferation of thought leadership and tools in this space.

This article provides an overview of design systems for non-designers, and highlights some best practices for creating modern, scalable design systems:

What is a design system?

A design system is a collection of reusable assets and accompanying documentation that act as a single source of truth to help teams build more consistent products, faster.

Assets 🧱

Assets are the reusable styles, components, and patterns that make up the design system. Design system assets could come in the form of design files (e.g Figma or Sketch files) or they might be code-based (e.g React or HTML components). In isolation, assets are often referred to as component or UI libraries.

Styles, components, patterns

Documentation 📝

Documentation is what sets apart design systems from component or UI libraries. Design system documentation typically comes in two forms: Asset-based documentation (e.g. usage guidelines, supporting user research, and implementation instructions) and product-based documentation (e.g contribution guides, roadmaps and backlogs, and blog posts). Some tools, such as Storybook.js, will automatically generate documentation for you, saving you even more time.

Design systems documentation

💡 Best practice: A comprehensive design system should contain both assets and documentation.

Why do you need a design system?

“Using a Design System can remove over 50% of the time needed to design, develop and test” PGS Software

Enhance usability 😄

Design systems create consistency across the user experience of your products which makes them more usable. A button on this screen looks the same as a button on that screen, and because of that it reduces the user’s cognitive load.

Increase product development efficiency 💨

If user interface components and patterns are predefined and documented as code, engineers can use these repeatable building blocks to rapidly build out the front-end of applications. Likewise, if a product designer only needs to assemble a set of existing components to build a new prototype (as opposed to designing them all from scratch) this will save them a huge amount of time.

Reduce waste 🗑

If three teams have all designed and built the same component, then two of those teams have wasted their time.

Improve information flow 💬

Having a set of well documented, accessible design assets improves the flow of information across an organisation and allows teams to self-serve without asking unnecessary questions.

Where do design systems live?

The design system itself could either be static or code-based. Static design systems exist within the design files of design applications, such as Figma or Sketch. Code-based design systems manifest themselves through a website or code repository. Often, teams will use a combination of the two, with designers maintaining a static component library in their design application of choice, and publishing references to those design files and documentation to a dedicated website.

Tip: The term ‘living design system’ simply means that it is constantly evolving and is not a once-created static artefact. You can still have a living design system that exists as static design files, so long as there is an ongoing effort to support, maintain and iterate them.

A public facing website with accompanying open source code repository is obviously the most accessible option. However this approach comes with additional overheads and may require the support of engineers to create and maintain the design system.

💡 Best practice: Make your design system accessible by creating a public facing website with accompanying code repository.

How are design systems managed?

Design systems are a product themselves, so if you want to get the most out of them, you should manage them as any other product within your organisation.

Centrally managed

Centrally managed design systems are owned and managed by a dedicated team or person. In some large organisations, design systems are supported by full-time product managers and engineers. Having this dedicated resource often provides the additional bandwidth and focus needed to mature a design system and ensure it is maintained properly. However, a centrally managed design system often becomes a hard dependency for those wishing to use it if they’re not empowered to make contributions. It can also lead to poor morale amongst designers who are not part of the central team, as their role becomes less creative.


Federated design system management means that there is no single team dedicated to the management of the design system. Instead, anybody from any team is empowered to contribute towards it. This means that there is no hard dependency, and if a new component or pattern is needed by a specific team, they are empowered to create it. This approach comes with the benefit that the development of the design system is driven by those who are closest to the needs of the user and the business. However, without a dedicated team, it’s easier for quality to diminish over time.

💡 Best practice: Empower every designer and engineer in your organisation to contribute towards your design system while establishing a central group (not necessarily a team) to ensure quality and maintenance.

When should you implement a design system?

While there is no hard and fast rule for when to implement a design system, the lifecycle of and scale of your products can give you an indication of when it’s most beneficial.

If your product is at the beginning of its lifecycle, for example, in discovery, building a comprehensive design system can be overkill. During this phase you should be prioritising speed, ideation, and experimentation over consistency and reuse.

As you move out of discovery into developing a minimum viable product (MVP), this is when it becomes more beneficial to start developing a design system. Design systems can often be created as a by-product of the design and development process. As new screens and components are developed, reusable assets can be defined and shared, enabling future reuse.

Once you’re past the MVP stage - and assuming you don’t have a single, super-simple product - this is when a comprehensive design system becomes incredibly valuable and crucial if you want to scale quickly, without generating a lot of waste.

How to start implementing a design system

Starting with existing products

If you have existing products that you think would benefit from the improved consistency and velocity that a design system can bring, the best way to start is by auditing the different components that are already in use. While a product designer is best placed to perform such an audit, it is possible for other members of your team to do so. Performing a comprehensive audit will show you which components are ripe for standardisation, where the quick wins are, and also, where the gaps are.

It is also important to conduct user research with the people in your teams who will be contributing to, or consuming the design system, to understand their needs. You can then use these insights to inform a roadmap or backlog for your design system. As new components are defined, you can strangle out the existing components iteratively until you have achieved full coverage across your product. This iterative approach avoids the inherent risk entailed in replacing all your components at once and delivers change faster.

Starting from scratch

If you’re building a new product from scratch, then the decision becomes whether to start by using an established open source design system, such as Material, or to create your own bespoke one. This decision is best made by understanding how customised and branded your design system needs to be. If you’re launching a product into a competitive market, where users can choose to use other products, then creating a custom design system is likely the best approach.

If, however, you’re building an internal product, or a product with a very small user base, then using an established design system might be the best path. You might also start with an existing design system for speed, and to make use of its best-practices, but customise or theme it over time to meet your needs.

💡 Best practice: Investing in creating your own bespoke design system often pays off in the long term and provides a greater degree of flexibility.


To recap, design systems are a critical tool for any organisation wishing to improve the usability of their products, information flow, and the efficiency of their product development process.

A modern design system should:

  • Include a comprehensive set of both assets and documentation
  • Be accessible to everyone in your organisation
  • Enable all designers and engineers to contribute towards it
  • Be managed as a product, with funding and continuous innovation, driven by user needs

And finally, you should make a decision on how and when to invest in your design system, based on the complexity and lifecycle of your products.