Aligning your team through design principles
How to spend less time discussing design and more time doing it.
It’s easy for design discussions to devolve into three hour tangents of everyone needing their opinion to be heard. But as designers, we know that iteration and critique are crucial to the design process. Luckily, many disagreements that seem like they are fundamental to your design are actually based on differences in prioritization or understanding of larger goals, not the drama-prone situation of one person being wrong and another right.
If a team member insists a button be big and blue, but you believe it should be subtle, chances are you’re focusing on different problems. This isn’t an argument about taste, it’s a disagreement on what the feature is for.
In cases like this, developing design principles can help your team make decisions more consistently and quickly, without drama and with full buy-in. We recently developed a set of principles at Asana, and I’d love to share our process.
A few years ago, when I started designing at Asana, I knew what our larger goals of the product were, but the exact details of how we were going to accomplish them were pretty unclear. This is how it should be —building a new product means a lot of iteration, trying new ideas, and moving quickly.
But recently, as the product has grown in functionality and our vision matured, intentionality in our design has felt just as important as speed of implementation. We want to be more aware of the impact of each little product change, and need a framework to balance the inevitable myopia that comes from focusing on features.
In other words, when you move fast and don’t consider every step, it’s really easy to lose sight of your larger vision. You tend to think what you’re working on is the most important thing ever for your product, because why would you be spending your precious time on it if it wasn’t? But this narrow focus can be dangerous, as you lose sight of the bigger picture.
As a company focused on teamwork, it’s probably no surprise that we wanted to be more productive in our design discussions. And since we care so much about our product vision, it seemed like the right time for us to develop a set of principles to guide us.
What are design principles, anyway?
We did a bit of research and found that principles can vary widely. They can be broad and inspiring, specific and guiding, or seemingly simple and obvious — but each reflected the culture of the teams that were using them.
With that in mind, we wanted to make sure that if we were going to spend the time to write them, they needed to be useful. They needed to be a way for us to express our culture and allow us to consistently and meaningfully represent ourselves through our product.
Design Principles should help the product team remain focused on a consistent vision of what makes our product experience unique. They should be specific enough to differentiate us from other products, reflect our values, and help us make decisions; but be broad enough to apply universally to our product.
The process
Writing principles that are both useful and broad meant that we needed to take a two-pronged approach — exploring both the nitty-gritty details of when we could have used guidance, and the high-level goals of what we wanted our product to be.
In service of being useful, we started by recording real instances where we could use direction in our decision-making. This list included questions around the importance of direct editability, the appropriate times for innovation, and how focused on power-users we should be.
These were the sticking points we kept coming across in our disagreements, places we weren’t consistently choosing the best balance point.
At the same time, the team got together to discuss the product goals we often referenced but never formalized. From the beginning, we believed that our product needed to be frictionless, empowering, transparent, and simple. But were we succeeding at this? Did we still believe in these goals? What did we actually mean by these words? The outcome here was mostly ensuring that these goals were better understood, but they were still too broad to be useful as principles.
Now that we had a list of real-life instances where we could have used principles, and a better outline of our product goals, our next step was to reconcile them. Each team member chose a few of the points in our list that were the most contentious and suggested a balance point, with examples. These acted as catalysts for finding patterns (and anti-patterns), and identifying specifically how we were doing in relation to the product goals we identified earlier.
We asked ourselves questions like:
What is the right way to notify people of messages without sidetracking them from the work they’re trying to get done?
Was direct-editability the most appropriate way of creating a frictionless UI?
What role should our UI play in team-connectedness in relation to helping people feel empowered and be productive?
The next step is a bit fuzzy. I spent several days looking at those other principles again (plus a few more), this time looking for inspiration and thinking about what differentiates us. With a focus on being useful and expressive, I looked for ideas for how to frame our viewpoints concisely, while remaining grounded in the reality of the list we had collected earlier.
With all that in mind, I began organizing the small issues under the larger goals and found patterns. I looked for ways to have principles balance against each other, since each principle on it’s own doesn’t define the experience we want to create. And above all, I wanted to inspire us to be true to our vision, and give us a defined space within which we could explore because we better understood our direction.
The Principles
Allow users to focus on their work without interference.
A user’s focus should be in their control, only distract users with changes that are personally relevant.
Increase confidence through clarity.
Within the application, and more broadly within teams, it is unambiguous what is happening and why.
Foster productive and emotionally satisfying interpersonal dynamics.
Users feel like they are part of a team, where they can count on each other to do their part, and feel like they’re moving forward towards a common goal.
Design for fast, effortless, and intentional interactions.
Simple and common tasks should be frictionless and obvious; complex tasks should feel efficient and delightful. But, speed should not lead to inaccuracies.
Empower everyone through progressive discoverability.
Everyone at all levels of experience with Asana should feel like they know how to use the product, regardless of how many features they use.
Be consistent and standard, and innovate when it’s worth it.
Users should feel like Asana is familiar, yet modern.
Mindfulness is one of the most important aspects of our company culture, and it was time for us to bring that more fully into our design process. We’re looking for ways to ensure we remember to use them, including creating artifacts like posters and stickers, and appointing an owner for each principle to ensure it is considered.
I am really looking forward to internalizing these principles, and can’t wait for everyone to experience the next generation Asana as we push forward into the future.
