In 2013 I spoke about Responsive Deliverables at SXSW. While it felt in-tune to the emerging web design trends and my personal experiences, I didn’t really anticipate that I’d personally spend the nearly every day of the next 7 years working on component-based design systems. The work has been a series of utter successes, quasi-failures, mutinies, political dramas, complete lack of organizational prioritization, and 67.742% rollouts. As my head rises from the the waters of recent projects, my thoughts have been gathering around how to improve the work I do.
I was struck this week by a post by Jeremy Keith called Architects, gardeners, and design systems. Jeremy wades into the world of metaphors and expounds on Frank Chimero’s Gardening vs. Architecture metaphor and its relation to design systems. I enjoy this metaphor a lot. Gardening is a mix of planning, digging, cursing, planting, maintenance, fighting against environmental entropy, and lots of waiting to see what bears fruit.
Jeremy extends the analogy of gardening to the idea of maintenance:
Outside of the context of open source projects, we don’t talk much about maintenance. We’re much more likely to talk about making.
In our cultural obsession with billionaire entrepreneurs we laud new features more than the maintenance and incrementalism work of making old features better and more accessible. Maintenance looks like red minus signs in the spreadsheet. New features look like green plus signs. New features look better on our LinkedIn profiles. New features have that pizzazz, baby.
When gardening, the building of planters and initial planting is a very short process. The majority of your time is spent nurturing and monitoring growth. I personally feel the struggle between maintainer work and new shiny feature work. I enjoy that new feature smell but I know that my day-to-day is more like a janitor on a boat mopping up someone else’s barf. In terms of metaphors, the gardening metaphor is certainly better, and it acknowledges that design and development still tend to be more creative endeavors.
But the garden has become more systematized, industrial, and Jeremy makes a strong assertion about the societal impact design systems have:
In that light, design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.
This kills me, but it’s true. 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. We operate more like Taylor and his stopwatch and Gantt and his charts, maximizing effort and impact rather than focusing on the human aspects of product development.
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.
Two themes that keep coming up in my business book odyssey are that the key to employee happiness comes from autonomy and the people you work with. “Autonomy” is a tough one for design systems. In a sense, a design system exists to reduce “riffing” and wrangle against having 32 different buttons across 20 page templates. Consistency tends to be great for User Experience.
It seems to be human nature, however, to build a new button or use the wrong LEGO or use the LEGO that your corporate idols use, instead of digging in the bin for the exact right one. I’ve seen the eyes designers and developers glaze over with boredom when I inform them that their new radical idea is already in the design system and is waiting to be implemented. Perhaps problem-solving work is inherently more interesting to humans than the implementation work.
It can be hard to stay interested if it feels like you’re painting by numbers, even if they are your own numbers.
But design systems excel at making that new feature work boring. “You need a list of products over the thing? Well, here’s our list of products and you put it over the thing.” Often the concise description of the problem is the solution. It can of course be improved, but not bad for two minutes of work. But it only works if people feel they have autonomy and are a part of a cohesive team. Otherwise, they’ll go rogue.
There’s always a point on a project where I’m approached by a distant, rogue manager of a distant, rogue designer who has been told by their manager they need to adhere to the design system. “Is this design system compliant?” to which I only know how to reply, “I dunno, did you use the design system?”
Ultimately, your satisfaction with a design system or “design systems” as a concept in general probably depends on whether you contribute to the hyperobject or are beholden to it. It’s unfortunate that in a system where all design compositions and all lines of code must maximize shareholder value, we never learn to play and how to break the rules in order to produce something new and exciting.
So how do we inject more autonomy into design systems? Jina Anne’s philosophy on Design Tokens seems really strong in maximizing individual contributor and team autonomy, being more “descriptivist” as Jeremy puts it, rather than “prescriptivist”. Perhaps the old “Tools, not rules” adage holds up here as well. Design and development tools and processes that democratize contributions could provide autonomy, or at least the feeling of autonomy.
I’ve said it before in the past and will repeat it because I feel like it applies here, but I wonder if the tiny part of “tiny bootstraps” is maybe the most important part of my little catchphrase from yesteryear. Perhaps some styles, some utilities, some components, and a handful of carefully considered assemblies could maintain that autonomy and while keeping the User Experience consistent for customers.
The gospel of design systems is still very true to me, but I’m beginning to see some of the potential tradeoffs; the human costs.