👻 Medium and Low priorities are usually an illusion

Bear with me. The default priority custom field in Asana contains High-Medium-Low.

Apart from the fact that they should not have colored them all (but only color High), I believe having a Medium and Low priorities adds complexity where things used to be simple.

Something is usually either urgent, or is not. It is a high priority or a normal one. And, for the sake of clarity, when something has a default value, use an empty value! Your Asana project will be clearer, with less words and colors, and the actual high priorities will pop on the screen.

My revised version of the priority field? A single value « High » in red. Nothing else.

11 Likes

I agree, and would go even further:

  • Avoid use of a Priority custom field (as found in many Asana-provided project templates, unfortunately); it’s often not really meaningful and extra work to set such a value for every single task. (Sometimes projects can be set up to allow the tasks to appear in rough priority order.)
  • Instead, consider an “Urgent?” custom field with a default value of blank and a single other option of either :fire:or “Urgent” in red. (Often with similar on/off custom fields I use the lighter-weight value of just :heavy_check_mark: but in this case it likely helps to see the word “Urgent”.)
  • Since priority is now reduced to just a single value, Basic (free) Asana accounts could use a tag instead of custom field, and this may even be desirable for paid accounts too because it’s even more lightweight–no devoted column required. That tag value could either be “Urgent” or simply :fire:.

Hope those ideas help some,

Larry

PS I can’t believe I had to encourage @Bastien_Siebman to use an emoji❗

4 Likes

Hey @Bastien_Siebman !

That actually makes total sense. I will update some projects havind that in mind. Thanks!

1 Like

Sorry to disappoint Larry but I do have the emoji already :slight_smile:
Capture d’écran 2021-01-21 à 22.30.38

2 Likes

It depend on where you are using them. In a project / product back log these are create for understanding customer prioritise as a starting point. You then only promote the high priority ones.

1 Like

Disagree completely.

Often when scoping out work it is necessary to set the level of want for an item. This helps determine it’s priority in sprints as well as descoping if time/budget constraints come in or additional scope is requested.

If any of the above I can easily provide as list of low priority items to be descoped or moved to a different version.

I can also prioritize resources based on what has been identified higher priority. It may have impact on other projects but isn’t urgent. It may be a nice to have but should never be coded above other work.

So many different reasons to set priority on tasks. Nothing is ever black and white or Urgent or Not.

1 Like

@Getz_Pro I agree several levels are sometimes needed or interesting, but in many cases that brings more complexity and manual work to manage :slight_smile:

To your work perhaps. But not to most work.

For your use case why bother at all with a priority level? Just put urgent tasks at the top with the expected due date. Urgent means now or this week. No need to also call it out via a field.

There is zero manual work with Rules.

Also, having the levels allows for a lesser scoped item to move up to a higher priority if budget suddenly allows or use case changes. Then you can rule a chain reaction accordantly.

Agree that any of this denotation for the ‘doers’ is pointless, but for the ‘planners’ it is vital.