On August 2016 Asana launched the Offline mode for both Android and iPhone users.
The project came from the necessity of users to keep working continuously in Asana while they had poor connectivity, or no internet connection at all.
Goals: • Make the product functional without connection. • Inform the users while staying out of the way. • Create a consistent cross-platform UX and UI system.
After several iterations we decided to go for an unobtrusive design based on two pillars.
First, an informative bar that stated the current status and informed the users that the changes were not synced. That way we made the users feel safe by telling them their changes were stored and would be uploaded when connection was restored.
And second, a simple UI based on color and iconography, repeated across the board so it would become familiar. The new and edited items would become lighter (wether it was text or an image) and a cloud with an “x“ would appear next to them.
The simplicity of the design made it easy to port between platforms while staying consistent within the Asana Design Stylebook. At the same time, it made it really versatile and easy to extend every time a new feature hit the app.
For the users, this feature meant they could keep on working without having to worry if the connection was interrupted, and with a product that did what it was supposed to do and reassuring their information was safely stored along the way.
Information bar (Android, iOS). Each platform required a different placement to avoid interfering with platform-specific UI.
A new comment while offline. (Android, iOS)
View of task list with multiple items pending to sync. (Android, iOS)
Adding followers. (Android, iOS)
New Project (Android) and New Conversation (iOS)
New comment with an attachment before and after syncing (iOS).
In September 2014 the Asana product and design teams gathered to create a vision for "the new Asana".
Goals: • Make the product more approachable • Maximize clarity • Separate the company from competitors • Express the character of Asana
As a Senior Product Designer I paired with the Head of Product and Co-Founder, Justin Rosenstein. We sat together and discussed about our goals, finding ways to turn them into design patterns.
After sketching, I created these concepts and we reviewed them with the larger Design and Product teams. These concepts were the some of the first steps of the Asana Redesign that launched September 30, 2016. Many of these concepts shipped to users much earlier.
One of my first projects at Asana was the Asana Dashboards feature.
Reporting was a highly requested feature from users, and user research indicated that users would benefit from a visual representation of the status of their projects. Team Leads wanted to be able to quickly check that everything was on track.
Goals: • Be able to scan project status at a glance • Visualize progress at a glance • Choose the most relevant projects • Ease the communication between Team Leads and Project Leads
Asana Projects already had a Progress tab, which included a burn-up chart. In order to maximize consistency and ship quickly we used that chart as a starting point.
As a Senior Product Designer I worked with the PM to define what our users needed. We discovered through iteration and user research, that users wanted to see as many projects as possible on their screen, rather than more information about each project. We balanced this by surfacing a project summary: the project's Status Color, the first lines of the last Status Update, and at-a-glance data like Project Due Date and Project Owner.
Dashboards was launched as a premium feature, and quickly became one of the most successful launches and a top revenue driver for Asana.
Custom Fields on Boards
Custom Fields in Asana allow you to add custom metadata to tasks in your projects.
Boards view (also known as kanban) is a condensed view of cards. This view is really poweful for agile frameworks like SCRUM. So we needed to include the user-generated metadata on the cards.
Goals: • Display Custom Fields on boards • Keep the noise level to a minimum • Balance information-density • Don’t break user flows
As a Senior Product Designer I paired with the PM to define what the users really needed. We explored and tested to see if labels were necessary, but they turned out to add more confusion than clarity on empty fields. We also decided not to pursue editable fields on cards, because they would interfere with the existing user flows, since the user priority in this view is to scan for information and move the cards around; the edit flow happens when the user opens the details not in the general view.
In order to display more content and keep the same number of cards per view we had to redesign the cards visually. Minimal typography and margins adjusted turned into a view that included more information than the original, without losing the much-needed whitespace.