The power of Digital desire paths and Shadow IT

Why do IT users ignore or circumvent the rules and instead carve their own Digital desire paths?

Should we block all instances of Shadow IT?

Could we instead see it as an opportunity to help us better understand our users?

What is a desire path?

Wikipedia defines a Desire path as:

“A path created as a consequence of erosion caused by human or animal foot-fall or traffic. The path usually represents the shortest or most easily navigated route between an origin and destination. Width and erosion severity can be indicators of how much traffic a path receives. Desire paths emerge as shortcuts where constructed ways take a circuitous route, have gaps, or are non-existent.”

So, what is a digital desire path?

When users ignore the official processes and workflows used to provide software or hardware. Or where they use digital systems in unapproved ways.

This might include bypassing the approval process to get hardware or software.

It might also include running a project without visibility or involvement from IT to deliver a solution.

What are the reasons they form?

Such unstructured routes can develop for all kinds of reasons:

Some present obvious shortcuts .
Some offer easier routes.
Some offer users more choice.
Some address regional or cultural differences.
Some bypass alarms, security measures, or other impedances.

How can we learn from digital desire paths?

Enough of my rambling. Here are some pictures. Enjoy these visual metaphors.

Over-engineered solutions can lose sight of the primary aim of the user. They may end up being ignored entirely and are usually a costly investment.

If users are cutting a corner. That might highlight that the existing path isn’t the most efficient.

If we use an arbitrary restriction that inconveniences users and that can be be bypassed. It will be. We also need to make sure we don’t rely on a templated approach because it worked somewhere else.

When we block an existing desire path without providing an alternative. Might we be provoking the users to forge a new one?

Failing to anticipate user needs will often result in a desire path forming.

Sometimes we should admit the users are right. Integrating their path into the official solution.

After fresh snow, planners can learn a lot about the paths users might naturally chose. The same can be true when we provide new solutions and allow users to define what best-practice looks like to them.

What is Shadow IT?

Wikipedia defines Shadow IT as follows:

“Information-technology systems and solutions built and used inside organizations without explicit organizational approval. People also use it—along with Stealth IT and Client IT—to mean solutions specified and deployed by departments other than the IT department.”

Or in other words, any IT used in the organisaiton that didn’t come through official IT channels.

Who is Shadow IT?

Probably you. Actually, almost certainly you…

Rules exist for a reason. No one is exempt. Illustration by Rory Walker (roryroryrory.com)

Most of us are likely guilty of it in some way:

If you install extra software that’s not on the official list … that’s shadow IT.
If your team purchased a cloud based application without consulting IT … that’s Shadow IT.
If you’ve ordered a peripheral from Amazon rather than through the IT service desk … that’s Shadow IT.

Why does IT have rules?

The rules of IT exist for good reason:

To save us money.
To protect our security.
To improve consistency and reliability.
To help us work more effectively.

That, at least, is their aim…

So, why do we get Shadow IT?

Even people in IT are human. Sometimes when applying the rules we lose sight of the user. Sometimes we forget one of our objectives.

If we emphasise any of the reasons above the others we can negatively impact the others:

In trying to formalise rules to be more consistent we can make our processes overly complicated and inefficient.
In trying to save money we can end up providing an inferior product that users don’t like.
In trying to be ultra-secure we can over-restrict available options.

The result can be a time consuming process. One that takes too many steps and causes users to seek an easier path. A path to solutions they’d pick – rather than the ones prescribed to them.

Analogue blindness

People are analogue. IT isn’t traditionally. That’s because systems and processes are digital.

We have a tendency to be analogue blind. We ignore what we can’t easily measure. Namely, user needs and preferences.

Analogue blindness. Illustration by Rory Walker (roryroryrory.com)

We rely too heavily on technical specifications. More on how to avoid that specific pitfall can be found in this article on Outcome-driven specifications.

Start with the WHY

Make sure your requirements stem from your users. Not the other way around.

If you help them to define the problem then you can more readily provide an effective solution.

You should look beyond the immediate request to find the root cause. The role of IT is to facilitate, not simply to provide.

Starting with the technology and then looking for opportunities to use it is also rarely an effective strategy.

Education, education, education

People who don’t understand the rules are more likely to break them.

Make decisions transparent. Update users on progress. There is no need to hide the inner workings of the process from them.

Empower them with understanding. They can then provide you with a strong business case. Making it much easier for you to say yes.

Accept we can always do better

IT professionals can get treated as authorities in a wide range of fields. But we aren’t infallible.

Knowing how to create an app or design a solution doesn’t mean we instinctively understand the requirements of a user. Especially in a function we’ve never worked in.

You know what they say about assumptions…

To get around this we need to engage deeply and sincerely with the communities we are expected to help. To ensure we address actual needs rather than indiscriminately “disrupting” the way their established systems work.

We should confirm our assumptions and understanding in a real-world setting.

Harnessing the power of Shadow IT

Maybe it’s time we take a look at the rules and the processes that surround them?
Maybe it’s time we put more effort into understanding why users ignore them?
Maybe if we let users, they might demonstrate needs to us that we were unaware of?
Maybe some of our users are actually at the leading edge of IT and can show us tech and best practice opportunities we’d otherwise never see?
Maybe Shadow IT has a use after all?