So, what does "High Priority" really mean?
A requirement has come through that a job must be able to be marked as "High Priority". Simple enough? Well, as in all things UX, the answer is yes... and no.
The reason I started asking what it really meant was that I'd seen users game the current system's definitions and implementation of a "High Priority" setting. Their "High Priority" had a business rule that meant that a warning flag was sent to a senior manager if a task was not completed within X days of it being started. The task included a number of information gathering and data entry tasks that very often could take more than X days since there were sometimes a lot of dependencies (including other tasks that had the same time limit!).
Their solution was to do the entire job manually outside of the system that was built to manage the collection of the data. The data set was collected in a word processor document and only then did they start the data entry task inside the system by copy and pasting the results from their information gathering, and finally save the results in the previously time-limited application.
All on the same day.
OK, so the job got done, you say. But the reporting and time management data that could have been gathered at the same time was totally useless. There was no way of knowing how long each different task took, so efficiency reports were useless. And the data was captured outside the system, so managers have no idea at any specific date or time the state of each task with their individual workers, or within the team as a whole.
In the end, the "High Priority" setting was no solution, and added risks to the system that should not be acceptable.
So, how do you fix this to help all users?
You must go back to the original idea that prompted the concept of a "High Priority" setting as the solution.
Again I ask, what does "High Priority" really mean?
High priory really in this case means "I want this done quickly". But high priority as implemented in the example above meant “get this done within the time-limit or you’ll be reported to senior management”.
The aim is 'fast work throughput', but the solution is ‘cover your arse’.
The point is there should never be a need for that non-perform flag to be sent to the senior manager. The workflow and operating procedures should have the potential for manageable escalation built in.
The problem can be broken down into a number of points:
- The business rule is linear and too rigid.
- The rule is often unachievable as the same rule can apply to individual sub-sets of the measured task.
- A consequence of the rigid rule creates inaccurate metrics...
- …so analysis is based on inaccurate data.
- There is no gradual escalation of the issue; just a big stick,
- Users that run out of time do not normally just work faster, they cut corners or find a way of conforming to a rule that is outside the original intent of that rule (as in the case above).
- The flag is being used by the manager, not the team.
So from a usability point of view, how do we solve all of those issues?
Let's look at that list and reverse it.
The last point, point 7, is in my list is actually the starting point for a better way to design the system. The team should always be the driver, not the manager. The users must be given visibility of that flag and provided with up to date information on how to beat the flag rule without going outside that rule’s intent.
In point 6 we see that although the rule's intent was to push high priority tasks through the system first, the result of gaming the rule meant that the high priority flag had an unintended - and potentially dangerous - outcome. Tasks escaped the 'system' and was not visible while outside that system.
Point 5 shows that there is an heavy imbalance between the managers of the system and the people actually doing the work. Rigid rules and big sticks only tell your workers that you don't trust them to complete a task successfully; a task they have been hired to do after going through an interview process to allow a manager to pick the best person for the job. If you, as manager hired them, why don't you trust your own judgement in them? End even if you didn't do the direct hire yourself, isn't part of a manager's job to make sure their team has been trained to do their job?
Now, points 3 and 4 are linked: inaccurate metrics creates inaccurate data. Inaccurate data means that decisions are ill-informed.
Point 2 really means look at the whole system. Creating arbitrary rules made without looking at the holistic consequences of that rule is just plain bad management. And leaving that rule in place over several years brings us to the initial point.
For in point 1 rules need to be degradable. In programming every decision has options - the 'if' statement is there for a reason - it allows a programmer to look at what happens next if an event occurs. It defines options. It must include, within reason, get-out or postponement clauses that allow staff to do their work in a flexible - but still legal - manner. By all means you still need a red flag event, but that is the LAST step, not the ONLY step.
In the case above only one rule was made. Make this task high priority. The intent was to speed up work for high priority cases. The result was to put a major flaw in the system. That is NOT why we make a task high priority.
