Ugly truths about design systems
Design system (DS) is not a temporary trend, it has many benefits to the organization and the product. If you google “Design system”, there will be unlimited articles about why we should have a design system. Giant companies build their DS and share it with the world, Airbnb, IBM, Shopify,…
After spending a year on building DS at Carousell, here are what I’m facing when building it.
We are feeding the scale monster
Consistency across the product and organization is the most important benefit of building a DS. We spend lots of time building it. Not only designers, developers, and PMs, but it’s also the whole company. We spend time creating something that we can use everywhere in any case.
It’s called design for scale.
But one solution can’t fit all. It’s the same for DS. We don’t know what we don’t know. We’re unclear about new problems we will face. Some new problems need new approaches. Anh DS doesn’t always fit.
I don’t like the phrase “Design for scale”. When we feed the scale monster, we will lose flexibility and optimization. We need the flexibility to adapt to the fast-changing world. We go global but need to localize.
Treat DS as a product is a lie
“Treat DS as a product” means to continue updating, iterating like a product. But it’s a lie.
As a startup, we’re fighting every day to live. We use all of our resources to focus on the product, create new features, to improve and optimize for a better product. Who cares about updating a “product” that’s not so real like DS?
In a big organization, the product team is divided into different teams. And the product stays consistent due to the DS.
Different teams solve different problems. That’s why one component works for this team but not for the other. That’s the time designers sit together to discuss the change. But we also need engineers to be involved. But they are busy with their task, and their OKRs which are building DS isn’t included. Even updating DS is in their OKRs. We are not sure they want to do it, because we all agreed that was how the component works.
Changes are a reality, we always need to change DS either. That is to say involving and sharing why we should update the DS is very important.
DS is a strick grammar
Engineers will always ask us to use the components that were already built. There’s no wrong with that, their goals make it work and easy to maintain. They don’t like any things that are inconsistent and dirty code.
Designers will use what we have on DS for their designs. Sometime, the built components just can’t solve the problems. It’s good to work under constraints. But just after a big project, the product just goes wrong. You see so many things can be done better with some small changes. But when we want to change, the whole product will be impacted. We have a stack of dependencies on each design.
Locking design into a system makes it very hard to make something fast. And with a strict grammar system, we have less freedom to create something fun and surprising. When it’s not fun, it’s not design anymore.