Stephanie Hornung


Asana Web Product

Asana is an enterprise product aimed to help teams work together effortlessly. Teams of all shapes and sizes can manage projects, hit deadlines, and have clear responsibilties over their work.

As the first designer at Asana, I saw the company from pre-launch to over 140,000 companies actively collaborating on the platform everyday.


I was responsible for designing and launching the first paid product, as well as Organizations, which allowed large teams to work together more easily.

Organizations enabled teams within organizations to collaborate by adding more robust permissions, project organizational structures, and automated signup of new employees. Read more in this NY Times coverage of the launch

Both of these products are responsible for 10s of millions of ARR and a revenue growth rate of 2.3x in the last year.

Asana Redesign Architecture


As Asana grew in functionality, we were finding that the early simplicity of the product no longer held true. Users were having trouble finding features, and reported a general feeling of being overwhelmed. We had a vision of being a powerful and flexible tool, so we knew we needed to do something to make the experience more extensible to the features our users were asking for, as well as where we saw our business going.

An Asana project showing the project overview on the right. Users were confused by this hierarchy, and we were constrained by our two-pane model.

Object map and sketches

Approach to Ideation

A few features made it pretty obvious to the team that we needed to rework our architecture, so we started exploring different options.

  • During those telling projects, we started sketching ideas for how projects, our main feature, could grow in functionality.
  • I created an object map to get a better sense for the kinds of information we wanted available and where. This ensured we were creating something extensible and focusing efforts in the most worthwhile area.
  • As a way to quickly generate ideas and gather buy-in from the team, we spent a few days off-site focusing on and our key use-cases.

Variety of ideas from the team generated during the off-site.


After the redesignathon, it was important to keep the momentum going.

  • A member of the team pulled together the ideas and created a high-level concept for where we wanted the product to go.
  • We tried to break down the big decisions early, to make sure we were working with the right constraints.
  • User Research helped by running quick studies for each of those decisions to find what worked and what didn't.
  • We remained open to revisiting certain decisions if we found they were creating false constraints down the line.

Concept mocks created by a team member, which we used to guide us.

Initial panel structure implemented on different page types, we found it to be too constraining. Followed by the next iteration, which lead to what was implemented.


The launch of the redesigned product was highly successful by any measure, even outside the impact of the visual change/rebrand.

  • Half of a percent (.5%) of current users chose to stay with the old design by the end of the day the product was launched
  • Much of the qualitative feedback implied that users thought new features were added, when in fact they hadn't. The design had just made it clearer.

Asana Design Language

A major part of the recent Asana Rebrand was the development of a clear design language that was representative of our new brand.


The design system had several goals that guided the work and ensured we stayed focused.

  • Be a clear implementation of brand attributes, allowing to suffuse personality and differentiation throughout the experience.
  • Empower designers to do their best work, not constrain them with seemingly arbitrary rules.
  • Foster collaboration and empower design partners to make decisions that are inline with the brand.

Inventory of buttons in use

New button styles


The design system was set to work across Product, Marketing, and Mobile, so it was important to involve the entire design team in the process.

  • To get started, I did an inventory of the items in the current product that should be considered a reusable element, even if they weren't implemented that way.
  • This served as a basic framework to design the new language, where we started with the simplest, most low-level ones.
  • The team test elements in key flows early and often to identify new patterns and places to iterate.
  • We compared across platforms to stay cohesive.
  • We consistently document guidelines through the entire process stay focused and on the same page.


While the design system will never be complete, documenting the language and having it available to the greater team had further reaching impact than we had expected.

  • Design time to re-skin features took a matter of hours rather than days.
  • Design handoffs to engineers no longer requires redlines or detailed mocks of every screen.
  • Design/engineering collaboration can now focus on user goals, instead of implementation details.
  • Product and brand is stronger and more cohesive.