Why most internal tools go unused

It has to be faster than the workaround

People do not resist new tools out of stubbornness. They resist tools that are slower than the spreadsheet they already have, and they work that out considerably faster than whoever is measuring adoption.

If the new system takes more clicks to do the common thing, it loses, regardless of how much better it is in theory or how complete its data model is.

Count the interactions for the frequent case and compare them honestly against the old way. That comparison predicts adoption better than any amount of enthusiasm in a requirements meeting.

Design for the frequent path

Most internal tools are designed around the full feature set rather than the one screen a user opens forty times a day. Every field has an advocate in the specification meeting, and none of those advocates are the person who has to fill them in.

Make the frequent path effortless and bury the rare one. Optimising for the common case at the expense of the exception feels wrong when you are writing the spec and is almost always correct in production.

Every field you remove is a field that cannot be filled in wrong, which improves data quality at the same time as adoption.

Beware data entry that benefits somebody else

A reliable adoption killer is asking one person to enter data purely so another person can have a report. The cost is immediate and personal; the benefit is invisible and belongs to someone the user may never meet.

Sometimes it is genuinely necessary. When it is, make it as cheap as possible and close the loop so the person entering the data sees something useful come back. Silence guarantees the discipline decays.

Where it is not necessary, cut it. A lot of mandatory fields exist because somebody once thought the information might be useful, not because anyone uses it.

Ship it in front of people early

The gap between what someone describes in a meeting and what they actually do is enormous, and it is not dishonesty. Expertise makes steps invisible, so people genuinely cannot narrate their own routine accurately.

Working software in front of a real user in week two prevents months of building the wrong thing. It also surfaces the informal steps nobody mentioned because they had stopped noticing them.

An hour watching someone work is usually worth several hours of requirements meetings.

Roll out to one team first

Launching to everyone at once means discovering adoption problems at maximum blast radius, after the design has become expensive to change.

One team, one workflow, in production surfaces the same problems while fixing them is still cheap. It also produces the most persuasive thing available: colleagues telling other colleagues that it is genuinely faster.

The people who resisted hardest often make the best pilot group, because they will tell you exactly what is wrong instead of being polite about it.

Adoption is a metric, so watch it

Decide before launch what usage should look like and then actually check. Not a satisfaction survey, which measures politeness, but whether the thing is being opened and whether the old workaround has stopped.

If the shadow spreadsheet reopens, you did not replace it. You added a system beside it, and that is worse than before because now there are two places to look.

Being willing to change the tool in response to that signal is what separates internal software that survives from internal software that gets quietly abandoned.