Like most products in their early stages, the first few years at Asana we were a small team focused on shipping features and determining what we needed to do meet our initial customers needs. We weren’t building a brand, focused on scaling, or hiring like mad — as we shouldn’t have been. But as we succeeded in building the user base, it became clear that we needed to shift our focus to a longer term vision of who we were. And a stronger brand and design language had become necessary.
Before setting out on any new projects, it is always important to try to understand the problem you're trying to solve, in order to focus your work on the highest leveraged pieces. For each of the problems we identified, a subsequest goal for the system was agreed upon.
We all agreed that a consistent and cohesive product was important. And as a result, we put a lot of effort into maintaining consistency as we grew. But without a broader understanding of the design language and what we were trying to accomplish, our design became stale, boring, and un-innovative.
Designers felt constrained by rules that were unclear, unsure about which parts of the system to use and how. We were spending more time than we wanted reviewing and discussing designs that should have been simple. And instead of spending time on new problems, we were often finding ourselves revisiting or questioning decisions that had already been made. Not because we thought they needed reworking, but because we just didn’t know what had been done before.
Like most endeavors, having an agreed upon and understood set of principles and goals can help guide decisions and resolve disagreements more quickly. And while it may not seem intuitive, having a good sense of rules can empower designers to confidently and intentionally break them. Without a deep understanding of where we were, we weren’t able to take the time to move the system forward in a clear direction.
A good design system should empower designers to do their best work, not constrain them with seemingly arbitrary rules.
Even though we put effort into maintaining consistency in the web product, most of it was just on the surface. In service of speed and getting the product to market, a lot of the core features of the product were implemented as one-offs.
Even more importantly, since the design system wasn’t clear, the components built by engineers didn’t usually match up with the design system. This meant that not only was re-use not easy, the engineering team didn’t feel able to make simple design decisions, like the color or placement of a button, on their own. Without a clear foundation a design system provides, engineers were often focused on the implementation rather than the design, unable to act as true collaboration partners by providing feedback and ideas.
A good design system should foster collaboration and empower design partners to make decisions that are inline with the brand.
Because we started design with the web product, there wasn’t a system outside of that. We had a color scheme and type, but without a broader definition of the brand, it was completely unclear how implementation in one platform could translate to another. But again, because we were in our early stages, spending the time to take a step back and figure that out didn’t feel like the right use of resources.
It was feasible to use some elements from the web product in marketing, for example, but in most cases it felt awkward because the use-cases were different. We knew that on different platforms these styles could actually be different, if at a higher-level they complimented each other. But without that set of guidelines, it wasn’t clear where it made the most sense to diverge and still feel like we were conveying the same brand.
Overall, it came down to the fact that we didn’t know who we were. Externally, this resulted in a distinct lack of personality and little to no differentiation from competitors.
A good design system should be a clear implementation of your brand attributes, allow you to suffuse personality throughout the experience.
The first essential step in creating a design language is to understand the brand. At Asana, we chose to go deep into redeveloping our brand (which you can read more about here) but a rework of your brand isn’t necessary to build a system, only an understanding of it.
Creating a real and workable implementation of the brand is like turning words into action. Picking things like typeface and color is just the first step. Determining how to use these tools in your design work is where you refine those initial brand elements and truly bring your product to life.
Concurrent with the process of defining our brand, we began to work on setting out a framework for defining the overall look and feel. While we knew that some parts of it would change as our brand became more solid, this gave us a strong base to start with.
We looked at the very basics -- like how and if to use depth; the amount of whitespace; the primary color feeling of on a screen; base text size; and what interactions should feel like. And then we used this framework to help us define the most basic components that would be used across screens and platforms.
The initial framework also helped us recognize where of these elements would vary across use-cases and which may not. For example, the base type size on Marketing needed to be larger, but what interactions looked like could be shared. This allowed us to design elements like basic body copy, buttons, and form fields in a way that worked both in the product and on marketing sites that were different but still felt related to each other.
Once we had some basic elements designed, it was important to see how they worked in practice by testing them in key user flows we had wireframed earlier. This helped us know when we were going in the wrong direction, define variations, and gave an opportunity to define elements we had missed.
This was also a great way to involve the entire design team in pushing the boundaries of the system, finding holes and internalizing the language. As the lead in the development of the system, it was my role to work with each of these designers through implementation to help find where we needed to make changes.
The largest change to our visual language came out of the discovery that our brand motif, which was based on the concept of "daily flow", wasn't working. Implementing it was proving difficult across use cases and platforms, and we realized that it wasn’t doing it’s job of communicating who we wanted to be.
After a few weeks of trying to make it work — a small set of the team got into a room to rethink our motif and came out with a new concept, one of "clarity + energy". (You can read more on that process here)
The new style included a new color palette, but more importantly and new and clearer sense for how color should be used. Normally, such a large change midway through a project could have felt like we were starting over. But since we had a framework already in place, we knew the changes we made were more focused and informed.
One of the main problems we had identified early was that our brand wasn’t cohesive across platforms, so it was essential for us to make sure that we continued to revisit how we were interpreting the brand in all the use cases and work to bring the patterns together when they diverged.
The most important thing we learned here is how important it to be open to changing core elements if will help strengthen the connection between the platforms and the brand. It was during these exercises that we made the most changes to the core of the system.
A clear design system was something we all wanted, but until this effort we weren't able to devote the time to doing it well. So it was surprising that even though we all believed in the benefits, none of us expected the impact to be so immediate.
By documenting the patterns and having the entire team testing and iterating on them, we were not only all able to internalize the brand, we also changed the way we worked. We became even more collaborative and changed how we gave feedback. We were able to have discussions at a higher level, about the success of a certain design or whether the pattern worked, instead of directed towards whether we liked it or not.
We also found that by having patterns to follow, we didn't have to discuss or spend a lot of time on designs that were fairly straight foward. So some work was able to be done in a matter of hours instead of days. It was clear how it should look and work based on the components in use in the feature.
The biggest impact was how it changed the relationship between design and engineering. We believed the style guide needed to be more fully featured for it to be useful to engineers, so we didn't focus on this problem in the first iteration. However, by just making the documentation available to engineers we not only eliminated the need for redlines and mock-ups for every screen, we created a shared language with which we could communicate. By providing this language, the perspective of the engineers shifted away from implementation and towards what the design was trying to achieve.
The design language not only allowed us to create and cohesive brand, it empowered designers and design partners to collaborate at a higher level. And this more than anything else, has the largest potential to positively impact the way we work and the product we build.