Case study

The tool nobody trusted

BT Group / OpenreachUX ResearchPaused, funding resuming in ~6 months

3user roles interviewed
2research phases
17research sessions
6 wkstotal research time

Redesigning a vehicle management tool

Engineers working for BT Group and Openreach are responsible for going out and physically repairing connections for consumers. They get a vehicle assigned to do this job. Managing thousands of those vehicles across BT and Openreach fell to a tool called eOrg: an interface that hadn't been meaningfully updated in years, originally built to track every kind of company asset from laptops to vans.

Different tools were responsible for different parts of the process.

eOrgHolman
  • Reassignment of vehicle
  • Updating location
  • Booking repairs
  • Daily vehicle check
  • Scheduling service

Fleet Managers had learned not to trust eOrg's data, so they defaulted to Holman even for the handful of things eOrg was supposed to own. A tool nobody trusts gets used less, which only made the data staler.

The asset management team brought me in with an open brief: understand what's actually broken, and build the case for whether it's worth fixing.

Two phases, one consistent question

The redesign moved through two connected phases: first understanding how the system was actually used, then testing whether the new concept held up under real tasks.

Phase 01 / Discovery

Cross-Role Interviews

Three groups touch vehicle allocation (Engineers/Drivers, Patch Managers, and Fleet leads), each with a different stake. I ran a 3-week discovery sprint of in-depth interviews across all three, digging into workflows, pain points, and what information actually mattered for their decisions.

  • Info scattered across 3 disconnected systems
  • Vehicles went "stuck" with no traceable owner
  • Bad parking data caused mislocated service bookings
  • Complexity forced reliance on informal training

Phase 02 / Usability Testing

Prototype Validation

Design built a to-be concept centered on an AI chat assistant as the primary interaction, with the dashboard kept as a fallback layer. I tested it over another 3-week round with Patch Managers and Drivers, watching for findability, understandability, and satisfaction.

  • "Set as home location" checkbox confused most Patch Managers
  • Users expected their team's vehicles to surface automatically
  • Matched flows moved faster & more confidently than eOrg

The plot twist

Here's the part that made this project a strategy story rather than just a usability report.

Users preferred the plain dashboard over the AI chat.

Given the choice, people wanted information at a glance, not a conversation to have with a system before they could even see it. That single finding reshaped the whole project.

What we built firstAI chat as the primary interaction
What shipped insteadA fast, clear dashboard

The chat feature got deprioritized, freeing up budget for a fast, clear dashboard and automatic vehicle transfer when someone leaves a role.

The final design included a dashboard with assigned vehicles and recent activity, a vehicle list with per-vehicle transfer/amend actions, a transfer-request flow, and a manager-facing review screen with a visible before/after record.

Where it stands

Before the project paused, the concept and prototype were validated with real users across all three groups. It's currently on hold pending funding, with a build phase expected to start in roughly six months.

What I'd do differently

I'd push harder, earlier, for a clear funding roadmap before scoping the full vision, shaping a smaller proof-of-concept that could ship and prove value on its own, rather than designing the complete picture and losing momentum when the bigger ask stalled.