On Starting

Prep is great and necessary. But sometimes you just have to start.

Since a lot of my work in the last two years has been solely focused on design systems, I've thought about them a lot. I wanted to share some of what I've learned—as a sort of exercise in taking stock and seeing what still makes sense. Chiefly, I want to talk about why I still think design systems matter, how hard they are to get off the ground, and how setting pace out of the gate can be difficult and limit how far you go.

We're all familiar with our old pal evolution. The conventional wisdom on mother nature's chief method of creation and destruction goes something like this: organisms change slowly over time, responding to environmental changes by auditioning new things (let's call them "features") over many generations, getting rid of the ones that fail (like, say, Microsoft Clippy) and keeping the ones that win (like bottom navigation on mobile devices). This sounds like a great way to build software, too, at least at first glance. Slow and measured, evolution ensures we don't throw anyone off with big mutations that inhibit people's ability to use our software. We arrive slowly at a platonic idea of "better" software, and keep everyone happy in the meantime by slowly squashing bugs and adding features at a sustainable pace.

But you have to start.

This is the single greatest impediment to teams building design systems. Most of them are beginning in an environment where the process of designing UX is total chaos. Nothing is documented, there's no shared vocabulary to talk about what's being built, and there are lots of patterns in use without rhyme or reason to govern them. It's primordial soup all the way down, and things are happening by accident or not at all. And the backdrop to all this chaos are unyielding stakeholder requests to fix problems, launch new features, establish new measurements and on and on. What to do?

  • Make room to get weird. In a situation like the one above, you're going to just have to start. It's going to be uncomfortable and maybe weird, but you'll need to temporarily abandon the safety of measured evolution and—like Gregor Mendel with a window box full of ivy plants before you—get weird.

  • Map your current position. In a situation like the one above, you're going to just have to start. It's going to be uncomfortable and maybe weird, but you'll need to temporarily abandon the safety of measured evolution and—like Gregor Mendel with a window box full of ivy plants before you—get weird.

  • Set priorities. With an audit under your belt, you can start to look at the components and experiences that you might think of as the "core" of your system. These will need to ship the soonest, be documented the most thoroughly, and be the most bulletproof. For most teams buttons, forms and typography come first. Without these things, not much magic can happen. This list may need buy-in and blessings from a variety of people. You may also need to get your testing methodologies approved. For this, your mileage may vary. Now may also be a good time to brush up on your sales skills.

  • Make the first pattern. With the audit complete and your priorities in order you'll quickly find yourself at the crux of the biscuit. Building the first pattern—setting its rules and requirements, designing its look and feel—will be the hardest. Especially if this is the first time this work has been done in your organization, all eyes will be on you. But rest assured, if you do a good job someone may name an element after you.

This is the danger in elevating the administration of UX work itself to the level of academia. This is not to say that some aspects of the work are not complex, or don't require time and effort to set up. But it's important to not get seduced by the tools themselves, and to remember that establishing a framework is the beginning of the work and not a perpetual task. It's the same in nature. The process of evolution is slow and measured, but mutations themselves can be shockingly bizarre, quick to arise, and just as quick to go away forever. As a framework with internal dynamism it can teach us a lot about how to create user experiences, and it goes deeper than a casual reading of evolution.

The zen of good prep
As a creative person, I've picked up lots of hobbies over the years that seem to involve preparation. I cook extensively, I used to build scale models as a kid, I paint and draw. Something that I never understood in the ADD rush of my childhood was that there is joy in preparing to do something creative; building out the framework, Knolling the tools on the workbench, setting your notebook and pens by your laptop and headphones just so—all of these things are joyous in their own way, creative with a lowercase 'c'.

But as someone who has struggled with focus and attention, and who has learned a raft of coping techniques—I know the anxiety that comes when prep ends. A table covered in cut up vegetables, protein and sauces can mean only one thing: it's time to cook now. Potential failure is only seconds away (and a sink full of dishes). All that stakeholder goodwill, the carefully curated process and the framework itself—could all go up in smoke (to brutally and egregiously mix metaphors). But it's the same in any creative endeavor. The carefully stretched canvas, the artfully appointed livery on a race car, the gantry of a Saturn V rocket—these are means to an end, and as such they should and do vary wildly from creator to creator.

This is another way of saying: I care about prep and frameworks, processes and tools, but the core of Pragmatic UX is that these things are lightweight because they are meant to burn up on the launchpad when the genius of your designs takes flight. I care a lot less about your tools than I do what you do with them.

It's one of the strange ironies of design today. I know a lot of designers who talk a lot about their tools, write extensively about their build scripts that allow this thing to render this other thing that makes this documentation page happen. They work on meticulously organized desks where everything is just so. But then lunch time rolls around and they want to find the grimiest, realest taco place in town because that's where the real shit is.

Box does not reveal contents
Designers working in UI and UX now, more than ever, are borrowing whole chunks of process from one another because it's so easy to do so. You can go to Github and fork airbnb's entire design system if you want to—process and all. But the box—the evolutionary blueprint—reveals very little about the end product. You're building a framework so you can get weird. You're not building a framework to build a framework. Do it with reverence, document your steps, and be prudent. But remember you have to cook.

— Nick Jones, Jan. 24, 2022

Last Updated January 26, 2022 @ 4:58 PM

Copyright © 2022 Nick Jones

All rights reserved, all wrongs reversed.