I’d maybe simplify this people problem a bit: the codebase is easy to change, but the incentives within a company are not. And yet it’s the incentives that drive what kind of code gets written — what is acceptable, what needs to get fixed, how people work together. In short, we cannot be expected to fix the code without fixing the organization, too.
These survey results show that creating and maintaining an impactful design system comes with challenges such as planning a clear strategy, managing changes to the system, and fostering design system adoption across the organization. Yet the long-lasting value of a mature design system—like collaboration and better communication—awaits after the hard work of overcoming these challenges is done.
A great talk by Ethan called The Design Systems Between Us.
Don’t blame it on the COBOL:
It’s a common fiction that computing technologies tend to become obsolete in a matter of years or even months, because this sells more units of consumer electronics. But this has never been true when it comes to large-scale computing infrastructure. This misapprehension, and the language’s history of being disdained by an increasingly toxic programming culture, made COBOL an easy scapegoat. But the narrative that COBOL was to blame for recent failures undoes itself: scapegoating COBOL can’t get far when the code is in fact meant to be easy to read and maintain.
It strikes me that the resilience of programmes written in COBOL is like the opposite of today’s modern web stack, where the tangled weeds of nested dependencies ensures that projects get harder and harder to maintain over time.
In a field that has elevated boy geniuses and rockstar coders, obscure hacks and complex black-boxed algorithms, it’s perhaps no wonder that a committee-designed language meant to be easier to learn and use—and which was created by a team that included multiple women in positions of authority—would be held in low esteem. But modern computing has started to become undone, and to undo other parts of our societies, through the field’s high opinion of itself, and through the way that it concentrates power into the hands of programmers who mistake social, political, and economic problems for technical ones, often with disastrous results.
It all started at Patterns Day…
(Note: you’ll probably need to use Reader mode to avoid taxing your eyes reading this—the colour contrast …doesn’t.)
Smart thoughts from Ethan on how design systems can cement your existing ways of working, but can’t magically change how collaboration works at your organisation.
Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.
Sara shares how she programmes with custom properties in CSS. It sounds like her sensible approach aligns quite nicely with Andy’s CUBE CSS methodology.
Oh, and she’s using Fractal to organise her components:
I’ve been using Fractal for a couple of years now. I chose it over other pattern library tools because it fit my needs perfectly — I wanted a tool that was unopinionated and flexible enough to allow me to set up and structure my project the way I wanted to. Fractal fit the description perfectly because it is agnostic as to the way I develop or the tools I use.
I really, really like Andy’s approach here:
The focus of the methodology is utilising the power of CSS and the web platform as a whole, with some added controls and structures that help to keep things a bit more maintainable and predictable. The end-goal is shipping as little CSS as possible—leaning heavily into progressive enhancement and modern techniques.
If you use the cascade for everything, you’re going to run into trouble. But equally, micro-managing styles on every element will also get you into trouble. I think Andy’s found a really great sweet spot here that gets the balance just right.
CUBE CSS in essence, is a progressive enhancement approach, vs a fight against the grain of CSS or a pixel-pushing your project to within an inch of its life approach.
Yes! It feels very “webby” to me.
Five moments in the lifecycle of a design system. They grow up so fast!
- Formation of the Design System Team
- First Page Shipped
- Consumable Outside the Main Product
- First Non-System Team Consumer
- First Breaking Change
Dave makes the observation that design systems are less like open source software and more like enterprise software—software you didn’t choose to use:
Often, in my experience, for an internal Design System to have widespread adoption it requires a literal executive mandate from the top floor of the building.
Also: apparently design systems have achieved personhood now and we’re capitalising them as proper names. First name Design, last name System.
“Please, call me Design. Mr. System was my father.”
I enjoyed talking with Chris about design systems (and more). The episode is now available for your huffduffing pleasure.
Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.
Who hurt you, Robin?
- Design systems haven’t “solved” inconsistency. Rather, they’ve shifted how and when it manifests.
- Many design systems have introduced another, deeper issue: a problem of visibility.
Ethan makes the case that it’s time we stopped taking a pattern-led approach to design systems and start taking a process-led approach. I agree. I think there’s often more emphasis on the “design” than the “system”.
Is making your design system public worth the effort? In short: yes, it is.
I agree with Dan. But I wish that more people would make their design system mistakes and misteps public, like Robin talked about.
Through planning and architectural design, Le Corbusier hoped to create a scientifically rational and comprehensive solution to urban problems in a way that would both promote democracy and quality of life. For him, the factory production process applied to high-rise buildings with prefabricated and standardized components is the most modern and egalitarian of urban forms.
Something something top-down design systems.
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.
This is something we’ve learned at Clearleft—you can’t create a design system for an organisation, hand it over to them, and expect it to be maintained.
You can’t just hire an agency to create a design system and expect that the system alone will solve something. It won’t do much before the people in the organization align on this idea as well, believe in it, invest in it, and create a culture of collaboration around it.
The people who will be living with the design system must be (co-)creators of it. That’s very much the area we work in now.
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?