An illustrated, experimental, approach to design system principles
We did it! We made a design system this year called Blocks, adding CBRE Build to the 85% of tech teams who have a design system. Most of them also have articles about their design system journeys. These articles usually go into detail about how to structure a core design system team, how to get stakeholder buy-in, and how to build versioned pattern libraries. What they tend to gloss over is the messy process of defining design system principles. Why? Because design system principles are a lot like love. Everyone agrees that they are fundamentally important but no one agrees on what they are or what bigger purpose they serve. And good luck trying to find a no-BS guide to falling in love — or defining principles — without a lot of clichés and hand waving.
I’m going to tell you our team’s love story — messy entrails and all. I’m not promising it’ll be replicable but maybe it’ll be relatable.
“Research”
January was a rabbit hole of research. I started with the classics of the Design System genre — Design Better, Brad Frost, Alla Kholmatova — then moved onto binge-reading every Medium think piece I could find. I had open tabs on tabs on tabs. At this point I had barely defined a style guide for the product I was designing, but I felt like I could write a dissertation (or at least a solid term paper) on Design Systems.
In hindsight, this insane early hubris probably got Blocks off the ground. I was a local maximum — the most knowledgeable of the people in my immediate vicinity — and therefore an expert. I thought I knew what I was doing so others did too. What started as a haphazard solo project gained traction with engineers, researchers, product managers, and other designers. Over a few short months our style guide expanded to a React pattern library, our design team doubled with two new designers, and we suddenly had one of those core design system teams I had read about. While we built components and patterns, I conveniently ignored the problem of foundational principles.
I reasoned that we had never standardized any of our components before — between products or even within them. We needed to create consistent patterns first and perfect them later. I figured the principles would sort themselves out naturally and that the team would A Beautiful Mind our way into seeing the underlying foundation of our newly consistent components. Spoiler alert: we didn’t.
Existential Crisis
Another month passed and no stone tablets with principles appeared. I went back to my trusted Medium articles and presented my findings to the core team. I regurgitated a lot of definitions and examples of other companies’ principles but I had no point of view. Some companies use principles to define their brand, others use them to define their culture, still others have principles to define their design process. In my head, our principles would work for all of these use cases — and more! I delegated (read: punted) the task of actually defining principles to others in the team.
When I asked people to brainstorm principles based on my super vague descriptions, disaster struck. I was met with blank stares and a barrage of questions I had no real answers to: Why do we need principles? What are the principles for? How do people actually use principles in day to day design, engineering, and product work? I had committed the cardinal sin of product design and ignored the user needs of the people using the system.
What’s Love Got to Do With it
My confidence was further shaken when I started digging into these questions. The blueprints of other companies and product teams didn’t make sense for what we were trying to build. Each of our products had its own unique product development histories, users, and product strategies with seemingly little overlap. How could we create principles that applied to each of our products and product teams when we lacked any sort of formalized product ethos or vision? The problem seemed tautological.
Luckily, two researchers in the core team helped us reframe the problem and take practical steps away from this roadblock when they asked us to write love letters to our products from our users’ perspectives. We wrote things like:
“Come back to me, and remember to bring your on-the-fly headcount statistics, and wear them with that flowy horizontal graph bars that I like so much on you.”
“We hope that one day, you’ll grace the world with an easy to use UI and intuitive UX.”
“You ask me things about me, you listen carefully, you seem interested. And then you think about it. You draw on experiences that I don’t have.”
It was awkward, silly, and exactly what we needed.
This exercise forced us to put into words what we value the most in our products. We dissected each love letter, pulled out key words and themes onto post-its, and realized we valued a lot of the same things across our products. The word cloud created out of those sticky notes became the basis for our our eventual principles.
A Dubious Experimental Methodology
I’d like to say that once we did the love letter exercise our principles came to us easily. In reality, we had a lot of nascent ideas and no consensus about how to proceed with any of them. So we put the problem on the back burner again for a few months. This was probably the most frustrating period of the entire process. We knew we were onto something but we kept having the same discussions about how to best turn mushy love letter values into solid principles. We felt paralyzed.
To get out of this seemingly interminable standstill, we stopped worrying about wording and wrote up three test principles that captured the gist of the love letters. We devised a month-long experiment to test two hypotheses:
- Having product principles to help guide individual and team decision making meaningfully improves our collective product process.
- Our 3 test product principles were necessary and sufficient.
Approaching the problem of defining Design System Principles as an experiment freed us from our perfectionist paralysis. We called our experiment the Product Principles Pilot (PPP) and laid out some ground rules:
- Our principles are accepted rules of action or conduct used to guide our product process.
- Our principles govern our approach to building products but don’t apply to our company brand or to our broader company philosophies or ethics.
- Our principles follow the Wall Street Journal criteria for good principles.
We tested these potential principles with 16 participants from every product team and discipline. We gave each participant a copy of the test principles to keep near their desk and reminded them three times over the course of the month about the PPP. To establish a baseline for our existing product process and what wasn’t, we asked participants to evaluate their own and their teams’ efficacy with 15 agree/disagree statements like:
- “I am empowered to try new things and make mistakes,”
- “My team spends an appropriate amount of time making feature-level decisions,” and
- “My team agrees on our objectives.”
We hoped for some sort of validation that all these months of guess and check were worthwhile.
“Analysis”
The validation came when we looked at the difference between the survey responses at the beginning and end of the month. The results surpassed all our expectations. Across the board, the average score for each statement increased significantly.
By the end of the month, the average participant felt more effective in their role and more confident in their teams’ abilities to make decisions. Of course, we had no control group so our results might just be confirmation bias. But whatever the causation was, the testimonials from the survey are hard to ignore.
Specifically, an engineer said the principles helped their team make decisions faster, a designer said they felt more prepared in meetings when they used the principles, and a product manager even said the principles empowered them.
The surveys showed that having principles helped us work better individually and together. We had criteria to judge the efficacy of principles. We finally had answers to those tricky existential questions — and they were backed by almost real science! Reworking and polishing up the principles we tested was luckily fairly straightforward. After two working sessions with our criteria in mind and thesauruses in hand, we arrived at principles we could be proud of.
Engagement Party
If you’ve been skimming this article just to find out what our principles are, you’re in luck. After half a year of ups and downs, these are the design system principles our team has made a loving commitment to:
- Confirmation over Creation
- Progress over Perfection
- Alignment over Assumption
There were a lot of times over the past year I wasn’t sure if this day would ever come. If I had to do it all again differently, I would have:
- Synthesized all my research at the beginning into a clear thesis instead of trying to crowdsource principles with no definition or direction (Confirmation over Creation).
- Investigated the underlying problems we were facing in our own product process instead of trying out ideas that worked for other teams (Alignment over Assumption).
- Spent less time worrying if I was approaching the problem the right way and more time testing things out (Progress over Perfection).
In spite of the mistakes we made along the way, we fell in love and you can too.
