Designing Timeline: Lessons Learned From Our Journey Beyond Gantt Charts
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.
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.
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.
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.
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.
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.
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.
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.
👋
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
