Approaching Design System as a Part of Your Organisation

“It is better to do the right thing wrong than the wrong thing right.” Russell Ackoff

During Helsinki Design Systems meetup, I was asked if there were any tips on how a designer could start a design system project when there seemed to be no initiative from the upper management. This question deeply resonated with me, as my role in this endeavour was never to build a design system itself, for that I had a better equipped colleague, but to figure out how to integrate it into the rest of organisation with our limited resources and little support.

Our main approach was to come up with an evolutionary process, where the value the design system (even if partially implemented) brought to developers would be higher than the effort to adopt it. In other words we were designing our design system not to be perfect, but to be used.

Nevertheless, the goal of this article is not to dive into intricacies of our planning process, but, when looking back to our story, to think what kind of tips I would have shared, if I was asked the same question today.

So here is my list:

1. Find like-minded colleagues In every more or less large organisation there are definitely at least few more people except of you, who thought that creating design system would be a great idea. Therefore it is important to find them and offer a collaboration, especially if they are from different professional background. In our case such person was a senior developer, who helped us to create a repository and provided a lot of technical support during the early stages of the project.

2. Define your user When resources are scarce, it is very important to define your user as precisely as possible and then focus exclusively on their needs. It is even better if you can think of real people in your organisation, who will be using the design system. The users can be either designers or developers, but I would not recommend to focus on both at the same time. In our case the users we had exclusively focused on were developers working with web applications.

3. Replicate user’s workflow As it was mentioned earlier, it is extremely important to keep the effort to adopt the design system very low. One way to achieve this is to replicate user’s workflow. The design system should exist in the same environment where the user is used to work, all communication and support should go through the same channels, and work should be organised in a same way as with the user. In our case we shared the same repository with our products, used the same apps for chatting and ticketing, and even step-by-step moved into the agile sprints work mode.

4. Communicate This one might sound as very obvious, but it is too important to dismiss. Communicate with all potential users and stakeholders, so that no one is left out and everyone is aware of the project. The goal is to make people talk about it without you being present. The best indicator of a successful communication is when someone from your organisation, to whom you haven’t yet presented the design system, asks you if you have heard about it. Furthermore, it is very important to show people that this is serious and update them on the progress. In our case, from the very start, we organised dozens of meetings with all development teams, who worked with web apps. Once the project started rolling, we began doing presentations to managers and product owners as well.

5. Share ownership When resources are low, it is important to share the ownership. Create an open community, where everyone can contribute to the design system. Try to avoid calling yourself the core team or owners of a design system. At this stage of a project your role is rather to facilitate and synchronise. In our case, a team of developers created and took ownership over a javascript components library which were based on our vanilla code. Our role was merely to make sure that visual design of components was synchronised between vanilla and javascript repositories.

6. Encourage initiative One way to share the ownership is to encourage initiative. Engaging people outside your “core team” widens the skillset that can be contributed to the design system. If everything goes well, colleagues from other teams will start offering their assistance. Embrace their help and support their efforts to the best of your abilities. This will allow you to create a healthy open community. In our case, Q&A developers proposed to create an automated regression testing for the design system, the idea we fully supported. As a result we even learnt a thing or two about AET.

7. Look for “windows of opportunity” Every organisation has periods of stability, when it is hard to introduce novelties, but also periods of change, e.g. new business strategy or reorganisation, when novelties are easier to implement. During these periods of change various “windows of opportunity” may open, you just need to look for and utilise them. In our case, shortly after the introduction of the design system, our company went through a re-branding project. We proposed to use design system to accelerate the transition of our products from old brand to a new.

Don’t fall in love with your design There is a moment in each successful bottom-up initiative, when it becomes too important for organisation to keep on functioning as someone’s side project. Moreover, as a number of stakeholders grows, it becomes hard to rely only on a self-organising open community. Hence, the project should become more centralised with properly defined responsibilities and workflows. In our case, as the number of products that was using the design system grew, it became evident that more and more stakeholders saw us as a separate team, rather than an open community, where everyone could contribute. As a result, we took a critical look at how we operate, and decided to reorganise the way we work to fit new expectations of our users. Luckily for us, the growing number of stakeholders also meant a growing number of resources. But this is already a different story…