Leading Field UX Research in 3 Cities

At a glance


Team	3 field researchers, each in a different city (I coordinated the brief, methodology and analysis among them)
Method	Field shadowing + in-situ interviews, cross-case analysis
Sample	6 nurses in 3 cities of different sizes
Stakeholders	Supplier agency (business output) + software vendor (product output) – with two different priorities
Deliverable	One report with two lines of findings, prioritised recommendations, client presentation

Context

A healthcare organisation in home care was moving from an older desktop/web application to a new native mobile app. Nurses spend a large part of their day in it – recording medical procedures directly at clients’ homes, driving between visits around the city or the district.

I received the brief from an agency that was leading the redesign for the client (the software vendor). It quickly became clear that this wasn’t one brief, but two:

The agency needed to defend the business case – what drives the app towards adoption and what holds it back.
The software vendor needed to know where the app “stumbles” in practice – specific usability problems and feature requests.

These two needs naturally pulled in different directions. The agency wanted to hear about value and adoption, the vendor wanted a list of bugs to fix. Reconciling both in a single field study, without one side getting only a fraction of the attention, was the first and probably most important decision challenge of the project.

My role

I led the project from the brief to the final presentation. Specifically, I was responsible for:

Framing the brief – I translated two partly conflicting briefs into one research plan with two parallel lines of analysis (adoption/value × usability/feature requests), so that neither side received a “trimmed” version of the research.
Leading a team of three – the team consisted of three field researchers, each covering one city. I set up a unified methodology (what to observe, how to run an interview, what sample criteria to use) so that data from different cities could be meaningfully compared at all.
Stakeholder relationship – I communicated constraints (holidays on the client side, the sensitivity of having a researcher present with a patient, GDPR) and negotiated a realistic data-collection schedule.
Analysis and synthesis – after data collection, I led my own three-phase analytical process (below) and was responsible for the final recommendations and their prioritisation.
Presenting the outputs – I prepared and presented the results to both stakeholders at the same time, in one shared artefact.

Approach

Why field shadowing, not just interviews. Nurses use the app on the move – in the car, in the lift, at a client’s home with gloves on. An interview at a desk would show what nurses think they do, not what they actually do. We chose half-day shadowing (the researcher rides along with a nurse for part of her regular route) complemented by a short interview before and after the trip.

Why we asked about the need, not whether the nurse can operate the app. I introduced an explicit rule into the brief: don’t ask “can you find feature X in the app,” but “did a need to do X even arise for you.” The difference is fundamental – the first question tests memory and training, the second reveals real gaps in the product.

Why six people in three cities, not sixteen in one. The sample was deliberately small but structured across branches of different sizes and different “maturity” in using the app – from a branch where they had been using the app for half a year to a branch where nurses were only learning the basic login. This allowed us, instead of a single average picture, to see how the same product behaves in differently organised operations.

How I made sure six interviews could carry a serious decision. Instead of one round of “collect quotes and write a summary,” I introduced a three-phase process:

Granular extraction – from each interview separately, I pulled out concrete data (not impressions) into predefined categories: what holds the app back, what drives it forward, where nurses work around it, what the real vs. declared use cases are.
Stress test / verification – for each respondent I deliberately looked for internal contradictions (e.g. “the app doesn’t bother me” vs. three specific problems listed five minutes later), and I distinguished findings independently confirmed across multiple people or cities from those resting on a single voice.
Synthesis and prioritisation – only findings that passed verification did I rank into recommendations by impact and by how many independent sources confirmed them.

This intermediate step (verification) isn’t a given in field research, but it proved key: for at least half of the respondents, a general question about satisfaction concealed problems that only surfaced with a more specific question. Without that step, the report would have contained weaker, less substantiated recommendations.

What we found (selection)

One missing feature blocked adoption of the entire app. Across two independent cities and without any coordination, nurses and team leaders named exactly the same barrier – the app couldn’t carry over text from a previous entry. Estimated time lost: 1.5–3 hours per nurse per day. This wasn’t one of twenty items on a list – it was a precondition without which nurses rationally stayed with the old system, regardless of what the app did newly and better.
The app was strong at orientation, weak at administration. Quickly looking up client information pushed the app forward; recording, ordering clients and handling exceptions happened mostly outside it in all three cities – on paper, in another app or on the desktop.
Practice varied even within one organisation. Nurses in the same company wrote the same type of documentation with varying regularity – something we could only uncover by comparing across cities, because no single interview would have shown it on its own.

Why it mattered to the business, not just UX

A standard mistake in field research is to stay in UX language – “the app has low satisfaction” or “nurses can’t operate the app.” No business decision-maker understands that, and nobody can invest on that basis. So when reporting, I translated the findings into language that leadership understands too:

A cost, not a UX nicety. We didn’t frame the missing copy function as a “comfort improvement,” but as a recurring operating cost – extra hours of work every day, for every nurse, every day, for as long as the app has this gap.
A risk, not just inconsistency. The differences we found in how regularly documentation is filled in we linked to the fact that insurers don’t reimburse incomplete records on audit – so to a real financial risk for the client, not to an “inconsistent habit.”
Speed, not just delay. The goal was to get this finding in front of the team before they invest further sprints in smaller improvements, and before the app rolls out to the remaining branches – fixing a blocking problem before a full rollout is orders of magnitude cheaper than after it.
Adoption, not satisfaction. The stakeholder’s ambition was to roll out the app across the board and switch off the old system. As long as the app keeps nurses in hybrid operation with the old system because of one missing feature, the company keeps paying to run two systems instead of one – we used that as a direct argument for prioritisation.

Deliverable and recommendations

The deliverable was one shared report with two readable lines (a business line for the agency, a product line for the app vendor), a cross-case comparison between branches, an inventory of real workarounds, and recommendations split into four priority levels – from the one precondition necessary for adoption to longer-term improvements. I presented the report to both stakeholders together, and it went into their standard approval process.

What I’d do differently next time

A sample of two people per city gave us rich data, but little room to tell whether a finding was specific to a given person or to the entire branch – for one finding (inconsistent documentation practice) we had to rely on the stakeholder verifying it themselves. Next time, I’d insist on at least one additional interview with a team leader in each city as part of data collection itself, not as a recommendation for the next round.