Design systems can often ‘read’ as very top down, but need to be bottom up to reflect the needs of different users of different services in different contexts.
I’ve yet to be involved in a design system that hasn’t struggled to some extent for participation and contribution from the whole of its design community.
Aaaaaand the circle is now complete.
It is a crisis of care.
As with anything, it’s not about the technology itself:
A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.
Another follow-on to my post about design systems and automation. Here, Matthew invokes the spirit of the much-misunderstood Luddite martyrs. It’s good stuff.
Design systems are used by greedy software companies to fatten their bottom line. UI kits replace skilled designers with cheap commoditized labor.
Agile practices pressure teams to deliver more and faster. Scrum underscores soulless feature factories that suck the joy from the craft of software development.
But progress requires more than breaking looms.
Brad weighs in on what I wrote about design systems and automation. He rightly points out that the issue isn’t with any particular tool—and a design system is, after all, a tool—but rather with the culture and processes of the organisation.
Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.
There’s a full-on rant here about the dehumanising effects of what’s called “agile” at scale:
I’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.
But a design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.
Ethan shares his thoughts on what I wrote about design systems and automation. He offers this test on whether a design system is empowering or disempowering:
Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?
We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it.
Dave follows on from my post about design systems and automation.
At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
Almost every technological innovation over the last 300 years has had side effects which actually increase the number of opportunities for employment. The general trend is that the easier something is to do, the more demand there is for it.
Cameron looks at the historical effects of automation and applies that to design systems. The future he sees is one of increased design democratisation and participation.
This is actually something that designers have been championing for decades – inclusive design at all levels of the company, and an increase in design thinking at all stages of product development. Now that we finally have a chance of achieving that it’s not a time to be scared. It’s a time to be celebrated.
When another company achieves success, there’s a lot of pressure to investigate what they did right and apply that to our own organizations.
But we still have a chance. As long as we run brave organizations made up of even braver souls who are willing to embrace expression, trust their intuition and experiences, and stand up when everyone else is sitting down, we will survive.