We can’t automate everything. But we can come close.

Often when we start a new project that involves applications or flows there is a baseline assumption that technology should handle everything–the user shouldn’t have to be bothered. As we diagram flows and sketch interfaces, there is a nagging thrust to push every bit possible off on the technology. Many times this is a good idea. I shouldn’t insist a user learn the format I use for dates and properly map it to the day they have in mind, or click repeatedly through a calendar to find their day. Technology is more than capable of parsing a date in almost any format the user prefers and converting it to the format I need. I put the onus on technology to automate the date formatting task.

But what about a more complex task? Or something that involves interpretation, reasoning, balancing alternatives and subjective thought? Where is the line–or is it even as clearly defined as a line?

There is a continuum from users doing the work (manual) to technology doing the work (automated). Historically, all processes start on the far left of the continuum as a manual activity. Automation is introduced when the manual process becomes tedious, repetitious, overwhelming or burdensome. The intention of automation is to make a process more efficient. Automation doesn’t inherently make processes more efficient, though.

How do you know when to automate?

Variability: how much repetition is involved?

Automation favors tasks that are repeatable. The more variability a task involves, the harder it will be to automate. Tasks with a limited amount of variability (<25% of instances involve an exception to the rule) may benefit from a partially automated interface that allows for adjustment at the user’s request. Tasks with no variability are excellent candidates for automation. Tasks with high variability (>25% of instances involve an exception) should probably be left to the user.

Volume: how many people do this thing?

The more people performing a task, the greater the benefit from automating that task. If a relative few have to perform the task, carefully consider whether the effort of creating a technological solution is going to be less than continuing with a manual process.

Effort: how much time does this thing take?

Tasks that consume a lot of time are good candidates for automation. Time is relative, though, as it can be compounded by volume. In a task with high volume, a few seconds may be a long time. In a task with low volume, it may take minutes, hours or days to have the same impact.

Bottlenecks: are current executors a bottle neck?

Generally, a task considered for automation is part of a larger process. If the task in question is the bottleneck–the step that slows down the whole process–it is a good candidate for automation. The effort of automating a task that isn’t a bottleneck may not be worth it.

Susceptibility: is an error more likely by lots of humans, or a few algorithm authors?

A manual process relies on each individual user to execute correctly. A technological solution doesn’t remove that susceptibility to error, it just transfers it to a small team of algorithm authors. Both groups are susceptible to making errors. When individual users make an error, it only impacts their instance of the process. If algorithm authors make an error, though, it impacts every instance of the process. Generally, a team implementing a technological solution will exhibit more care than a standard user, but it is still important to consider which group is more likely to fail in your task.

Critical: what are the ramifications of an error?

The potential consequences of an error go hand-in-hand with susceptibility. In the date picker example above, the ramifications are very minor. In other tasks, errors could result in much larger issues. If a task is critical, it makes consideration of susceptibility that much more important. If a task is not critical, the automation versus manual decision has much less impact.

In most cases, there is not a yes-or-no answer for whether to automate. The answer lies somewhere along the continuum from user to technological responsibility. Tend toward automation for that which is repeatable and known. Keep users involved when there is high decision-making variability or a degree of algorithmic complexity that would be cost-prohibitive to get right. Most situations will land between the endpoints: some components will be automated while others are manual. The trick is to find the ideal placement for your application along the continuum.