Design System and Crazyness
Last week my ex-colleague and friend Benoit Rajalu shared a post called “Is it really a design system?” in which he lists the different reasons why the shiny project you call a “Design System” maybe isn’t really one, but just a collection of bad components.
You’re not building a Design System when designers and developers are not using the same language and components, when you have no documentation except a Storybook or few comments on a Figma file, when designers reinvent the wheel in each project and developers code single-use ultra-specific components. You’re most certainly not building a Design System when there is all that and nothing is attempted to fix it.
And I strongly agree with this.
I formulated a strong opinion on the situation thanks to the powerful schema his article ends with.
It shows that setting-up a Design System for your organization means switching from the traditional “designers vs developers” mindset (left) to a Product mindset (right).
The target is to have a team that owns a product (the DS and its artifacts). A product that has customers (your other teams).
I have to admit that I am not seeing a lot of Design System teams in companies so far. I see Design System projects, for sure. It’s very trendy these days. They are mainly driven by the base of the organization, ie. some designers and/or developers. They work on it on weekends. They come early in the morning or they leave late at night to work for the project without slowing down production for their “real” job, shipping features.
The organization’s leadership may eventually enter the game, especially if the project begins to see some traction (as it will because, turns out, it’s a powerful concept) and if the initial volunteers haven’t burned out yet. Leadership declares: “We have a Design System! It’s so good! Thanks so and so”. A quick mention of it is made in a blog post or a corporate presentation, showing the world how their Design System revolutionized the company. Meanwhile, nothing has actually changed inside.
Nothing has changed because the leadership has not embraced that a Design System is a product, and nurturing a product requires a dedicated team.
Is such a thing a pipe dream? It should not be, we are already used to this paradigm in our engineering departments. We have infrastructure or platform teams that cater to the other units, providing a solid platform to run their services. We have engineering productivity teams that help others with day to day tools (CI, testing environment, etc.). We have analysts and UX researchers to support the decision-making of other teams with bespoke data. They are all “in-house” services teams.
Organizations willingly invest in all of those teams but can’t form one for the Design System? What’s the problem?
Is it the idea of mixing designers and developers together as one unit? How is it different from what we do for feature teams, squads, swarms or whatever name you give to multidisciplinary teams, those working on features?
Is it an org chart issue? Where it’s unclear whether such a team reports to the VP of Product or to the VP of Engineering? Why would that matter? Aren’t they both after the same ultimate company goal?
Is it because designers or developers are already understaffed? Well shoot, that’s precisely when a dedicated team would help: with a Design System they will do more with less.
Is it because nobody is here to lead this team? What about those who have managed to build the current Design System and do their day to day job at the same time? Aren’t they leadership enough?
Is it because you don’t believe in investing in such low levels teams for the benefit of the rest of the organization? Then why keep talking about a Design System, and why keep investing in infrastructure teams, UX researchers and so on if you’re against such an idea?
All this questioning leads only to one conclusion: wanting to produce a Design System without updating your organization to support it will make your designers and developers go crazy.
They have to work for their team’s projects on the roadmap while fighting with management over time budgets for Design System tasks. These are never the priority and the global roadmap has never enough room for them. But both designers and developers see their benefits, so they keep trying, and trying, and trying.
They end up giving 100% for the Design System (because, you know, such a project is not an easy task) while they’re asked to keep giving 100% on their regularly-scheduled features, knowing such a pace always ends poorly (yes, burnout. Or wry cynicism in the best of cases, go ask Benoit).
They are often put in acrimonious situations with other colleagues while continuing to work with them on their features. This is unavoidable. The situation doesn’t actually make sense to anyone. The people invested in the Design System will of course fight for it. Those who aren’t as invested are faced with an unsanctioned, “bottom-up” project, and some will therefore have no issue undermining that project. If it were so important, a team would have been formed around it, right? Right.
They are left with two very opposite missions: they must keep focusing on the specific needs of their individual teams while simultaneously creating a product, one that preaches the need to cater collaboratively to the necessities of every team. In the same work day, they may be tasked with creating design or code in complete opposition with the goal of the System they defend.
They also lack the proper communication structures. Nobody listens to them. Nobody considers their requests. Nobody respects the rules the Design System comes with because they have no authority. Their product has not been sanctioned, it is not materialized by a single, identifiable core team. It’s just a bunch of people being mad at the void.
They are mad because they have to work in constant questioning, constant tradeoff. They have to manage all those contradictions and conflicts by themselves, not being afforded the same support and leadership other “in-house services” teams have been given.
They’re going completely crazy.
By wanting the company to produce a Design System without organizing around and for it, we chart a clear path to craziness. After all, it is exactly to prevent that that we usually create new teams with clear responsibilities. It’s for people to work efficiently towards one team goal. For conflicts and contradictions to be resolved by teams speaking to each others, not by poisoning everyone’s mind.
I’m not saying it’s impossible to build a real Design System relying only on a few charitable souls spread across teams. There are certainly successful examples.
However, it certainly is the hardest path. If the benefits of the Design System come without change on your organization’s part, without a dedicated team, supportive leadership, ressources, time and headcount, then you can trust the cost is being paid by the employees. At the cost of their sanity, or their trust, or their motivation.
Thanks to Benoit Rajalu for helping me with drafts of this!