Asana Goals to Decks
Asana Case Study
Product Designer
How might we create a way for people to seamlessly share their Asana goals and OKR’s to their stakeholders?
Asana Goals is a relatively new, but major feature introduced into the product roadmap. Goals are a flexible goal-tracking system that helps drive measurable results by providing a single source of truth for setting and tracking goals where your teams execute work.
Adoption of Asana Goals had been very high, but there had been lots of user feedback around pain points with exporting these goals.
Exporting existed in other parts of the product (in the projects and portfolios section, for example) but the functionality didn’t exist for Asana goals.
Role:
Product Designer
Skills:
End-to-end product design, UX research, Interaction design, Visual Design, System thinking
Partners:
PM, UXR, DS, Dev
Why is the Goals product important to Asana’s strategy?
Goals is a very important piece of the product for businesses to track OKR’s, especially in the enterprise category. As businesses scale, they need to have practical and efficient ways to track their OKR’s.
Why design this feature now?
In the macroeconomic conditions of H2 2022, the emphasis on winning upmarket and winning over large enterprise companies was paramount. There was a strategic shift to focusing on enterprise customers and their needs, and the Goals product was a huge part of that.
Enterprise customers rely heavily on OKR’s, and building a product with a strong OKR system is necessary to continue to build enterprise trust.
Customer feedback reports
For the beginning phase of discovery, I leaned in to VoC (voice of customer reports) in our database that had to do with customers who had given feedback around pain points of sharing Asana goals.
This led to early insights of understanding this was a big pain point as there many reports that this feature was missing. Users felt that the lack of export functionality as something that should be there because it appears in other parts of the product!
Learnings from related work
I also sought any other related work from people at Asana had completed. Things like an executive monitoring research study, as well as research from Asana Goals adoption.
I found a few relevant data points to define my point of view:
CEO’s of companies use Asana goals far less than managers
Lack of connectivity between Asana goals and other parts of the Asana product makes it cumbersome
Getting to know Asana Goals (and it’s quirks)
Goals is a super complex product with a web of hierarchies (lots of nesting of goals) — this gets more complicated with larger companies (company-wide, division-level, team-level, personal goals).
Goals can be linked as parent or sub-goals, to create a goal hierarchy, and supporting work can be added to make the connection between goals and work clear.
I decided to map out the possibilities of ways that goals can be nested in Asana so that I can get a clear understanding how an export would look like.
Leading a research study
I collaborated with Data Science to do a data pull of all customers who have used Goals at companies with at least 50-100 people and beyond.
I collaborated with UXR to recruit the participants which fell into two categories: Managers + Execs
I led 10 user interviews with the participants to understand how they shared Goals information and the pain points with said sharing.
Key insights
Users reported a high a mount of toil across the board — taking stuff from inside goals, manually inputting into a spreadsheet, manipulating the data, and then putting it into a presentation manually
How they solve for this today:
Someone takes a screenshot and adds it to a deck or document for the exec to view. Over time, this is very tedious and the data isn’t in real-time.
Users will share their screen and go through the Asana goals product directly.
Manually entering information from Google sheets into Goals
Most executives just don’t use Asana and have their direct reports or assistants prepare unique decks for them - this corroborates the research I did on the previous goals adoption research I originally looked at.
Executive leadership isn’t going into Asana - they get bogged down in the complexities of the goals product.
Defining my point of view
Asana Goals product
UX research
What did we want to find out?
1. How and to whom do users currently share goals info?
2. How would users like to share goals info?
3. What information would users like to include when sharing goals info?
Main user segment - Managers
This segment of users are ‘Asana masters’ of their company
They share externally to stakeholders who are not as tech-savy or utilize Asana
These users are typically involved with creating or managing OKR’s and progress
How do users share goals?
5 out of 7 managers input data from Asana to a deck because executives don’t use Asana
4 out of 7 managers use spreadsheets to customize/filter data before presenting to executives
90% of managers shared to higher level executives in quarterly or weekly meetings
“We are considering leaving Asana because of this current solution not working for us. If this [customizable export] came out tomorrow - we’d 100% stay at Asana.”
-Ethan
Users want to see goal name, sub-okrs/kr’s, blockers/status updates and owner of the goal on a shared goal presentation.
Users reported that the pain points were so intense around this, they considered leaving Asana.
An example of how quickly complicated the web of goals hierarchies can get.
Ideation
I showed the users of my research study 4 potential solutions that I sketched to see how they ranked how much it solved their pain points.
My thinking was that because adding an entire export functionality to the goals product would be a much more expensive and long process, an add-on integration could be an MVP that solves it (until we add export to the roadmap for goals).
An overwhelming amount of users (100% of them) said that a way to export directly to a Google slide deck would be the best option.
Explorations
Example of an exploration for a solution I showed users. Here we see export goals to a spreadsheet.
I started sketching to ideate how to design an add-on that would effectively export Asana goals to a Google slide deck.
I needed to decide how to design something that can export multiple goals, multiple teams, etc as the possibilities in Asana are complex.
Final designs
The final designs were the amalgamation of many meetings with several thought partners on the best way to ship an add on experience for Asana goals.
I met with data scientists to figure out how many goals and subgoals the average customer of a certain size has in order to determine what the output of the slides are
I also had recurring meetings with the integrations team to help me figure out the best way to design for an integration that exists outside of the product. Working in an engineering framework outside of the product was a unique challenge that affected how the design worked.
My PM and I worked together to make sure that the solution was ready and met regularly to discuss the complexities of the goals product and if this MVP would work within it.
The prototype for the integrated add-on experience.
Our users
Designing for an integration (constraints)
One learning point from this project was designing with the constraints of an add-on experience. I only had a small amount of space to design for given the size of the Google add-on windowpane. This led to tradeoffs in the design decision making like:
Trying to figure out how to display a time period - I wanted a date picker to be more clear, but due to the constraints of size I decided to use pills instead.
Figuring out how to utilize the space to be able to design all the forms that are necessary
The MVP for this goals sharing project is currently in the process of being shipped. Although it was not specifically on the product roadmap, the user problem is big enough that once implemented should add a little more enterprise trust (a huge roadmap item).
For the next steps, l’ll be collecting information on how much usage it is getting, pain points around the add-on and creating a user journey once there is metrics to reference.
I also will be reaching out to customers for qualitative feedback before building the next version that will hopefully be in the form of being embedded in the product.
Next steps
What did I learn?
This project was a lofty one that I was happy to tackle. One of the main things that I learned from this project is how to become a better systems thinker when designing solutions. The goals product was so complex, that I should’ve mapped out its functionality in more detail from the very first steps of the project. Although I did do that later, it helped me to realize the depth that some products have in their systems that needs to be identified.
Another learning was creating an out-of-product integration. This was a great opportunity for me to design something outside of our design system and using a different engineering framework. Learning how to work within those constraints took me out of my comfort zone and allowed me new design competencies I’ll bring to the next integrations related project!