Designing internal tools that people will actually use

Internal software has a special failure mode: it ships, it works, and nobody uses it. The investment is sunk and the spreadsheet keeps winning.

Why internal tools fail

1. The developer optimized for the developer. The screens make sense if you wrote the code.
2. The workflow does not match how the work actually happens.
3. The tool replaces a flexible process with a rigid one without buying anything in return.
4. Onboarding takes longer than the spreadsheet would have.
5. Nobody asked the people who would use it.

What works

• Watch people do the work first. Take notes. Do not propose anything for a week.
• Ship the smallest version that solves one real problem. Earn the right to expand.
• Optimize for the most-used path. Make it three clicks for the action that happens 80 percent of the time.
• Match the vocabulary they use, not the vocabulary you would use.
• When in doubt, ship a feature behind a feature flag and watch how it gets used.