4 false assumptions we made about our Design System (updated)
Lessons from 8 years in the making
This article was originally published in April 2020 with 3 false assumptions. We lost it, then backed it up (phew!) and added a bonus 4th at the end.
Fabien and I took the stage at the Design System Summit in early 2020 (in a very different world!) to talk about what happens after you release a Design System — Fabien as dev and me as designer. What happens after you press that holy Production button for the first time?
At Societe Generale we pressed that button for the first time in 2014, and we haven’t stopped since!
It’s fair to say that we’ve come a long way since — we’ve iterated a lot. We also made some mistakes too! In this article, I’m going to share the assumptions we made, and explain how we came to change our minds.
Please note I’m not explaining what Design Systems are here, but if you’re interested read some of the previous articles in this series!
Assumption 1: We just have to do the same as…
This first mistake we made was in our choice of technology and tools.
It’s easy to fall into the trap of being tempted by big-name tech stacks. Design-wise, we followed Google Material perhaps a little bit too much at the beginning of our journey.
Just to be clear, Material in itself is great. Forever one of our favourite systems. But we have needs and constraints at Societe Generale that others don’t.
For example, at that time, Material’s form inputs were designed with an underline — Can you imagine that element in our complex financial screen full of inputs inside table cells?
For our choice of front-end framework, it was a similar situation…
In 2014 we decided to build every part of the system with AngularJS, the standard at the time. Then around 2017, developers legitimately argued that AngularJS (Google JS framework) was outdated and we should migrate to React (Facebook’s alternative). We could have chosen to follow their suggestion, and rewrite all our AngularJS code but then what will happen in 202X when React is outdated? Another migration, all over again, but with a lot more code to rewrite.
Our solution was to stop relying on GAFA tools and face these technologies head on with our needs and constraints. Instead of simply using or reproducing, we started looking for some inspiration and adapting a system for ourselves.
The result was this: on the design side we now have a system of guidelines applied to our UI Library which is well documented. On the code side, we chose to avoid having to build components in multiple frameworks and rely on Web Components to stay independent from any 3rd party frameworks, while our CSS system is usable on any front-end project.
Assumption 2: Of course, they will understand…
The second big mistake we made was in wrongly anticipating the way developers would welcome our newly-released design system.
We anticipated that developers would be instantly able to use the system, because it is so simple that they wouldn’t have any difficulties. And even if some of them had questions or misunderstandings, they would simply need to read the Documentation and…
FABIEN: HUM, REALLY? I’M A DEVELOPER MYSELF. I DO NOT READ DOCUMENTATION… until I’m stuck and need to move on.
At that point, there is no other solution than meeting your developers, explaining to them what the design system is, how it will solve part of their problems, following the installation if necessary and showing them how to use it, where the documentation is, who to contact and how, if they have any feedback or issue.
Keep in mind that Design Systems solve part of developers’ problems, but they need to be aware of what it actually is and how it will help them in order to use it willingly. This is Design System adoption.
Assumption 3: Let’s settle this in a meeting…
This third mistake is in the way we decided what should be part of the System or not.
At first, we started inviting everybody to meetings to discuss the matter together and make a collective decision. But soon, most attendees complained because it was all taking too long, and who really likes meetings anyway…
Then, we moved to a ‘benevolent dictator’ format where a few selected people met and decided for everybody. Again, people complained they were not part of the decision, not aware of what decisions were actually being made.
So, what could we do?
We established an asynchronous decision-making process through GitHub for code, and InVision for design. Now everything is discussed through issues or prototypes and everybody (well, mostly the relevant ones) is able to take part in the discussion, whenever they want, with the whole history available.
Another advantage is that when someone joins the team, everything is available and the whole decision process is perfectly transparent.
Assumption 4: They will say thanks… [2022 addition]
Looking back over 8 years in the making, there is a last misconception I want to tackle in this article: nobody will thank you for doing the grind work.
After all the excitement and pitches on the benefits of having our design system (time saved, money saved, see we’re really saving this bank, etc.), the work on adoption and buy-in — people now treat our design system as “business as usual”, as a utility… which means they don’t really notice everything, except if it isn’t working well.
Missing features.
Missing examples.
Missing documentation.
They expect the design system to do more than what it is designed for. Instead of mentioning time and budget saved by the system, they complain that they missed a roadmap delivery because a component was buggy!
All this can be emotionally draining and cause design-system fatigue. To mitigate it, we had to move away from a ‘hero-saving-the-day’ mindset to something closer to ‘servant leadership’ where support and bugfix are prioritized against starting shiny new things — instead of being forgotten in roadmaps. We focus less on “strategic KPI presentations”, and more on how useful the system is for the people it serves.
Today, we keep on celebrating and amplifying stories, but less on the system itself, and more on the people using and contributing to it.
Conclusion
Just as we did, you are likely to make assumptions before creating your Design System. Some of them will be wrong, but that’s OK: it’s all part of the product lifecycle.
What we wanted to illustrate with this article is the importance of iterating and staying open to change and evolution, based on feedback. Also, it is a healthy discussion to have with your teammates or peers!
Have you changed your mind while building your Design System?
This article is part of our Design System series: a 5-year overview, getting buy-in, governance & chaos (part 1), governance & chaos (part 2), adaptive colour systems and surviving. Watch this space for more!
