How Product Designers at Asana use Asana (featuring Boards!)

This is the second post in our “how Asana uses Asana” series! Our first post describes how Asana’s Marketing Team uses Asana.

About Asana’s Product Designers

Want to get a bit of background on our product design team before we jump into their projects? Check out this great blog post!

How Product Designers at Asana use Asana (featuring Boards!)

In this post we’ll tell you one of the ways that product designers at Asana use Asana. Product designers at Asana work in what we call Design Sprints. Our product design team will often use Boards to plan our their design sprints.

Example Boards project: Unicorn Design Sprints (created for the purposes of this demo)

Purpose of the project: manage the Unicorn product launch (an imaginary launch for the purposes of this demo)

How the project is organized: This is a collaborative project between product designers, PMs, and engineers. The PM leading the Unicorn launch will manage the project, conduct sprint planning, and assign out tasks. The PM will collaborate with designers and engineers to assign out tasks based on each person’s bandwidth and the overall project timeline.

Columns: In this example project you can see columns for Backlog, Ready, In Progress, Done, Needs More Info, Meeting Notes / Feedback, and References.
Backlog: questions that still need to be answered, tasks that still need to be completed but aren’t quite ready yet.

  • Ready: questions we’re ready to answer, that we want to prioritize for the upcoming sprint
  • In progress: tasks that we’re working on right now
  • Done: completed work
  • Needs more info: outstanding questions that we want to keep in mind and/or answer for a future sprint or in the long term
  • Meeting notes: notes in every meeting related to this project
  • References: links to related projects, login information for relevant tools, background info to keep in mind

Custom fields: Custom fields customize the project experience to the individual team. You can see custom fields for engineers and product designers. The designers use custom fields to identify where they are in the design process. Designer drop down custom fields are: backlogged, open questions, design in progress, design ready, eng ready, revisiting designs, and de-scoped.

The Project and Design Custom Fields




How do you plan design sprints in Asana? Do you think this process would be helpful for you? Do you have any other processes to recommend? We’d love to hear from you!

2 Likes

HI @Alexis, Thank you for this helpful post! Quick question: What’s the difference between the columns Backlog and Need More Info? Thank you!

Hi @Brett1! Glad this post is helpful for you. In this case the backlog contains things that we’ve decided to hold off on for now, whereas needs more info contains things that need more info before we can prioritize them (ex. can’t decide what to do until we get results from a research project).

I feel really bad but somehow I missed this post AND the marketing team one and those are both so relevant to my area I’m mad!

Anyway, I LOVE LOVE LOVE this look at the teams. My question is then - do yall have it set up so one task is reassigned multiple times? For example the ‘design ready’ ‘eng ready’, let’s say something is design ready, is it reassigned for someone to review, or is a subtask made for reviewing it? And then once it’s reviewed, does it get reassigned to the same person to make it ‘eng ready’ (whatever that may mean), then perhaps assigned to an engineer?

I find it particularly interesting that neither the design dropdowns nor the board have any kind of ‘in review’ notation. What’s the review philosophy like then, or process even?

It’s a bit trippy to me because our fields (used mostly in design/video) are things like in progress, ready (but this one means ‘its ready for review’), reviewing, complete (totally approved), needs update, and blocked (for more information). So seeing the ‘ready’ at the beginning is super trippy but for the concept of product design and sprints/kanban I understand.

If the backlog is considered unanswered questions or ‘tasks that still need to be completed but arent quite ready’ - for the latter you mean a task that is perhaps still waiting on another team to complete prerequisites, or not all the requirements are gathered, etc.? Just curious. We don’t use that method, but I’m always interested in different thoughts on it.

I would also be interested in seeing how the custom fields mix with the board section titles since there is some overlap, and how you use them in say reporting or PM capacities.

Like, is it open to anyone to do a search for ‘open questions’ fields and just lend their thoughts/ Kind of curious!

Thanks so much for this, I’d love to hear more!

Hi @Caisha! So glad you are enjoying this look at how Asana teams use Asana! I’ll address some of your follow up questions.

Yes, changing the task assignee is a common practice for some if they have a multi stage process. It depends on the person, I think. Some prefer reassigning one task, some prefer creating a sequence of tasks, or creating subtasks.

Good catch about a “renew” step. Honestly, I’m not 100% sure but I bet review subtasks and reassigning are part of the approval process here.

The backlog - not quite ready could mean too early in our company’s timeline for example or yes, to your point another team might need to complete X first.

Could you elaborate on this question…?

I’m happy to help clarify further!

For the open questions, I mean like - could anyone search for tasks with that field label and answer? or is it for mostly PMs to identify which tasks still need them?

So say I’m a developer but I see a task labeled open questions, and I can answer that question (like maybe the open question is ‘can X be add to Y’ or whatever), would I comment on the task with the answer, or would it be the PMs responsibility to gather the remaining answers?

It’s interesting that a convention like reassigning vs subtasks isn’t defined at all, now I’m curious about reporting metrics. To me, whether tasks get reassigned depend on the information in them, and the reporting (ie, in our department the head wants to track task efficiency by assignee so reassigning wouldn’t work really).

Anyway, cool insight, I just find myself wanting to dive deeper now =)

Ah yes. The PMs would be responsible for gathering the remaining answers.

The task reassignment all depends on the team, so I’d say that in situations like these the convention would be stated clearly. In this demo project there’s flexibility for viewers to imagine themselves in the same scenario and think of the different conventions that might work for them. However, yes, clearly stating conventions is super important to an effective project! You’re so right. I also like your point about reporting metrics. If understanding the phases of a project is important to a PM, you’re totally on point that knowing which task is completed when would be super important, and thus a new task (rather than a reassignment) would be most appropriate…and now I’m just reiterating what you already said :relaxed:

Let me know if there’s anything else I can do for you!

1 Like