The Theology of Design Systems
UI and UX folks love them, established industries have built guilds and unions because of them — and I still go my own path
This thought likely goes well beyond the user interface design (UI) and user experience (UX) frames of my audiences, but I’m going to keep it there for now. It’s a simple belief (or unbelief) in these design systems which sparked such contemplation. I’m rattling around yet another recruiter-forwarded opportunity and the description of the role led to doing some research. That research lead to a platform product, and that product a design system.
Design systems are the-thing-to-have in UI development and design. And it makes sense. Who wants to be spending time drawing and connecting again and again components (buttons, text areas, etc.), tying together the associated business logic, and managing the transitions between them manually every time? A design system normalizes much of this in the same way a font makes text readable — when there is uniformity, there is speed in delivery and a base-level of quality. Having been in and around web design and development since the late 1990s, design systems evolved from a lowly “logo and colors” to “dynamic style guides” to today’s design systems, interface guidelines, and SDKs.
I’m guilty of looking at every design system (and every Sketch, Photoshop, etc. file library containing them) with a slanted eye. Its not at all that I don’t believe them. There is a consistency and approach taken to put these together which needs to be applauded often. Having been on the side of creating these over my 20ish years in this space, design systems are only as good as the folks who aren’t designers. What are the workflows developers are using these systems to enable? What kinds of feedback are heard during the training and support contexts once the system has been implemented? Has marketing has ditched the design system to do something else (maybe similar, maybe easier… you know in-company NIMBY perspectives)? Design systems are only as good as the faith of their priests being seen activating something in the lives of their adherents. Faith is something lived, not just believed.
I don’t know that people outside of crafting industries should care about design systems. And those within those crafting industries (talking wider than UI now), should probably be aware their design system is indeed a language and culture all its own. Using a design system profitably requires learning its doctrines, likely mending various practices, and maybe even some denial of self. The design system that’s pulled from another source is a kind of missional/imperialistic adventure — you will conform to someone’s greater reputation or law in order to be affirmed as trustworthy enough to continue existing. The design system is there not for the craftsman to make the preeminent model, but for the model created to be most acceptable to the market it wishes to entreat. In a very real sense, a design system is a theology to drive towards some ethereal, external-affirming outcome (aka ROI).
And there’s my problem… I know why I wake up in the morning and its not to make someone else’s external outcome my own.
One of the pillars of my being is the need/want to create every day. A design system is a lot like Legos in that there are things which can be created, but you are limited by what’s in the box. There is no making of new pieces/behaviors (without business and technical validation). There’s really not much in the way of creating that happens; a well-done design system needs only a business goal and its pretty much plug-and-play. And that’s ok for some folks. That fits their buckets of what it means to be creative. It doesn’t for me.
I’ve found some design systems limiting in their scope or how the UI teams have gone down their implementation. This is to be expected. There have been enough transitions in computer-aided design where it makes sense to see best practices and best fails. The former is often shown, the latter occasionally only mocked. Learning another design system resets the expectations towards outcomes. Communicating that (for example to the recruiter mentioned at the start) is not something you do. You don’t tell Columbus he didn’t discover a faster route to India; you tell him that he might be in a section of India he’d never heard of before. You lead others to discovering their frame of reference might be a bit skewed, and offer yourself and opportunity to learn more also. You converse. Design systems are a conversation, at least they should be.
Design systems are not a conversation. They are a doctrine. They are a method. And those with stronger convictions than even the companies who maintain those design systems have to be ok with this. Knowing a design system means that you simply know the body of beliefs for a specific company in a particular industry at a particular time. Unless you become something of a gypsy, you will constantly talk yourself in and out of what about design you actually believe. The design system is the company’s rudder, not mine, not yours. And its ok to be skilled in using the design system, but not believe in it. Find your design principles, find the things which matter most to you, and be honest about the outcomes of using that design system helping you to realize them. Or, cut your own road. Because (as I’ve also found out), being off the beaten path is a believe system as well.
