Desire Paths in Retail Technology: A Death Knell for Intelligent Design

Desire paths are burrowing their way around your systems.

---

You Talkin’ Uh’Me?

You are a tech leader in a retail brand.

You are passionate about what you do. Motivated. Smart.

(I see you nodding as you read this — ‘Yes, I am pretty great aren’t I?’).

In half of your waking hours on this earth, you urge your corporeal self, logic, wisdom, and creative soul into your work.

Why?

To auteur beautifully designed systems, of course.

Palaces of productivity and light: guiding people towards their potential via honeyed panaceas for the mundane modern workplace experience.

Or, you just implement systems for a retail brand. Wherever you are on the scale of poetic description is fine by me.

Spreadsheet Insurgency

But at work, you’re seeing things that concern you.

The users of your systems aren’t meeting your gaze as they used to.

A suspicious number of spreadsheets are open when you walk through the office.

The sales report you’ve just been handed clearly wasn’t generated from the ERP.

The users are not following the workflows.

Conflict is resolved from a starting position of both sides agreeing the other has a point.

Desire paths are burrowing their way around your systems in ways you were blissfully unaware of, until now.

You are frustrated.

‘We designed this together?’

‘We sat through session after session agreeing how this would work.’

‘You said you needed it this way!’

‘Now it’s live and you’re just… freestyling?’

Fair points.

But conflict (even very minor, as in this case) is resolved from a starting position of both sides agreeing the other has a point.

So, what is the user perspective?

Why are the users trampling down the grass at the verges of your ERP (for example), instead of following your planned route?

When you observe desire paths, what opportunities are created?

Reasons, Examples, And Jungian Silliness

Potential reasons abound:

• The workflows are not optimal.

• The menu options could be more intuitive.

• Something might have been missed in the design. (It’s possible — that’s all I’m saying!).

• Users weren’t trained well enough.

• The system documentation doesn’t support the post-live phase.

• New people have joined since live and don’t know the right process yet.

• System labelling could be better.

• The system hasn’t evolved with changing needs.

Of course, there’s also a selection of reasons which nest under the ‘wrong operators in place’ category, but this article presumes you’ve got good people in the right seats.

“Tom, this is all quite abstract — what does a desire path even look like in the retail software context?”

Very specific question imaginary reader… And frankly, a bit wordy. Also, curiously timed given what’s coming next. I sincerely hope you’re not a narrative device posing as a legitimate reader/writer interaction?

Here are real-world examples from brand teams of desire paths in retail software.

1. Creating products directly in the eCommerce site rather than the product master system.

2. Manually adjusting stock levels in the eCommerce site.

3. Selling custom products on PoS transactions.

4. Producing reports and analytics in Excel/Google Sheets rather than inside the tech stack.

5. Bypassing automated replenishment workflows to order stock via email from suppliers.

6. Manually triggering iPaaS syncs instead of letting them run on schedule.

Can these instances create issues for you? Yes.

Tech teams inside brands scurrying around fixing the fallout of colleagues’ ‘off-roading’, as you well know, oh so clever reader, is a part of the job. But how big a part of the job is up to you.

So, let’s think about it a different way. When you observe desire paths, what opportunities are created?

Each one of those examples tells us something. Take the one below.

Producing reports and analytics in Excel/Google sheets rather than inside the tech stack.

This suggests that either:

🥉 The reporting capabilities inside the stack aren’t rich enough.

OR…

🧑‍🔬 They are, but the users aren’t yet skilled enough on the system to produce them.

OR…

🤔 Users are perfectly skilled at generating system reports but view doing that as less effective than exporting data for manipulation in spreadsheets.

Any of those creates an opportunity.

In fact, whichever example from the 6 above is chosen, all create an opportunity, to either:

1. Make systems better.

2. Make processes better.

3. Make documentation better.

4. Help someone who needs more training.

Viewing things this way, rather than as wanton destruction of your pristine palace, fosters growth for users, yourself, and the systems.

Ego does not a good software make. It’s like Carl Jung said…

“Through pride we are ever deceiving ourselves. But deep down below the surface of the average conscience, a still, small voice says to us, 'They’re not breaking process because they’re idiots, mate. It’s probably at least partly the system."

---

---

The Paths Not Seen

So there are the desire paths you can observe, and then there are the ones you can’t.

Perhaps someone on your team is too shy to admit a process isn’t working for them, or fears your reaction to their feedback.

They might be too busy to document what doesn’t work and why, feeling pressured to 'push ahead and make it work' to save time.

Or they don’t want to ‘get in trouble’.

Or, they don’t even know they aren’t following the process!

What to do about that category of scenarios — the paths not seen?

Unaddressed, these paths can make small issues big.

For example, point 6…

Manually triggering iPaaS syncs instead of letting them run on schedule.

Imagine that over some months, someone on your eComm team notices your integration not updating stock on certain products as it should.

Initially, the issue only affects a handful of items, so they quickly add the stock manually on Shopify and forget about it.

They repeat this a few times over the months, dismissing the issue as too minor to report: 'It’s just a couple of products; it’s quicker to fix manually’.

But that problem is about to become much bigger.

A certain product type (let’s say, footwear) is missing from your 3PL's stock files, preventing your integration from updating its stock on Shopify.

That’s a small issue now because you only have one or two ‘path-finder’ footwear products.

But tonight is the big launch of your marquee footwear product, a key strategic move to capitalise on the success of a pathfinder trainer.

And the eComm team member who had been quietly fixing the stock issue left the company last week.

It’s 6 pm, and a raft of new product listings were added to Shopify earlier in the day. They have beautiful images, carefully crafted descriptions optimised for SEO, tags. A lot of marketing spend went into this campaign. But… there’s no stock?

‘Why is there no stock!?’

‘The integration ran an hour ago — all the other products have stock? Why do the trainers have no stock??’

You call the integration provider but it’s outside of their working hours. They scramble a developer to look into it. The sale launches in 30 minutes.

20 minutes pass.

The developer looks into the file. The footwear SKUs just aren’t there. It’s a 3PL issue. Now you need to contact the 3PL. 10 minutes to go…

This kind of thing happens. I’ve seen it.

So, how can those issues be pre-empted?

Solutions

Happily, there are many ways to capitalise on the opportunities created by desire paths.

Some methods are technical, others involve process and system choices, some require strong soft skills. A few are quick to implement, others not. A mix of the options below may work best.

Here we go!

Feedback Systems

• Operate an internal support desk and make it easy for your colleagues to create tickets.

  • Effort level: Medium.

  • Process:

    • System users in the business raise a ticket if they:

      • Encounter a technical issue.

      • Use a workaround (i.e. create a desire path!).

      • Don’t know how something is supposed to be done.

  • Tips:

    • Keep ticket creation simple with minimal mandatory fields — users are more likely to act when it's easy.

      • The helpdesk will also support users raising tickets via email.

    • Set up a regular review process and follow-ups; people will stop raising tickets if they feel ignored or see no resolutions.

    • Plenty of helpdesks are available, but avoid Zendesk; its reply threading can make long interactions confusing.

    • Most support desks can prompt users to check relevant 'how-to' guides or knowledge-base articles.

• A shared document for logging system feedback. If a helpdesk is too much work.

  • Effort Level: Very Low.

  • Process:

    • Set up (something as simple as) a Google Sheet, or your organisation’s equivalent. Create columns for the data you want to be filled in.

    • Share it with key users you want to input.

    • Use a Loom video (or equivalent) or hold a meeting to explain what to do, why it matters, and gather feedback.

  • Tips:

    • Have your key users add the document to their bookmark bar to remind them to use it.

    • Better yet, if they’re willing, ask them to set the document as their new tab page (I use this Chrome extension).
      

• Surveys and feedback forms.

  • Effort Level: Very Low.

  • Process:

    • Easy — create form, list recipients, send form, gather feedback, decide actions.

  • Tips:

    • Keep the form simple to boost engagement. Save the detailed stuff for a follow-up after the fact. Asking for too much information in the form will decrease engagement.

    • Send the form out with the explicit message that it takes sub 1-min to complete!
      

• Regular, quick sessions with key users. (My favourite solution).

  • Effort Level: Low

  • Process:

    • The format is simple — “Re the systems you use, what’s good? What needs change?”.

    • Could be 15 minutes once a month to start with.

  • Tips:

    • Encourage users to note down ideas on what’s good/what needs change in between meetings.

      • There’s gold in them there hills…

Observation & Analysis

• Implement a technical screen monitoring solution, like HotJar.

  • Effort Level: Unknown.

  • Process:

    • Disclaimer: I haven’t used this tool before and understand it’s primarily for tracking website user behaviour. But, I’m curious about its potential for identifying friction points encountered by browser system users (e.g. Netsuite, Shopify, Airtable).

  • Tips:

    • Crucial — this absolutely has to be done with prior user consent. Don’t be a ***** and start spying on your teammates.
      

• Audit of ‘Shadow IT’.

  • Effort Level: Very High.

  • Process:

    • Lots of planning. Data collection. Analysis. Stakeholder updates. Reporting. Possibly different approaches for remote/office workers.

    • A quick search suggests there are tools which help do a more automated version of this (like Lansweeper and ZScaler) but I can’t speak to cost, setup or effectiveness.

  • Tips:

    • Be wary about this option. People sometimes see ‘audit’ and hear ‘witchhunt’. Plus, doing it thoroughly is weeks of work. If you decide it’s worth doing, go into it with your eyes open.

    • Unless you’re in an organisation which is too big to take a more personal, collaborative approach, this option isn’t preferred.

• Task-specific audit.

  • Effort Level: Medium-High. (Hard to define without knowing the tasks, but shouldn’t be unworkable).

  • Process:

    • There are lots of thorough guides on how to do this online — I’ll leave it to the pros.

  • Tips:

    • Remember, the goal isn’t to ‘correct’ or catch users out, but to learn things which create opportunities to improve the tech setup.

• Shadow key users.

  • Effort Level: Medium–High.

  • Process:

    • List ideal key users for different systems.

    • Schedule appropriate slots to sit with them, and learn by watching how they use the system and asking questions.

  • Tips:

    • Make it ‘light touch’ (short periods with each key user and not too frequent) and informal.

    • Don’t try and implement this with remote workers! In-office businesses only.
      

Culture Change

• Culture setting around giving constructive feedback.

  • Effort Level: Medium-High (but worth it).

  • Process:

    • Get the message out that feedback is welcomed.

    • Include in that message how you want to get feedback, and the type of feedback you are looking for.

    • Lower the barrier to giving feedback (and keep lowering it). A simple form, or a simple format. Don’t ask too much! If possible, ask so little that not giving feedback seems almost rude.

    • Reward givers of feedback.

    • Let users give feedback anonymously if they’d prefer.

    • Show vulnerability — acknowledge your mistakes. Users are more likely to suggest improvements if they see you're open to feedback and learning.

    • Actually implement the good ideas… Starting with quick wins to build a sense of ‘this feedback actually makes positive change’.

    • Get feedback into your culture from top down. It’s powerful when leaders openly seek feedback. Nobody is above improvement — show that.

    • Sell the value of the feedback back to everyone. Show where feedback was given, received, appreciated, acted upon, and led to measurable improvements.

• Tips:

  • This is where your soft skills need to kick in. Show gratitude in getting the feedback (which is best done by actually being grateful…). Give off positive energy in all of your messaging around this initiative.

  • Keep repeating the above steps and use your charm (!) to mean that doesn’t get annoying.

    • Get the way you want people to deliver feedback, the type of feedback you want, and the value of having the feedback so deeply ingrained in the organisation that it’s an unconscious part of the environment. That’s done through repetition, which doesn’t have to be boring.
      

Species Survival

We as systems people can be prone to being Intelligent Design evangelists.

We know what our users need. We create it. They thrive.

But, in reality, it comes down to this.

There’s how you plan for systems to be used, and then there’s how they are actually used.

Systems thrive by evolution just like we do. Desire paths might well point you towards the gene pool being selected.