What DEX Cannot Fix

Experience measurement finds and sizes friction. Several adjacent problems look like they belong here and do not.

The recommendations in “What DEX Cannot Fix” need visible ownership, review time and a way to show whether the change reduced effort for the affected group. An organisation can use time management software to coordinate that implementation work and compare workloads, without treating hours or activity as a complete measure of digital employee experience.

For an independent benchmark, compare this approach with Nielsen Norman Group; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

A role that is badly designed

If somebody's job requires twelve systems because the role spans four functions, no amount of endpoint optimisation helps.

That is a job design question and it sits with whoever designed the job.

A process that should not exist

The programme can measure that an approval takes four days.

It cannot decide whether the approval is necessary, which requires somebody with authority over the risk the approval addresses.

Measurement makes the case; it does not make the decision.

Underinvestment in hardware

A four-year refresh cycle produces four-year-old machines, and the telemetry will say so every month.

Reporting it repeatedly does not change the capital plan.

What changes it is the cost comparison — support cost and time lost against replacement cost — made once, properly, to whoever owns the budget.

Low engagement

Technology friction affects how work feels and is one input among many.

A programme that fixes logins will not move an engagement score, and accepting that as a target is how it gets judged a failure.

A service desk that is underfunded

Slow resolution with high volume is a capacity problem.

Measurement will demonstrate it and the remedy is money or scope, neither of which is in the programme's gift.

Shadow IT

People adopt unapproved tools because the approved ones do not work for them.

The programme can find it and explain why it happened.

Fixing it means either making the approved route work or accepting the tool, and both are decisions elsewhere.

Anything about an individual

Covered in its own note and worth repeating: the data describes equipment and circumstances.

Using it to describe a person is both wrong and self-defeating, because it changes the behaviour being measured.

Using this before you start

For each thing somebody hopes this will fix, ask what measurement would fix it.

Where the answer is "a decision by somebody else", the programme's job is to produce the evidence and hand it over.

Confusing those two roles is how programmes acquire responsibility for outcomes they cannot reach.

What to check

Is your programme being judged on anything from the list above?

Where does the evidence it produces go?

Does somebody act on it, or does it return to the programme?

And has anybody said out loud what this work cannot do?

The point

Where the remedy is a decision by somebody else, the programme's job is to produce the evidence and hand it over.

Confusing those roles is how it acquires unreachable responsibilities.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.