Internal tools fail differently from consumer apps

Most design writing is about consumer products, which means most design instinct is calibrated for a user who has a choice. That user can leave. They will leave if the first thirty seconds are confusing. So the craft optimises for onboarding, for delight, for the moment of first impression, and all of that is correct, for that user.

Nobody churns from an internal tool. They just get slower, and quieter, and start keeping a spreadsheet.

The person using a CRM did not choose it. Their employer did, probably two years ago, probably on price. They will open it eight times today and about two thousand times this year, and they cannot leave. Almost every instinct formed on consumer products is either irrelevant to them or actively harmful.

Here's the shift that matters most: a consumer product's cost is paid once and its value is paid continuously. An internal tool is the reverse. Every small friction (an extra click, a form that loses state, a filter that resets on navigation) gets paid again, by the same person, every single time. A two-second annoyance in a task performed forty times a day is eighty seconds a day, which is roughly five hours a year, per person. That's the real unit of measurement, and it's why “it's only one extra click” is the most expensive sentence in internal tooling.

There's also no churn signal, which is what makes these products so hard to improve. Nobody uninstalls a CRM. When it's bad, people don't leave. They adapt around it. They keep a personal spreadsheet. They batch their data entry to Friday afternoon and do it badly. They stop logging the calls that feel marginal. The tool's usage metrics look fine right up until the data in it is worthless, and by then the problem is three quarters upstream of where anyone is looking.

So the research method changes. Interviews are weak here, because people are bad at describing friction they've normalised. Ask someone how their CRM is and they'll say “fine, you get used to it,” which is not data. What works is watching them do the task they do most, at their own speed, without helping. The moments to write down are the ones they don't mention: the pause before a dropdown, the tab they keep open in the background, the field they always leave blank, the thing they do twice because they don't trust it worked the first time.

That last one is worth its own note. Repeated actions are usually a trust problem, not a comprehension problem. When someone saves twice, or refreshes after submitting, or checks the record again after editing it, the interface has failed to confirm something, not with a toast that disappears in three seconds, but with state that persists and says what changed.

A few things I'd design differently for internal tools than for anything consumer-facing.

Density is a feature. Consumer design rewards generous whitespace because the user is being led somewhere. An operator scanning two hundred records is not being led anywhere. They're hunting, and every row that requires a scroll is a row that isn't in their working memory. The right density for an expert user looks cramped to a designer reviewing it in isolation, and it's usually still not dense enough.

Keyboard paths beat click targets. Anyone who does a task hundreds of times will learn a keyboard route if you give them one, and they'll resent you for every operation that requires the mouse. This is the single cheapest performance improvement available in most internal tools, and it's almost always skipped because it doesn't show up in a Figma file.

Preserve state aggressively. Filters, sort order, column widths, scroll position, half-completed forms. The user's context is expensive to rebuild and free to store. Every reset is a small tax on someone who was in the middle of something.

Design the empty state as onboarding. New employees inherit these tools with no training and a message telling them to ask whoever sits nearest if they get stuck. The empty state is the only onboarding most of them will get, and it usually says “No records found.”

None of this is exotic. It's mostly the ordinary craft applied with a different weighting: repetition over first impression, certainty over delight, density over breathing room. The reason it gets missed isn't difficulty. It's that internal tools are reviewed by people who see them for twenty minutes in a demo, and designed by people who see them for two weeks in a project, for users who will see them for four years.