Fixing a fragmented experience across systems

Remote technicians supported customers through complex on-site phone repairs, but the systems meant to support that work were deeply fragmented. A single job spanned multiple tools: the Field app, NextGen Portal, Honeycomb, a third-party routing system, and the underlying routing engine. A mix of 3rd party and homegrown platforms, each with its own complexities and constraints (not to mention competing roadmaps and priorities).

Each system had been built with good intentions, but not with each other in mind.

For technicians, this meant constantly switching contexts while trying to stay efficient, accurate, and on schedule.

Several of the internal and external platforms required to complete a single repair

Throughout a single repair, technicians were required to enter the same information multiple times. A pre-inspection completed with the customer in Field app had to be re-entered later in Portal just to advance the job.

Swiveling between systems wasn't optional. It was required.

Worse, the systems didn't always agree. Sync issues meant data could be inconsistent, leaving technicians unsure which source of truth to trust. When something couldn't be done in Field app by design, technicians would move to Portal to continue the job anyway, even when the business explicitly didn't want them to.

If a technician's pay depends on completing more jobs, they'll do whatever the system allows them to do.

This wasn't malicious. It was rational behavior in a broken system.

Journey map

One of the most damaging side effects came from routing.

A third-party system generated inefficient routes that were visualized in Field app. Even though Field wasn't responsible for routing logic, it was the interface technicians interacted with — so it absorbed the blame.

Over time, this chipped away at trust in Field app itself.

The result was a vicious cycle: more workarounds, more system switching, and less confidence that any single tool could be relied on end to end.

Field app in the vehicle

During ride-alongs, one moment stood out again and again.

Technicians would complete a required phone pre-inspection with the customer in their home via Field app, then walk back to their van and do the exact same inspection again in Portal just to move the job forward to repair the customer's device.

On top of needing to swivel between systems multiple times, our systems often didn't stay in sync with one another. This caused confusion and frustration for Experts who didn't know which system had the correct information when they disagreed.

The reaction was consistent.

That question became the emotional core of the project.

I worked in a hybrid role as Senior Manager, Product Design and Principal Designer at different points in the project. I drove stakeholder alignment and high-level direction while also designing across both Field app and Portal.

This work required navigating long-standing tension between teams. Historically, the Field and Portal teams had operated in silos, with a degree of distrust on both sides.

I was able to bridge that gap because I had spent over six years deeply embedded on the Field app team and had recently moved to the Portal team, where I was actively building relationships. That context allowed me to reframe conversations around the shared customer and technician experience, rather than technical ownership or constraints.

Design became the neutral ground.

To ground the work, I created a service blueprint informed by technician interviews, ride-alongs, and stakeholder conversations. This wasn't just a documentation exercise — it was a tool for alignment.

Service blueprint

Seeing the full journey laid out made it impossible to treat these as isolated UI problems.

Given the scope, we made a deliberate decision to focus on the core job flow from start to finish. Beginning-of-day and end-of-day tasks like inventory management were intentionally left out of scope for this iteration.

We knew we couldn't eliminate every system transition, but we could make them less painful — and more coherent.

On-site device repair

Early on, the teams aligned on a deceptively simple principle:

That principle became a powerful guardrail.

It forced meaningful changes across systems and shifted conversations from "what's easiest to build" to "what actually helps technicians do their jobs."

One change in particular had a huge effect.

Previously, if the issue a customer reported during scheduling didn't perfectly match what the technician discovered on arrival, Field app would block the job. The technician couldn't proceed, and the customer had to book a new appointment.

In reality, technicians often fixed the device anyway using unofficial workarounds — creating downstream issues with inventory tracking and store payments. This stemmed from a misalignment around a business decision made years prior — the Field app team had been told to block the job, the Portal team had been told to allow it to continue.

We redesigned the flow to allow technicians to continue the job legitimately when issues differed. This removed a major source of friction, improved the customer experience, and eliminated the need for risky workarounds that had been quietly harming the business.

This work hasn't launched yet, so metrics are still to come. Even without numbers, the impact was clear in how teams talked about the experience.

There was stronger shared ownership across systems, fewer arguments about "whose problem this was," and more confidence that the product ecosystem could actually support technicians end to end.

This work reinforced a simple truth: nothing exists in a vacuum.

Great design doesn't move forward without strong relationships. Fancy UI means very little if teams aren't aligned enough to build it. Politics, history, and incentives matter just as much as flows and screens.

Going forward, I invest earlier in relationships — within and beyond my immediate product team — before pushing hard on strategy or design direction. Alignment isn't a nice-to-have. It's the work.