Asana Design Language

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.

Defining the problem

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.

Designing the product was more difficult, time-consuming, and often not as good as we knew it could be.

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.

The complexity of the UI and number of variations made it difficult to pick out the system

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.

Identified Goal

A good design system should empower designers to do their best work, not constrain them with seemingly arbitrary rules.

Implementation and iteration wasn’t simple

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.

As an example, each of these buttons were implemented slightly differently.

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.

Identified Goal

A good design system should foster collaboration and empower design partners to make decisions that are inline with the brand.

Consistency across platforms was even more complicated

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.

An early marketing site, along with a help center, iOS and Android apps. The latter are in an interim visual style.

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.

Identified Goal

A good design system should be a clear implementation of your brand attributes, allow you to suffuse personality throughout the experience.

Developing the design language

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.

We started with the basics

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.

Early pass at some of the basic elements of the design system

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.

Examples of different size elements for different use cases that are obviously part of the same system. And on mobile we agreed it was more important to follow platform conventions in certain places.

Testing in key flows informed us early and often

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.

We identified more patterns...

Avatars appear in many places in Asana, so it was important to have set sizes and rules about when to use them.

Communications is a core feature of the application, so we developed a robust system for the comment module (of which this shows only a small part.)

Iterated based on need...

Through testing, we found that the list item spacing was excessive in cases where the lists were long. Since the original was based on the tall button, we created a variation to match the smaller, more commonly used button.

We began our design with a strongly purple neutral palette, to match the original dark purple in the new logo. As we used it and our needs changed, it was updated and interated on several times.

One of the places we iterated the most was on our button styles. We revisted the color (several times), the state model, and the depth to work better with our evolving brand, look and feel and overall color system.

...And there were some revolutions!

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.

A fraction of the iterations we did for web and marketing using the "daily flow" motif.

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.

Because the new motif was based on being mostly neutral in its steady state, it was necessary to update our color usage to be more energetic in times of interaction and celebration.

We also tested the new motif in a few different contexts to find where else the system needed to be updated.

Comparing across platform kept us cohesive

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.

Original designs used green for the main "add" action, but we discovered on mobile that the brand identity was lost and the product didn't have the energy we wanted.

On mobile we were finding that purple buttons were both less clear than blue and made screens more colorful and scattershot than we wanted. By going back to blue as the accent color we were able to focus the UI and strengthen the coral as a brand color.

Results

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.

Just a few of the pages that were part of the design language documentation.

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.