If I tell you drinking coffee is "priority one" for me; I am reasonably sure you will assume that is it very important for me to drink coffee. But is it logical to think of a low number as a high priority; or is it simply a cultural bias?

The question occurred while considering a system that requires tasks where fine grained control is needed when adding new tasks. Here we express priority as a number, and things are not so "intuitive" anymore. When you say 'a higher number has a lower priority'; it sounds like an inverted way of thinking.

I would have liked to stick to some standard. But unable to find such a thing I looked around for examples. Thus, I came across MS-Project. Their choice seems to be more logical (albeit less "intuitive" to me): a higher number has a higher priority.

It is easy for me to imagine my tasking system will one day exchange tasks with MS-Project; so I am leaning towards picking the MS-Project way. And thus, adopting their's as a de facto standard.

I also have internationalization needs (like many of us). Am I making the right choice?

  • 1
    I have used several computer systems where priority increased with increasing number. The old Xerox Sigma 7 OS, IIRC, had priorities 0-7 with 7 being the most urgent. – Hot Licks Feb 11 '15 at 18:28
  • 1
    There is not a standard. If I saw a 1-4 I might be inclined to think 1 is high. But if I saw a 1-10 I would be more inclined to think 10 was high. What ever you decide you need to make is clear in the UI and documentation and be consistent. Even something like history - is 1 the last one you did or the first one? – paparazzo Feb 11 '15 at 19:59
  • 2
    Just a side note - all UNIX-based OS's use lower numbers to indicate higher priority for processes. Indeed, one can even get negative priorities. This is confusing, but just another widely-used benchmark. See nice(1) – felixphew Feb 11 '15 at 20:04
  • After all the great answers, I now feel obliged to share my more informed opinion: I feel that the meaning you tie to the smaller number is driven by the domain of your end-users. Researching and finding examples are very helpful if you want to form an opinion about how your users will think about these numbers. (i.e. a unix job scheduling application vs. an app that exchanges info with MS Project). That said; it should be noted that the user experience is much better when you do not use a number -- thus making the answer to this question not relevant. – Willem Feb 14 '15 at 6:54

There seems to be no set universal standard, only standards within different regimes picking a standard of increasing or decreasing priority. That said, a lower number being the highest priority appears to be more common. For example, Listing priority number, within the United States Fish and Wildlife Service uses a lower number to denote a higher priority.

Risk Priority Numbers use a higher number to denote higher risk.

The RPN is not a measure of risk, but of risk priority . You would apply your limited resources to the most important problems. The RPN gives you a model to allocate these resources. Higher numbers are higher priority, so you should work on an RPN of 900, before you put resources on an RPN of 30.

A good study of increasing priority numbers is Solving Queueing Systems with Increasing Priority Numbers J.-C. Panayiotopoulos The Journal of the Operational Research Society Vol. 31, No. 7 (Jul., 1980), pp. 637-646

Basically, when it comes down to it, there is no right or wrong answer. The choice is up to you - just ensure that you make it clear if you are using higher or lower numbers to denote higher priority.

One thing to note is that if you use the lower number being the highest priority, then you set an absolute limit, or ceiling, to the priority. If a new event/item comes along which over rules all prior events/items in the list, including those already at priority one then what do you do. Demote all events/items in the list? An ugly solution. So, it could be better to use a higher number denoting a higher priority. That way the list can always accommodate a new super high priority. That said, then very lower priority events/items may all end up getting bunched in the priority one category together, when some obviously will still have an intrinsically higher priority than others also at priority one. However, this is less of an issue, as they are all low priority and can be reprioritised at a later date.

  • Technically, if the software is built to recognize integers (as it should be) as valid priority values, there is no upper or lower limit as negative values would be perfectly fine. – dnbrv Feb 11 '15 at 16:11
  • 3
    Technically, I agree - but a negative priority looks odd, and using a negative priority to denote higher priority would seem a bit wrong, in a lower-number-high-priority system. – Greenonline Feb 11 '15 at 16:18
  • Oh, yeah, my bad. – dnbrv Feb 11 '15 at 16:24
  • 1
    Marked this as correct because it expanded my view. However I do not thereby suggest that the other answers are incorrect. – Willem Feb 14 '15 at 6:57

I would answer your question with a big YES!

Let me back that up by showing you what the DEFCON alert state does, since that's about as important as it gets when it comes to priority.

From Wikipedia:

The defense readiness condition (DEFCON) is an alert state used by the United States Armed Forces. The DEFCON system was developed by the Joint Chiefs of Staff (JCS) and unified and specified combatant commands. It prescribes five graduated levels of readiness (or states of alert) for the U.S. military, and increase in severity from DEFCON 5 (least severe) to DEFCON 1 (most severe) to match varying military situations.

* Emphasis is mine



Here are the 5 levels of DEFCON :

level colors

DEFCONs vary between many commands and have changed over time, and the United States Department of Defense uses exercise terms when referring to the DEFCONs. This is to preclude the possibility of confusing exercise commands with actual operational commands. On 12 January 1966, NORAD "proposed the adoption of the readiness conditions of the JCS system", and information about the levels was declassified in 2006:

levels table
Click to view table in its full size

  • Nice example. Thanks for bringing it to my attention. – Willem Feb 11 '15 at 16:03
  • 2
    Maverick having a DEFCON example somehow seems poetic. – Evil Closet Monkey Feb 11 '15 at 17:42
  • @EvilClosetMonkey - Doesn't it though? LoL! My mind immediately went there =D – Code Maverick Feb 11 '15 at 17:44

Priority 1 / Top Priority / First

The number 1 has the unique feature of being the closest whole number to zero.

Rating how important or critical something is should always put 1 first otherwise with only a single priority 8 item I'll have no way to know where it falls on the entire list of priorities.

If 1 doesn't represent the most important priority then there would be no zero reference point and no context to judge any other priority number. Would it be 5, 10, 100, 2 ?

Since I recently built a product measuring both Risk Level and Productivity Rating each with 5 number values on the backend I'll show you what tested well with our users (we chose not to expose the numbers at all in the UI)


  • 1
    Good points. Rating is not really my problem; but having absolute ceiling [top and bottom] is important. The idea of having 1 on top also creates a 'natural' feeling when applied to an 'order-by' column. – Willem Feb 11 '15 at 15:57
  • 1
    The closest whole number to zero is zero, technically. – Paŭlo Ebermann Feb 11 '15 at 19:09

Just like anything else, you have to validate this with your users. If they are project managers and the convention in PM software is to use numbers where greater number equals to higher priority, then stick to that and don't fix what's broken. If they are used to verbal representation (e.g., e-mail flags of High/Low priority), then you'll have to use that.

Alternatively, you can relieve your users of the mentally taxing task of assigning values to indicate priority and instead implement a drag'n'drop interface in the list of tasks where the top tasks will have a higher priority and the value is assigned automatically in the background. Asana does this extremely well.

  • Yes, considering the users as always best; I need to think whether I would classify my application is "PM Software" or not. I have considered your alternative suggestion. Unfortunately those that create tasks do not have access to the lists of those that perform the tasks; so producing such an interface is not feasible. Consequently the priority is more like a policy (i.e. not a relative value). – Willem Feb 11 '15 at 15:53
  • @Willem: If users who create tasks are not the same as the users who assign priority, then making it easy for those who assign priority is especially important. Also, it's not clear to me what you mean by "policy". Are you saying that your users don't need 1,000 levels of priority as MS Project offers? – dnbrv Feb 11 '15 at 16:06
  • Those creating tasks do set the priority, but they do not always know how the change in priority will affect the workload of the assignee. Yes, it is true. 1000 levels are a bit much. users would typically decide on broad levels (i.e. ranges within the numbers). However having more levels do allow them to tweak things when the need arises. – Willem Feb 11 '15 at 16:14
  • Let's focus on the strategy of task assignment. The manager cares that more critical tasks (closer deadline, more dependencies, more resource drain, etc.) get done ASAP. The worker cares to know what the manager needs and that it's displayed prominently. None of them cares about the actual priority value. This means that, in complex projects, priority should be calculated using a formula &, in simple projects, the task list should be sorted with drag'n'drop to float priorities to the top. – dnbrv Feb 11 '15 at 16:41
  • DnD would get rid of the concept of the priority. But sometimes it is needed. If manager A and manager B each place a new task for W. On manager A's list the task is on top and on manager B's list his new task is on top. The managers do not have access to W's list (i.e. they cannot see each other's tasks). A priority is needed to determine the order in which W processes the tasks. A policy is an agreement between A and B on how to assign priorities so that W will work on the most important stuff first. Automating policies is not always feasible. – Willem Feb 11 '15 at 17:03

Higher-number-higher-priority is better because is natural. It's something you can logically agree without investigating elsewhere.

Why? Because the other is odd, excpecially in certain circumstances.

@Greenonline, the person whose the answer was accepted, says: "but a negative priority looks odd, and using a negative priority to denote higher priority would seem a bit wrong, in a lower-number-high-priority system". In higher-number-higher-priority context, negatives are things you don't mind about, not so much, naturally.

(If everyone in the world does it wrong it's not enough for me to do the same way.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.