Part 3 of the Setting up a design system series.

The initiators

In the previous article I hinted at the fact that design systems often get initiated by a single person or a small group within a team. Often this is due to the fact that something triggered the wish to create a design system. I have seen these initiatives from both designers and developers. Obviously the motivation was different depending on who started the conversation and articulated the wish for such a system.

And this is where it is important to pay attention to how things continue from here. If the creation of a design system, a living style guide or a Pattern Library is only initiated by one group of people it is quite likely for it to have some built-in problems.

As the proverb says: If you want to go quickly, go alone. If you want to go far, go together. And there is a lot to it when it comes to design systems and all related tools and workflows. As motivated as a small group of 'makers' can be, hyped, pumped, ready to get a month's work done in a week, it is crucial to hold on for a moment and get the rest of the team/company aboard. This is an adventure with many obstacles ahead, you will need every single person to get to the proverbial paradise of a perfect design system, golden workflows, and rainbow emitting Pattern Libraries.

With that warning out of the way let's assemble a team to get the process of creating a design system started.

The founding mothers and fathers

While the initiators might be super excited and eager to get stuff done, quite possibly this could cause rejection and fear in other parts of the team or the company. They are just too motivated for some. An idea is to get a "constitutional meeting" organised. This meeting / workshop can be a great start and will most certainly bring a truck load of revelations to the surface (and no, I am not talking about things which happened at the last company Christmas party).

The design system kick-off meeting

Invite one or two representatives from the departments which might come into contact with the design system to a kick-off meeting. This ensures that no party is forgotten and feels left out. You want every possible input at this stage to create the most solid foundation for your system.

The meeting/workshop should cover these topics:

• What do/don't we like about our workflows and tasks?
• Where do we see chances to improve workflows and communication?
• What is important to a trade?
• Where do we need help?
• Where do we observe problems and obstacles on a regular basis?
• What are we afraid of?
• What do we think about when we hear design system / Pattern Library / Style guide?
• What would be a task / project you could imagine getting started with?
• What are the costs?
• Who has which experiences and knowledge to bring to the table?
• Do we have everything to get started?
• What are the next tasks?
• When do we meet again?

Ideally this will spark a lot of ideas and discussions. Obviously everything should be documented and a group of founders to take responsibility should be defined. They will get the first to dos done and distributed, keep the momentum up. Ensure that this group has at least one representative of all impacted trades, even if it is just a partial presence in the group. Advisors you might say.

The management

By now, you have an understanding of what is needed or might be coming. The founders get to define things, interview the others in their groups of trade or departments, a picture starts to shape up.

Obviously this process will cost time / money / effort and not everyone might feel like doing this in their free time. That is where management comes in (if you did not decide to have them in the initial meeting, which you should have). If people continue doing research, work on tasks, write stuff, do more research it is a thing requiring company resources. And even if there is no need for a fully fledged business plan for a Pattern Library (yet) or something similar it makes sense to discuss the impact of the founding work and the potential outcome.

Setting up a proper evaluation of the mission, the first tasks, the expected outcome, the investment is a good way of making sure there are no unexpected outcomes. At least not the nasty when-did-this-get-so-expensive kinds. Get management to sign the founding document as well (i.e. the meeting minutes).

The builders

Depending on what your design system will include, what you envision, it might need people to build it. Even if you come up with a simple document to start with, a text document with all colour codes on it, a folder with all code snippets used, a guideline for UX on your app, it needs to be created. Meet the content creators. They focus on the respective aspects from their trade's point of view. They do the lobby work for their topics.

The builders come in when things get a bit more complicated. There might be the decision to have a system which can be maintained via a web browser. Who builds that? Exactly, the builders. But they need support as well, as this is not just software. There needs to be someone doing the UI for this tool, a content structure, etc. Even if an existing tool can be used (like the UIengine for example) it is most likely that some adaptation is necessary for a smooth workflow.

The users

Once a system is in place, it is in a continuous stress test. Everyone who uses it from that point on has an opinion. Typical problems are:

• incompleteness (features, content, components)
• hard to use
• slow speed
• buggy functions and UI
• ugliness
• etc.

Those are just a few aspects, but should you wait to get the system started? Rather spend some more time to make it perfect?

Probably not. Start early and make it clear and obvious that this is work in progress. This has many advantages: People know that things will break. They can try using something and give feedback. Actually that is a crucial thing to offer simple feedback. Maybe a simple mini form on each screen a user uses?

From there you can not only collect, but make sense of feedback because it is clear where it came from and in which situation. Ask questions, derive features and optimisations from it. In short, make a better product. Because creating a design system is a product by itself. And so are the tools like a Pattern Library. The better your tool, the more likely it is to be used.

The design system ambassadors

With a need to keep people informed about what is going on, i.e. the status of the system, the feedback, and subsequent next steps, it makes sense to get your PR people to talk about the changes and new things. It sounds like selling something which should be used by the people anyway, but if you do it right, the whole team will start being more involved, know more details, get a hang of what is going on. They start owning it.

You might consider offering the people a newsletter, a microblog, some part on the intranet, maybe even a few minutes every week at the company get-together, to talk about the latest changes. People like to know things. Just do not overwhelm them. One thing at a time and in small doses. Reward feedback, embrace productive criticism, it will make the system stronger and stronger.

The external forces

This sounds dangerous. Force from the outside? Well, if you have a genuine interest in getting feedback, why not from outside as well? A design system is usually nothing secret. It is basically the rule book of everything people might see anyway. Many companies make their Pattern Libraries or design systems public, it is a good way of showing how you work. Some actually define this as one of the goals of such a system: communicating that they use a system to get certain jobs done. Not the worst idea to attract the right kind of people to get to work with you.

Obviously you would not want to put information into your documentation / design system with a top secret clearance and make it available to the public. But even that can be something to take into consideration when you set up your system in the first place.

So even people not on your team or within the company might be valuable contributors to the system or at least get an idea how you are working. Which raises the question: Did you get HR invited at the first meeting? ;)

Up next: Talking costs and budgets