6 questions to fail or succeed with Design Systems

I interviewed 10 designers to discover how would you and your team have success or not with your Design Systems.

Some weeks ago, I started to investigate a possible movement in my Product Design career at Marktplaats, the biggest marketplace in the Netherlands (check our vacancies!). This movement would take me to a role in our Design System team.

So I started an investigation to learn more about design systems and how people lead operations worldwide. To do it, I used my connections from my LinkedIn profile, asking for their help, and yeah, people supported me (when you need help, be humble and ask for it, the world is full of kind people willing to help you).

Preparing the questions

I consider myself someone pragmatic, so to keep my eyes on the prize, I also asked practical questions that you might have inside your head.

It’s important to say that I didn’t ask expecting right or wrong questions, but I want to understand how different people, from different companies (small and huge teams), would deal with the Design Systems challenges.

So let’s go straight to the questions. (See it organized as spreadsheet)

1 — How might someone fail in this position?

This question was important for me to understand how I would be able to fail as a leader of a Design Systems team. It was amazing to see how it reflects good practices for working with anything else.

Check the points they listed below:

• Being the police;
• Taking power from the designers;
• Incorporating and not having usage of components;
• Working reactively rather than predicting the team needs;
• Not listening, asking, or looking into researches with the users (designers and developers);
• Having a DS made just for DS;
• Not keeping a clear roadmap and process of the work;
• Creating an ideal XP that is not feasible;
• Not testing with the teams;
• Not understanding DS as a product;
• Building tools but not educating people to use them;
• Bringing too much theory that goes against the practical people’s way of working;
• Thinking that you can do it by yourself;
• By not having someone from the tech team 100% focused on exchanging knowledge with you;
• Not creating flexible components and generating detaches;
• Not asking for help and not connecting with people (internally and externally);
• If you dictate the rules, not being next to the team.

2 — What soft skills would make me successful in this position?

I know that we might need a long list of hard skills to work with something so technical, but I’m interested in the soft skill I would need. Technic you learn, the right traits are harder. So check now the point’s people have mentioned:

• Communication, communication, communication!!! ;
• Listening, asking, and researching with users is important;
• Humble to admit failures;
• Patience;
• Ability to create safe spaces;
• Be didactic;
• Systemic vision about how it might be reused;
• Resolute to make sure of the consistency in scale;
• You don’t need so much empathy because it’s a rule;
• 95% are hard skills and 5% soft ones for when stuff goes out of the rule;
• Share and empower peoples growth;
• Autonomy;
• Keep selling the product;
• Think about the strategy;
• Keep everyone engaged;
• Make noise about the DS;
• Invest time know as many possible scenarios as you can;
• Adapt your language to fit it.

3 — How do you believe a design system should be done, more centralized, or spread responsibility?

Imagine a rule; a DS might have two edges: a super centralized team that checks how people are doing design and another side where everyone is responsible for making the system work. I tried to understand where people would sit on that. The answers, you know, are below:

• Currently, we are very centralized, and it creates bottlenecks. But a distributed model would have a problem with less ownership;
• With +100 designers, we have a team that centralizes it;
• Collaborative with an alpha library where people create, and it becomes a backlog for the DS team;
• We train people to create their components;
• If you’ll centralize it or not is more a matter of politics; just make sure people get it needs to be scalable;
• We need to align expectations and involve people in the DS creation;
• People want to collaborate, but sometimes they don’t know how, so we created a process for it;
• In the beginning, it needs to be less collaborative to deliver, so being more mature you can make it collaborative;
• We reached a point that we needed to decentralize it; teaching people about how to contribute;
• If you don’t educate people, they won’t contribute to that;
• If a designer wants to do better and out of the standard, they need to think about how to standardize it;
• DS can’t be done for 1 or 2 people, if someone is designing, this person is creating systems, so DS start from the squads;
• It depends on the team’s size, sometimes the DS team takes care of core components, and ambassadors would help people to derivate the component for other tenants;
• Centralized but with some ambassadors trying to join people to collaborate, but centralizing the final decision.

4 — Do you see the design systems more rule restricted and detailed or more broad and open to give freedom to designers to create their layouts?

Lockdown or open? If you work with DS, this question probably already crossed your mind, and it crossed mine as well. So I decided to ask people about it:

• More restricted when it is about accessibility;
• We started with basic structures, but it started creating some inconsistencies. So we will never be 100% lockdown, but we are creating more restrictions. Besides that, we try to find ways to give something back to designers when being more restrictive;
• It depends, so measures the risks to decide it. Small teams = more flexibility;
• It is different from being creative and creating a new component; we do need to have components flexible enough to fit people’s needs;
• DS is a business, so as fewer components you have, better it would be;
• People need to like using DS, it looks like a uniform, so it’s easy to look inflexible;
• You can’t be super restrictive from the beginning, but with time you can start the evolution to patterns, etc.;
• For new designers joining the company having more lockdown could be helpful; we need to start with rules to start breaking that;
• We offer ingredients so people can create their receipts;
• It depends on the team’s maturity; more junior people request more design guidance because they consume less documentation. So they need to have more education. But at the same time, they try to don’t lock people and make it possible for them to work with some freedom. The biggest challenge is to make people read the documentation and use it, so a possibility would be to bring it to Figma or somewhere closer to the designers;
• Be more restricted about accessibility and aesthetics;
• Some tokens are important to keep the consistency;
• Good documentation is balanced between aligning with people and offering freedom.

5 — How do you see the Design system linked with Branding and Marketing?

I understand that a Design Systems should be about digital products, but I wanted to see how people see it and how linked it is with the branding team since the product might be one of the most important brand platforms.

• A way to think about branding linked to DS is to think about how it affects the DS;
• They started to align the design systems with the brand to have something with more look and feel of the brand;
• DS is for scale and brand ID, but this link depends on the branding team;
• Since DS is a language, MKT could support with assets for it;
• Branding teams need to join DS from the very beginning to create the ground rules;
• It depends on the company; it’s important to be aligned because DS is a tool to strengthen the brand. A link between areas could be the accessibility part because of compliance;
• It’s important to find ways to have syncs with the branding team to align the strategy;
• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;
• Sometimes you can have documentation and systems together, but most times, not. DS is for interfaces. For branding teams, it is normal to have a ‘Brand Systems’ (used for social, etc.). So most times, the libraries would communicate with each other but are not the same.

6 — How do you measure success about a DS?

The 1 million dollars question. This one is important to help you, me, and our teams to find a horizon for designing goals and celebrating when we reach them. What are people doing? I listed here:

• Perception research to understand engagement, adoption, and the team health;
• Component coverage;
• Adoption;
• Time to market;
• Implementation;
• ROI;
• Figma Analytics (Detach of components;
• Refection from the DEV teams;
• Accessibility;
• How many times a component is used;
• Implementation of components as a success metric;
• How much is DS vs. how much is hardcoded.

Well, the list is long, but it was valuable for me. I’m keen to hear from you in the comments: Does it makes sense for you? If not, what you and your team are doing?