Turning a Cluttered Admin Dashboard Into a Usable Operations Console
An internal operations tool had grown feature-by-feature for years. New hires needed weeks to become productive in it, and mistakes were common. Here's how the interface was rebuilt around actual workflows instead of accumulated history.
The situation
The tool wasn't badly built — it was built correctly, over and over, for years, by different people solving different problems in isolation. Every new operational need got its own screen, its own menu entry, its own slightly different pattern for the same underlying action. Nobody had ever stepped back to look at it as a whole, because it had never been built as a whole.
The result was an interface organized around the history of its own construction rather than the actual sequence of tasks operations staff performed every day. New hires learned it by shadowing someone for weeks. Experienced staff had their own private workarounds for screens they'd learned to distrust, and a handful of high-consequence actions had no confirmation step at all — a mistake that was one misclick away.
The approach
We started with task-based research, not a visual redesign: sitting with the operations team while they did real work, mapping what they were actually trying to accomplish rather than what the existing menu structure implied they should be doing. That mapping became the new information architecture — organized around workflows like "resolve an exception" or "onboard an account," each pulling together whatever data and actions that task needed, regardless of which old screen they used to live on.
Rather than a one-time visual refresh, we introduced a lightweight internal design system: a small set of reusable components and interaction patterns so that as the tool keeps growing, new screens stay consistent with the ones already rebuilt instead of drifting the same way the original tool had. High-consequence actions were also given an explicit confirmation step as a deliberate, non-negotiable pattern applied everywhere it was relevant.
The outcome
New team members reach baseline proficiency in days instead of weeks, because the interface now follows the shape of the job rather than the shape of its own build history. The most error-prone actions require explicit confirmation, and the design system means each new feature added since the rebuild has stayed consistent instead of reintroducing the same drift that caused the original problem.
Internal tool that's outgrown itself?
Let's talk through what your actual workflows look like before we talk about screens.