Design system: 10 questions you should ask at your next meeting

Written by: Marcin Sasin, UI Designer at Autentika

So you know you need a design system but you're not sure you have the internal capacity and competencies to develop it? Here's a checklist for your next meeting with the product and design teams with key questions to ask and red flags to watch out for.

The time has come. You're tired of wasting time and energy designing and developing new products. You're fed up with the weak UX, which everyone hates. It drives you mad that each of your systems looks and works differently. And that it costs gazillions.

You decided: The organisation needs a design system (or even two systems). You know it needs it, and the benefits are obvious to you. It won’t be a walk in the park, but you're ready to tackle this revolution (and even have the budget for it). But how do you ensure your product and design teams have the right skills and competencies to do it? Will they know where to start? Do they have experience building design systems? Do they have the right people on their teams?

At Autentika, we have experience in working with bigcompanies on their design systems and know the ins and outs of the challenge. We also know that some organizations – for example media holdings – often need two independent design systems – and we’ll risk a statement that internal teams are not always equal to the task.

In this article, we list the key questions you should ask at your next meeting to assess whether people in your company have the knowledge and capacity to build a design system. Beware – some answers you might hear are red flags. If you hear them, you should think of turning to external experts with proven experience – or you risk a failure of an entire project.

Read also: Expert's voice: How to build a design system? .

The first question you should ask is whether the people in your organisation understand what a design system is and whether they accept a uniform, company-wide definition.

A design system can be defined in many ways – and it's not enough to say that it's "the company's bible for digital product design and development". Sometimes people confuse a design system with a style guide, which is just one of many elements of a DS, or with a UI kit, a mere set of interface elements that represent their interactions in relation to a particular product. A design system is neither a Figma file with nested symbols, Sketch or other graphics files. It's not even the component library or a bootstrap – apart from components, it must include the knowledge and context of using them.

If there is a lack of shared understanding of a design system, navigating the work process is impossible because everyone has a different idea of what you want to create. In this case, the first step might be to develop essential documentation with basic definitions and assumptions.

It may be clear that your organisation needs a design system: it has an extensive ecosystem of IT projects that need to evolve, is planning new projects, or your teams of designers and developers struggle to communicate and achieve coherent results. You know you are wasting time because app development is taking forever. You are aware of the weaknesses of your UX and the lack of consistency between systems. Finally, you know that you are paying twice (or ten times) for the exact solutions implemented separately in many different places.

But do your key stakeholders know this?

The idea of a design system is to create it once and use it many times. But it’s you who should make sure everyone in the organisation is aware of the benefits a design system brings, such as:

• Increased time and cost efficiency when building new products,
• Coherent branding of applications within the ecosystem,
• Reduced costs of developing existing applications,
• Better user experience,
• Optimised control over roles and permissions.

It is also essential to know that people understand the change that a design system will bring – especially because implementation is not the end of the project (we'll get to that later).

Before we jump into questions about the key skills and competencies needed to build a design system, we want to alert you to a common pitfall. Many managers think that a design system is a project – a set of operations that bring a singular goal. We tend to think of it as a product that creates value for a user by solving a specific problem.

What's unique about a product is that it's never finished. Its inherent features require constant work with refactoring and component development. As a product, the design system needs resources and support not only to be built but also to be maintained and evolved.

We can say that creating a design system consists of two phases. The first phase, which usually takes six to twelve months, is the development, when you intensively work on building new components and adding them to the library. Over time, the library fills up, and new parts are added less frequently. Then comes the maintenance phase (12+ months), which never ends – at least as long as the product lives. It’s crucial to understand this and plan your work and the engagement of your employees accordingly.

Once you know the basics, it's time to think about the design system team. The first thing you'll probably want to assess is whether you have the internal capacity to build it. From our experience, we can say that a design system team should consist of at least two full-time employees: a full-time UI designer and a full-time front-end developer.

"Full-time" is a key term here. If you think you can pull your staff away from their regular jobs for a few hours a week to develop a design system, it will not work. You need a team – people working together, agreeing on and implementing the process.

You might also consider adding a UX designer to the team and a product owner to help you manage the project, develop strategies, plan, and move things forward according to your roadmap. As the project evolves, so does the team: you might need a content designer, UX writer, researchers, data analysts and others.

Note that after the most intense part of work (after roughly 12 months), you probably won’t need a full-time team; it will be enough to engage people for 20-25% of their time.

The size of the team is as important as the skills and competencies of the people who make it up. You should carefully decide whether the people working for you can handle the following tasks:

• create process documentation
• conduct user interviews
• gather system requirements
• create system fundamentals and structures
• create system components and assess their usability

Remember, this is the team we're talking about – the people you hire for this project need to collaborate, constantly sharing ideas and giving each other feedback. In the design systems space, a component designed by UI affects the front end and vice versa. Therefore, it's critical that those working on it think holistically about how the different pieces work together to create a cohesive experience for the end users. For this reason, your team should be user-centric: Understand user needs and turn feedback into solutions.

Communication skills are equally important – after all, your team will present the vision to key stakeholders and partners. Other "soft" skills that might come in handy are curiosity and a genuine passion for design – if you have someone really interested in design systems, you'll most likely end up with great results.

This is probably one of the most important questions you should ask and a serious red flag if the answer is "no". Building design systems requires particular skills, and few experts are on the market.

When planning a design system, ask if people have previous experience in the field, how often they have done it and how long ago. "Fresh" people who want to deal with a design system challenge can make costly mistakes, despite being enthusiastic about new tasks. If you have doubts about their experience, consider hiring an external consultancy and delivery team with proven experience. Such an attitude eliminates the risk of failure and guarantees peace of mind.

More questions about a design system in your organisation? Let’s talk —->

Your partners should know what tools and technologies they will use throughout the process. It's worth checking if they have specific applications in mind, such as

• Design: Figma, Sketch, inVision, Adobe XD
• Development: React, Angular, Vue, webpack, Node, styled-components, xstyled, Typescript, CSS-in-JS
• Documentation: Storybook, zeroheight, Docusaurus

The challenge with the toolset is that it largely depends on the technology you already use in your organisation – whether your existing applications were built in one, two or three frameworks, and whether you have some old, legacy systems. The bar also increases if you want to build mobile apps with one code source on multiple platforms.

Aside from tools, it's essential to have processes in place. You should ask product and design teams if they have prepared a process for developing and maintaining the design system, a process for creating documentation and sharing knowledge about the new DS.

The knowledge-sharing process is especially important here because you created the DS for a reason. Its goal is to make new applications faster and cheaper, so the organisation must ensure that new products are not created in isolation from the design system. People must know that the design system exists and how to use it.

Another point that should not be neglected is the documentation process. It is something that simply needs to be done, and if someone on a team undermines the necessity of documenting the process – it’s a red flag. Documentation is where many mistakes and inconsistencies show up. Sometimes you even conclude that you need an extra person in the team who could take care of it – so think in advance about how the process will be handled and which tools you’re going to use.

Building a design system is only the beginning of work – the real ride starts when the DS is actually in place because now people should be using it to build new products. That's why it's good to have a person in the organisation responsible for sharing knowledge and keeping track of all the teams supposed to use the DS.

It's not easy to find such a person: He or she must know the entire organisation well and have a bird's eye view of all teams and processes in the IT department. It's best if such a person is a kind of "free electron" who isn't tied to any team. That way, they can surf around the company, attend various meetings, talk to people, and “manage by walking around”. We can call him/her a "space owner" – someone who knows what is going on and what is planned in terms of development.

Your team should know the forecasted results a design system will bring to the business regarding speed and efficiency. How much time can be saved thanks to a design system? What cost optimisation are we discussing? What percentage of components from a design system will be used to build a new application?

From our experience, we can say that it’s highly possible to estimate those results – for example, if you build an application in four months instead of six, you will save at least 60 man-days, which already adds up to a certain amount of money. Your partners should be able to give you a similar answer – and if they’re not – it’s another red flag.

These 10 questions should give you a good overview of staff knowledge and skills and help you decide if you can handle building a design system with your internal team. It might turn out that in-house resources aren't sufficient – employees are busy with other tasks or lack the necessary experience to carry on such a complex task. Don't worry – this is a normal situation and doesn't mean you can't build a design system.

Red flags or vague answers you hear at the meeting should prompt you to seek outside help. But it doesn't have to be a typical agency that uses "one fits all" stamp solutions. It can be a partner you work with to develop a customised system for your needs.

Read a case study from our work on design system for Wirtualna Polska