Tools In The Basement

After putting my daughter to bed last weekend, I crept downstairs to finally hang pegboard and organize the jumble of tools scattered around my basement. And wow, what a therapeutic, enjoyable experience that was! As I was performing this strangely cathartic chore, I thought to myself, “How the hell did I come to acquire all these tools in the first place?” And since I was organizing a set of tools for the benefit of my future self, my brain naturally went to the world of design systems.

At the heart of a design system is a set of reusable UI components that are used to build other software products. Of course, these components aren’t the only ingredients of a design system, but they tend to steal a lot of the focus because they’re a very tangible representation of the whole effort.

There have been a few recent articles that address the disproportionate focus on components, and express concern that this focus can ignore actual user needs. Here’s Cathy Dutton with The Problem with Patterns:

Although patterns do help teams hesitate less and build things in shorter amounts of time, it is how and why a group of patterns and components are stitched together that results in great design. Cathy Dutton

And here’s Dave Feldman in Five Rants From A Cranky Designer:

A design system helps us solve problems without reinventing the wheel or creating chaos. But a design system, on its own, cannot solve user problems; and you can solve user problems — that is, do design — without a design system. Dave Feldman

This echoes sentiments and questions I hear from teams, such as “How does user testing fit into a design system?”, “How do we ensure our design system captures our users’ needs?”, “Where do personas fit into a design system?”, and “Do specific product guidelines live in a design system?”

These are all fantastic sentiments, so it’s worth exploring the relationship between real software products that serve real people and a design system that helps power those products.

What tools do I need?

Let’s come back to my earlier question: how did I acquire all those tools in my basement?

I didn’t drive to The Home Depot with a big truck and go on one giant shopping spree. As fun as that sounds (seriously, that would be awesome), arbitrarily going through the aisles of a hardware store and picking out tools doesn’t ensure you’ll actually have the materials you’ll need to complete all your home improvement projects.

Instead, I slowly but surely built up my arsenal of tools through a host of projects I’ve embarked upon over many years. When I had to drill into brick to hang a TV, I drove to Home Depot and bought masonry drill bits. When I built some workbenches that had to fit around a pipe, I drove to Home Depot and bought a jigsaw. We put up some drywall for my daughter’s nursery so I drove to Home Depot and got joint knives, mud pans, and a bunch of other stuff. Our dog thinks we go to Home Depot too much.

You get the idea. The specific tools in my basement are a result of specific projects I work on around my house. And so it goes (or should go) for a design system. The inimitable Yesenia Perez-Cruz said it best in her presentation Scenario-Driven Design Systems:

Start your design system with user scenarios. Yesenia Perez-Cruz

After all, real products with real user scenarios are where the rubber meets the road. It’s possible to create components in a vacuum, but ultimately you have no idea whether or not those components can successfully address your user and business needs. I’ve witnessed firsthand several design system initiatives crash and burn due to components created in isolation.

This is also one legitimate concern about teams immediately reaching for existing frameworks like Material Design or Bootstrap to do the heavy lifting for them. These tools are great, but they’re tuned for someone else’s organization so may not necessarily address your organization’s unique needs.

Tools by themselves don’t do the work

Each tool has certain properties (saws have sharp teeth, pliers have pinchers, a hammer has a flat surface), and these affordances hint at the tasks they could be employed to perform. But the tools in my basement don’t by themselves magically fix my always-running toilet, fix the leak in my ceiling, or install the cupboards in my kitchen. I still have to use my brain and motor skills to do the work. The tools in my basement absolutely help me do that work and do it effectively. I wouldn’t be able to complete my projects without these tools, but they’re not enchanted objects that magically do my work for me.

So how do we do successful work that ensures our design systems’ components truly address our user needs?

Atomic design & pilot projects

Atomic design is a methodology for thinking of UIs as a thoughtful hierarchy. But that’s not all it does. It also connects the dots between reusable UI components and real product screens. I’m finding that 5+ years after creating the methodology that one of the biggest benefits it provides is the ability to draw a straight line between reusable UI components and specific arrangements of those components to address specific user needs.

It’s at the page level of atomic design where we’re able do the hard work of creating UIs that represent real user scenarios. We’re able to design with dynamic data to ensure our design system is sturdy and can accommodate best-case user scenarios, worst-case user scenarios, and everything in between:

What if the user doesn’t upload a profile picture? What if the user has 87 items in their shopping cart? What if the product has 14 options? What if the blog post title contains 400 characters? What about a returning user? A first-time user? What if the article doesn’t have any comments? What if it has seven layers of nested comments? What if we need to display an urgent message on the dashboard?

This is why our design system process relies heavily on pilot projects. By building our design systems through the lens of real projects, we’re not just making user scenarios up or building UI components in the abstract. By combining the atomic design mental model with pilot projects, we’re able to ensure the reusable components we create are born of real user and business needs. Jina says it best:

The Design System informs our Product Design. Our Product Design informs the Design System. Jina Anne

It’s this virtuous cycle that makes for both a sturdy design system and solid product work.

I have to travel to Home Depot less and less as my tool collection grows more comprehensive. By maintaining a set of well-organized tools I acquired through real projects, I’m able to do more future projects without having to waste precious time and money buying more stuff.  In the world of design systems, every subsequent project can help fill in the gaps in a system, making it stronger, more comprehensive, and more capable of handling more user scenarios.