When I joined OfficeSpace Software in 2021, it was at a time when the design practice encountering some growing pains. The design language used in the product was the solo effort of one of the original founders, and as you’d expect from a bootstrapped startup, it had evolved without strict governance, adapting to each new feature and leaving a trail of UI and tech debt in its wake. But I was onboarded at a time when the product was reaching an adolescence and our design team was expanding. We created a design system, built a new front-end framework, and started introducing more documentation and (gasp) bureaucracy to our process, all necessary to keep our things running efficiently with more people on board.
Eventually, we reached a stage where we felt we needed a set of design principles to guide our decision making. I want to share my opinions on what makes for good design principles and the approach we took to develop ours at OfficeSpace.
Avoiding Common Mistakes
Design principles exist to articulate a strategy, and a strategy is a bet: a gamble that prioritizing one approach over alternatives will yield better results.
If your principles reflect a strategy, they will give direction when the way forward is unclear. Which is more important, streamlining complexity or encouraging mastery? Unique interactions or familiar ones? Surprise and delight, or transparency and trust?
Too often, I found the principles I researched before starting this process to be overly general. They tried to cover the waterfront, with anodyne, forgettable results. If the principles you come up with can be copy-pasted into any other organization, they’re not strategic enough in nature. Yes, they may tap into foundational best practices, but ultimately they should feel tailored, not off-the-rack.
Another potential point of failure is where your principles originate. They should be a reflection of the culture and ideas of your entire team. If instead they’re dictated from on high, it’s easy for them to be ignored because no one has a stake in them and perhaps even their opinions differ.
A Collaborative Process
Starting with a team workshop, we took the first step of considering what we wanted out of our design principles and what factors about OfficeSpace made our situation unique. We gave each designer time to write down phrases or concepts that they wanted to see fulfilled in our user experience—things like “rigorous consistency,” “make complex tasks efficient,” and “clear information hierarchy.”
We then grouped these concepts by theme and examined them. Based on their natural variance, we agreed on four groupings that would become our core principles, and then haggled over the exact wording that felt right to summarize each grouping. At the end of the workshop, we had our principles: Empathy, Purpose, Clarity, and Consistency. But we also had something more important: buy-in from everyone on the team.
Contextualizing the Result
On their own, these principles suffer from some of the pitfalls I mentioned earlier. While it’s important that the final result be simple and easy to remember, we didn’t want to leave behind the details that went behind each of them. We wanted our final document to include:
- The risks we were seeking to mitigate with each principle
- The methods we should use to employ each principle
- What the observable outcome would be and what metrics would be affected if we follow each principle
So I created the following table:
| What risk do we need to mitigate? | What principle helps us do that? | How do we employ this principle? | What’s the outcome of this principle? |
|---|---|---|---|
| Prioritizing business goals over user goals; forgetting to design for distinct roles | Empathy | Center the user’s story.
| Users report a positive experience in OfficeSpace and are return frequently (NPS, MAUs). |
| The tendency to forget that our users’ needs are mostly external to our product | Purpose | Design flows, not static views.
| Users accomplish their goals, even if it means spending less time in OfficeSpace (Time on Task) |
| Attempting to over-simplify when it's not appropriate or possible to do so | Clarity | Don’t fight against inherent complexity—manage it with clarity.
| Users feel in control of their experience at all times even during complex operations. At a high level, they have an accurate understanding of our system and how to use it. (Support Requests) |
| Drifting off-system without good rationale or because it's the path of least resistance | Consistency | Be rigorous about consistency in our designs and their implementation.
| Users always have the “confidence to click.” They feel the safety to explore and manipulate the UI because the design system is logically sound. They trust the product. (Feature Adoption) |
This, I think, is what turns this from a naval-gazing exercise into something truly useful. The top level principles are good shorthand, but by studying this table, any designer on the team can check their work against these principles in a more meaningful way.
Of course, what you leave out is just as important as what you put in. You’ll notice some popular ideas are not part of our set, like “simplicity” or “delight.” That’s because these concepts don’t align with our strategy. Seeking pure simplification is missing the point; instead, we should bring clarity without sacrificing the control we’re giving the user. Likewise, manufactured charm doesn’t jive with our users who have important goals to accomplish in short amounts of time. Understanding these trade-offs is empowering.
Outcome
Each team member got our principles tattooed on their wrists and we recite them together in a pledge in our weekly team meeting.
Kidding. Obviously, no matter how well-intentioned you are with a document like this, it is destined to sit on the proverbial shelf. That’s its place. I won’t lie to you and say that we refer to this document on a daily basis.
But that was never really the goal, after all. These principles exist to unstick our designers when they can’t choose between two potential approaches, to better contextualize their work in design reviews, and defend their decision making in presentations to stakeholders. They come up when they’re needed. They’re a reflection our own individual principles, something we own together, and, hopefully, another tool that helps us build better experiences for our users.
