Design system: LEGO kits syndrome
Balancing consistency and contribution should be the primary concern of design systems.
What happens when you have 5 designers creating a text field simultaneously?
They’ll come up with unnecessary differences: different border colors, various border radius, or different structures.
Letting this type of unintentional inconsistency cost us at least two things. One, it creates an issue for usability and expensive interaction cost for the users. The other obvious issue is the redundancy of the engineering effort.
The pattern library typically comes as a rescue for that problem. The team will use the existing library as opposed to creating unnecessary inconsistency. While this approach can resolve the unintentional inconsistency and I still advocate for it to some extent. We should be careful because it can create another problem.
Pattern library can create a LEGO kits syndrome.
Without a doubt, the result of the LEGO kits looks great.
However, as Derek Cabrera, Ph.D., points out, adults making LEGO kits are the ones thinking creatively. But it ends up teaching kids to follow instructions.
When the culture around the design system sends the signal, “please use the pattern library, so we are consistent.” This mindset is selfish.
I call this a pursuit of uniformity—the design system team see success when the “adoption” of their library is high and aim for the consistency for the sake of consistency.
This approach forces the designer to see the design system as LEGO kits.
As a result, when designers work on a specific interaction problem, they will think, “Okay, what available components or patterns can I use here?” Without further evaluating whether the component helps them solve the problem effectively.
I’ve seen this, over and over — no research or study around this. But the result of the design system survey by Seesparkbox can be a signal. 54% of in-house respondents of the design system survey reported that their design system users rarely contribute to the system or don’t contribute at all.
I suspect the LEGO kits syndrome is one of the factors that contribute to the lack of contribution.
The problem with this phenomenon is that the system would become stale. Without any participation and contribution from the community, it is simply a pattern library — not a design system.
Balancing act
When you want to utilize the pattern library to eliminate the unintentional inconsistency, consider what kind of culture you want to build.
Having participation and contribution from the community is what differentiate design systems from pattern libraries. I’ve learned the hard way and invested over 3 months to solve this lack of contribution back in the previous company.
The remedy? Consider building a community and enable contribution, which we’ll talk about in the next article.
Thought exercise
- How often do the system users give input about your pattern library?
- How often do the system users propose a new component or pattern?
- If the contribution is relatively low, what stopping them from contributing? Have you considered designing the contribution experience?
- How would you respond to the system users who created a new component without communicating it back to the design system?
- What do the system users think about the design system?
Best,
Budi
Blog: buditanrim.co
Newsletter: buditanrim.co/newsletter
Twitter: buditanrim
In this series:
- Intro: How to shape your design systems culture
- #1: LEGO Kits Syndrome
- #2: The BNARL model
- #3: From BNARL to interventions
- #4: The Pattern Friday as Ritual
- #5: How to Facilitate a Pattern Friday?
- #6: A Case Study: Bukalapak 2019
- #7: A Small Team Case Study: Indonesia Education Civic Tech 2021
