Designing Admin and Internal Tools That Don't Get Neglected

A client's customer support team was using an internal ticket triage tool that had been built quickly, years earlier, and never revisited because it wasn't customer-facing. Support agents were spending an estimated extra 45 seconds per ticket working around a confusing filter panel and an unclear status system — multiplied across hundreds of tickets a day, that added up to real payroll cost the client hadn't connected to a design problem.

We pushed back on the common assumption that internal tools don't need the same design rigor as customer products because 'employees will learn it anyway.' They do learn it, but learning a bad tool doesn't make it fast — it makes people fluent in a slow process. We applied the same usability testing we'd use on a customer product, sitting with three support agents for an hour each, and found fixable friction points within the first session.

The redesign prioritized information density over visual polish, which is the opposite of most customer-facing work we do. Support agents wanted more information visible at once, not less — fewer clicks to see ticket history, customer tier, and past interactions on one screen instead of tabbed across three. What reads as 'cluttered' on a marketing site read as 'efficient' to someone doing the same task 200 times a day.

We also built the internal tool with the same component library as the client's customer-facing product, which cut design and build time significantly since most patterns — tables, filters, status badges — already existed. Internal tools don't need a unique visual identity; reusing an established system is almost always the right call, freeing up design time for the workflow problems that actually matter.