Illustrated by the amazing Hannah Swann

Designing Timeline: Lessons Learned From Our Journey Beyond Gantt Charts

Nicolle Matson
Dec 18, 2018 · 8 min read

At Asana, we see the Product Design team as core to creating positive outcomes for our customers, and we know that good design thinking includes understanding technical complexities, business and product considerations, and strategic decisions based on user experience. We believe design should inform our road map, and we encourage our designers to push boundaries and offer new ideas for enterprise software. I’ll walk through how we applied this type of product design strategy and thinking on our Timeline feature.

Our Mission with Timeline

Asana is a work management platform used to track work across teams, and many of our customers are used to traditional, legacy solutions. But like all of our projects, we wanted Timeline to exceed, not just meet, customer expectations. Our team was able to work through major trade-offs and make design-informed, usability-focused decisions to develop a system that help our users seamlessly and fluidly collaborate.


Exploring the pain points

When the Timeline project began, the Product Design team synced heavily with customer-facing teams, including User Experience Research (UXR) and Customer Success. We already had a good sense of our customers’ pain points:

  • “I don’t have visibility into my entire project.”
  • “I need to share my project with my boss so they know where we are.”
  • “I need to see how my work will affect others.”

Each anecdote reflected an underlying problem: our customers needed a visualization that could show them at a glance what was going on across their projects, teams, and company. They needed to see the relationships between their work — even when tasks were tied to different departments or had different statuses — so they could transparently organize and distribute duties across teams.

We dug deeper into the problem and noticed our customers often bounced between Asana and other tools. Some wrote tasks on Post-its and mapped them out on a wall, then somehow translated that to Asana. Others used Excel spreadsheets or other Gantt chart–like software. But no matter the method, everyone was seeking the same thing: a holistic view of their projects, complete with timelines, tasks, and milestones.

Someone’s calendar in Asana. Describing how they print their calendar and draws in length of time.
Someone using Excel to map out their longterm timeline

Going fluid

It would have been relatively easy for us to add a typical Gantt chart, which is a type of bar chart that shows a project’s schedule, including dependencies between tasks. But we knew that wouldn’t be enough to satisfy all of our customers. Instead, we wanted to create a flexible UI — a Gantt-like structure, but one in which users could easily manipulate tasks on a canvas. After gathering input from customers, we came up with what we called a “Fluid” layout.

Fluid layout

The Fluid layout was constructed like a Gantt chart, but with a twist: each task could be arranged however our customers saw fit. The design was flexible, yet orderly — and a differentiator for Timeline. But this approach came with new design challenges.

First draft of tasks on Timeline with different durations

Going Fluid meant removing the left column that most traditional Gantt tools have, and as a result, customers were having difficulty telling tasks apart. If we wanted to move away from a traditional Gantt structure and still be accessible, we needed to ask ourselves: How will users be able to read or understand which task is what? How can we make it obvious that users can drag and drop tasks? How will all of these interactions work at different zoom levels?

To make sure Timeline would be intuitive and easy to use, we mapped out all of the scenarios for a task and developed detailed rules for its look and function in each instance.

Mapping out all task scenarios

We presented these new designs to our users, and doing so made a world of a difference. We would be in a very different place if we didn’t continue to listen to our users and make quick iterations on the designs — even when we were already in the process of building out Timeline. We continued to course-correct our designs throughout the project.


The power of prototypes

A challenge we faced while exploring the Fluid approach was how to describe interactions that would make Timeline powerful and different from traditional Gantt charts. We wanted users to have the flexibility to drag and drop tasks left-to-right and up-and-down, multi-select them, and/or insert tasks within rows.

Our team is based in NYC, which made it tough to describe to our SF-based teammates how we wanted the interactions to work. Our discussions were generating novels of explanations, questions, and concerns through Slack or commenting, which took up a lot of time. So, since we were designing something completely new for Asana, we decided articulating animation concepts would be easiest by describing interactions through a prototype. We used Framer to demonstrate complex interactions. By scoping in a couple of hours to animate key concepts, we were able to quickly validate ideas and get buy-in from our colleagues across departments — and across the country — as well as from our customers.

If you’re not familiar with prototyping tools, you might say it’s hard to learn a new program while you’re in the middle of designing a project. But we’d say that sitting with someone who is familiar with a prototyping tool or an engineer who is quick with Javascript is totally worth the time! Keeping things bite-size, without too much detail, can help get any idea across faster in your prototypes.

Example of Timeline interacting with tasks

Making Trade-offs

After months of development and hundreds of hours talking with customers, Timeline was ready for beta release. During beta, we saw two critical issues consistently emerge: how our customers categorized their work, and how intuitive and accessible Timeline would be.

Categorization

Categorizing work took a number of forms, including organizing a project by phases. (An example of phase categorization would be a film production schedule: Casting → Shooting → Editing.) Other forms of categorization would be adding sections, sorting, and checking statuses. We were able to solve for most of these approaches, but the biggest one was sectioning — or in other words, visually distinguishing buckets of work.

Examples of how Timeline could categorize work

Discoverability

The beta release revealed that people weren’t discovering task interactions for the Fluid experience. For example, many users didn’t realize they could click and drag the edges of a task to extend its due date. We needed quick wins to make sure our UI was accessible enough for people to understand how to use Timeline.

Making sure that the UI is easy to use

Unfortunately, time wasn’t on our side. Our launch date was looming, and we knew we wouldn’t be able to solve both the work categorization and accessibility problems before our launch date. We had to choose one area to tackle before launch and follow up on the other later. Through many discussions with customers and teammates, we decided we needed more insight on how teams categorized their work and that our immediate priority should be giving users a high-quality experience through accessibility.

In retrospect, it was a good trade-off. If users understood how to use the new UI, we could learn how they’d want to categorize their work and get a deeper understanding of what they needed. It took a few more weeks than we’d planned, but having a clear UI was worth the wait.


Looking back

After launch, we were pleasantly surprised by how many customers quickly adopted Timeline, but the best part was how they were using it. The vast majority of tasks — 94 percent of them — were scheduled via drag and drop, and customers took full advantage of the different ways to arrange Timeline, including side-by-side, waterfall, and mental mapping. We’d known the risks of designing a system that went beyond the traditional Gantt chart, and it was extremely rewarding to see those risks pay off, both for our customers and our team.

There’s no strict formula for designing new features. Like all new projects at Asana, it was important to begin Timeline with a deep understanding our customers’ pain points and the problem we were trying to solve. Here’s a few key takeaways we’ve learned to help us make good design decisions on future projects:

1. Keep listening

As obvious as this sounds, by continually listening to what our customers were saying throughout the entire project, the team was able to identify solutions that made sense for a range of workflows. By embracing research from the start, we were able to accommodate a wide variety of customer needs.

2. Prototyping is worth it

Communicating via prototype was the easiest way to get our ideas across and make decisions. The animations we built were the best way to illustrate the complexities of a new feature and demonstrate what it would actually feel like to use Timeline. The prototypes helped us get buy-in from all stakeholders, including our teammates and our customers. And because we were able to get aligned quickly, everyone felt empowered to contribute more toward the overall design.

3. Make calculated trade-offs

When we realized Timeline would not be ready for our planned launch day, we were thoughtful about our priorities — including the projects we pushed down the list. We accepted that key components would need to be added in order to make the feature ideal for all workflows and recognized that we’d require additional time and resources. We made calculated design trade-offs to ensure we launched with a high-quality product, and also followed up on other issues by shifting our product road map for the subsequent months. At many companies, little time is dedicated to fixing bugs and polishing a feature after it’s launched. At Asana, we’re committed to improving our product.


For Timeline, the improvements continue today. We’re still sharing our designs and decisions with customers and other stakeholders, and we still have a lot to learn. By adjusting our goals to reflect those lessons as we go, we feel confident that we can deliver an increasingly useful, powerful tool for our customers.

Learn more about Timeline.


👋

Interested in finding out more about Asana? We have a neat site up at https://asana.design with a little about who we are and what we do. We’re also hiring Design Managers and Product Designers in our San Francisco office, one of the 2018 best places to work in the US! (We can relocate you if you’re not currently based in the Bay Area.)

If you enjoyed this post, you might want to follow our publication for more stories from Asana Design

Asana Design

Stories and lessons learned from the Asana Design team

Nicolle Matson

Written by

Product Designer @ Asana : Making Stuff

Asana Design

Stories and lessons learned from the Asana Design team

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade