Forced Dependency field = bad UX

99% of all tasks created don’t need a dependency. This is based on 6 years of Asana use and experience from 10 organizations we work with.

Since 20 November we now have an additional field showing on all tasks. It’s a distraction and adds even more scroll for all users on all tasks through Asana.

Screenshot 2020-11-24 at 16.15.43

I would love to see the source for this UX decision. What makes that feature reprioritization worth lowering the experience for 99% of all use cases? What am I missing?

Hi @JFrentz,

This is an A/B test, so there is a chance it won’t launch in the future. I do understand this isn’t useful and may represent a distraction if you’re not using dependencies, but dependencies are becoming more and more popular, hence why we’re bringing bringing them up!

I’ll make sure to escalate your feedback to our Product Team, thank you so much for sharing it with us!

1 Like

Thanks for the :tophat::unicorn: service, @Marie! :person_in_lotus_position::heart:

The minimalistic design approach that we fell in love with and expect from Asana long-term is at risk with these decisions to force features upon users like this.

I feel like we lack some organization, team, or project setting to define how the task layout should be presented as standard. Why not treat it as a custom field, with a customisation option to show dependency as standard or not?

Related unexpected design decision
This is related to the same unexpected design decision to show all custom fields from the parent on subtasks as standard that you forced upon us this summer. On a desktop, they are hidden as standard(ok), but not on mobile. Our members primarily working from mobile now need to scroll past 20 unused(blank) custom fields on the majority of their task.

The minimalistic, clean experience is gone.

It’s bad UX to force these additional fields upon all users instead of user customisation options to maintain the minimalistic design approach and open layout options for those who need it in specific cases.


I would use Asana dependencies a lot more if they were more useable. But right now, the features are just too limited. For 1 simple example, the only defined dependency possible from Task A to Task B is to have Task A Finish trigger Task B Start, with no possibility to set a fixed delay. For those of us used to MS Project with FF, FS, SF, and SS, each with the possibility of defining any delay, including a negative number of days, the Asana approach to dependencies is about 90% underpowered.

To force the choice of such a low-value dependency feature on all users for every task isn’t right.


I like them. But as with most things, I think the most sensible thing to do is to allow the user to either turn them on or off visually in the UI.


I struggle to use Asana because almost every one of our tasks has dependencies and there is no ability to enter a duration. They really need a more robust dependency feature. I do agree that users should be able to determine what to see.


Hi @Debbie_Smith and welcome to the forum!

FYI just wanted to make sure you were aware of my Flowsana integration - one of its types of workflows, the Dynamic Duration workflow, allows you to have dependent tasks with durations and Flowsana will automatically set and maintain start/due dates based on that info.

1 Like