What I learned from making my own design system

Knowing isn’t understanding. Books are a great way to know. Understanding takes first-hand experience. A person can know that having kids will change their life. They won’t fully understand until they’re living it.

Design system teams are just as vulnerable to the knowing/understanding gap. A team can know how people use it. They can know what’s working and what’s not. But they may not understand due to lack of first-hand experience. The why behind the what is missing. And why is pretty damned important when it comes to design systems.

And this is why I decided to make a design system for my personal websites. It’d been a while since I drank my own kool aid. Which, for the record, I am an ardent drinker of. I wanted to once again be on the consumer side to refresh my first-hand experience. It didn’t hurt that my websites were a hot mess. And I keep telling people that design systems can fix that kind of thing…

This article isn’t about the design system I made. It’s about what I better understand from going through the process. Below are the things that stood out.

You can make a design system too late

I typically warn teams not create a system before it makes sense. Going through this process made it clear how crappy too late can be as well. I’d never been the engineer tasked to inject a design system into a mature codebase. It’s not fun. Now I understand even more why design system pushes often coincide with redesigns.

Clearly, it’s possible to adopt a design system after it’s “too late”. But it’ll be painful. Lesson learned. There’s an ideal window for injecting a design system. I don’t think that window is uniform, but I’d wager the ramifications are.

Breaking changes suck

People know breaking changes suck. But experiencing that suck is something else. Early in the process I made various half-baked components/patterns. Against my better judgement, I implemented them into the websites nonetheless. I then had to refactor every instance once it was clear the components weren’t ready. Not fun. That kind of work is ancillary and avoidable. Better planning would have avoided find-and-replace hell.

Behind every “oopsie” are people dealing with the fallout. There are two solutions:

1. Make sure the design system cleans up after its own messes. It can be code mods or assisting with refactors. Anything to ease the pain.
2. Don’t make the mess to begin with.

There’s a time and a place for messes. Thrash can be healthy in a design system’s youth. But make sure you have a plan to blunt the impact.

The least amount of technology is the best technology

I didn’t use React for my design system. I didn’t use Vue, or whatever framework is cool today. I didn’t even use web components. I just used HTML and CSS. And that made this process so much simpler.

There was no installation process. No command line BS. No library dependencies. I wrote CSS, saved the file and viewed the results. There was a straight line from start to destination.

I never focused on framework errors or compatibility issues. We know heaping technology on top technology creates a mess. I knew messes weren’t a good thing, but experiencing reminded me why. Messes are a distraction. My focus had to include how all added technologies worked (and worked together). Sure, they were convenient, but at a cost. I understand the value of frameworks in a large team environment. But this experience further reinforced to keep things as simple as possible. Add with extreme caution.

Design systems aren’t immune from this. They’re an abstraction and can represent a detour from the direct line of goal to destination. The people who use your design system just want to get their job done. And your design system is yet another thing they need to keep track of.

“Just because” is a viable excuse

My websites had numerous instances of similar patterns with slightly different executions. Not out of malice to myself. Just because. I wasn’t thinking ahead. I forgot how I did it in the past. My focus was elsewhere. Maybe all the above.

Designers and engineers think of a design system like a carpenter thinks of a hammer. Which is to say they don’t. They’re thinking about the goal. So when people deviate from a design system, or miss some rule, there’s a 99.9% chance it’s because they were focused on other things… Like the goal. The more the design system is detached from their goal, the more because happens.

This was reminder that deviation isn’t usually from malice, but just because. The more the design system helps reach the goal, the more people will naturally use (and master) it.

Not yet doesn’t mean not ever

My design process focuses on getting the idea out of my head as quick as possible. I don’t want to spend time polishing a turd. Get things right, then clean up.

If I’m focused on the problem, I’m focused on the problem. Not hunting for components or fiddling with properties. I want the straightest path to the objective. The more the design system wrinkles that path, the less it fits in the process.

There’s three options to address this:

1. Make the design system so natural to use that it becomes the default way to work.
2. Bake in time to translate rough ideation to use the system.
3. Both.

I’d say the realistic answer is both. Of course it’d be great for a design system to create a flow state. That’s not how everyone works though. Some people prefer to wing it and get ideas out of their head. I am one of those people, so I can relate.

Seeing myself work this way reinforced that it’s OK to not use a design system. Careful pushing when folks use it, as long as it eventually happens.

Different can be a barrier

I have years of conditioning to “trust the system”. I still had a knee-jerk dislike of the subtle changes my design system had on my websites. From, my own system. Yes, ironic. I didn’t think the changes were bad. But, I was used to the old thing.

It’s fair for design system consumers to be skeptical of changes. It’s fair for them to be unhappy. Change management is part of the joy of working on a design system.

Be thoughtful of change. Not too much, not too frequent, not too abrupt. Change isn’t inherently good or bad. But either way, it demands others’ time.

The system made me naturally sweat the details more

This process exposed how much more investment I’d put into detail when it was in the system. I could shrug off a rough edge if it only showed up once. Not so much if it would be everywhere.

This can be a great forcing function for quality. It’s easier to sell investment in quality when the work will be far reaching. There’s a clearer bang for the buck. Conversely, it stings a little more to knowingly ship crap across the entire product.

This is a strong case for measuring and driving system adoption. Design systems can dramatically improve quality in a fraction of the effort. But it only if it’s used.

System design is a way of thinking

The design systems practice is being held back by its focus on artifacts. Tokens and components are an important part of design systems. But they are an output. They are the byproduct of unifying separate, but related patterns in an interface. The thinking behind that output is the real value—and its applications are endless.

This realization took the shape of my sites’ build scripts. They were unnecessarily disparate. Different build destinations, different naming conventions, some would clear the build directory, others wouldn’t. These variances didn’t lead to better outcomes. They were only a distraction.

I refactored my build scripts to work from a common codebase. All sites follow a standard convention and structure.This wouldn’t traditionally be considered a design system effort. But it required the same thinking and returned the same benefits. If it quacks like a duck…

This experience cemented my opinion. System designers should expand beyond current definitions of design systems. Find other instances of related-yet-unnecessarily-disconnected things. Connect the dots. Create order from chaos. Reap the same rewards.

There’s a whole world outside our little house we’re cloistered in. We just need to step out the door…

Don’t take my word for it

Now you know what I learned, but the lesson here is to understand for yourself. Get your hands dirty, form your own opinions based on direct experience. Don’t buy what I or anyone else is saying until you’ve lived it yourself. I bet it’ll impact your thinking more than you know.