Smiths Detection — service consoles

01 Problem

Maintenance engineers servicing detection hardware worked across tools built for the machines, not the people. Diagnosing an issue meant cross-referencing several screens and a lot of tribal knowledge, which made onboarding slow and mistakes easy. Leadership wanted consoles a newer engineer could pick up quickly and that behaved consistently across very different regional teams. The brief was effectively: same job, far less friction, and measurable enough that support load and satisfaction would move.

02 Constraints

• Used daily in the field by engineers, not power users tolerant of rough edges.
• Three regions (Europe, APAC, North America) with different workflows and expectations.
• Built on top of existing enterprise systems and data models I had to design within, not replace.
• WCAG 2.1 AA required across every shipped surface.

03 Core design decision

Organise the console around the engineer’s task, not the machine’s data model.

The legacy tools mirrored how the hardware reported itself — screens per subsystem, data dumped as-is. I reorganised the interface around what an engineer is actually trying to do in the moment (diagnose, service, verify), pulling the relevant data from across subsystems into one task view. That meant a newer engineer could follow the task instead of having to already know which screen held which number.

Directions I rejected

• Faithful one-to-one digitisation of the legacy screensSafest to build and easiest to sign off, but it would have preserved exactly the fragmentation that made the tools slow to learn.
• A single dense “expert” dashboardFast for veterans, but it punished the newer engineers onboarding was meant to help — the opposite of the goal.

04 Design ↔ code, in one loop

Because I both designed and wrote the React, I could test interaction ideas against real service data instead of mockup data — and several times the real data is what changed the design, surfacing edge cases and states that never showed up in a static frame.

On the systems side, I automated a recurring reporting task in Python that the team had been doing by hand, cutting a roughly six-hour job to about fifteen minutes — which freed the team from a standing chore and removed a regular source of copy-paste error.

05 What shipped & what it moved

Measured outcomes from the shipped work, across the three regional teams:

95%

CSAT across three regionsFrom the recurring customer-satisfaction surveys run with the regional service teams.

80%

faster maintenance workflowsTime to complete the core service task, compared before and after the console rollout.

70%

fewer support ticketsDrop in console-related support tickets in the period following launch and usability testing.

06 What I’d redesign today

• Push regional differences deeper into the design system as configuration, rather than handling them case by case.
• Invest earlier in offline/degraded-connection states — a field reality that deserved first-class design from day one.