Case Study · 01

Redesigning for one hand,
in the field.

How a logging tool built for desks got rebuilt for people who can't put anything down — and why earning that redesign took longer than designing it.

Timeline
7 weeks, one release
Team
3 (2 engineers + PM)
Role
Product Designer
Surface
Native app · field ops
AI summary

The condensed version.

Problem: Fieldnote's logging form was designed for a desk, but survey teams used it standing in mud, in gloves, in bad light — so they filled it in later from memory, which defeated the point of the tool. Solution: I earned the mandate to rebuild the form as a one-handed, thumb-reachable flow with offline-first sync, then spent most of the project negotiating what to cut with support, sales, and engineering rather than designing new screens. Impact: Same-day logging went from roughly a third of surveys to the large majority of them within the first month, and the pattern built for one team's forms got reused twice more without a design request.

The throughline: the redesign's hardest problem was never the interface — it was getting permission to touch it, and then getting three teams to agree on what "simple" meant. The visuals were the easy 20%. The alignment, the evidence-gathering, and the patience to wait on one idea until the timing was right were the actual work.

01 Quick Summary

Problem, solution, and the impact that followed.

Problem

The field form was built like an office form — dense, two-handed, and useless in the conditions surveyors actually worked in. Most logging happened hours later, from memory.

Solution

A one-handed, thumb-reachable entry flow with offline queueing, built only after I could show the cost of the old one in numbers stakeholders couldn't wave off.

Impact

Same-day logging rose from roughly a third of surveys to the large majority within a month, and the flow pattern shipped twice more without anyone asking for it.

02 Earning the Mandate

Nobody asked for a redesign.

Nobody had scoped a redesign, so I built the case for one myself: I pulled 200 field sessions, showed that most logging happened hours after the fact, and traded a full rebuild for a scoped one-handed flow. The fight wasn't about the interface — it was about getting three months of roadmap reshuffled on evidence I'd gathered without being asked to.

The opening

Fieldnote's roadmap for the quarter was already set — two integrations and a billing overhaul, nothing touching the core logging form. I hadn't been asked to look at it. But onboarding calls kept surfacing the same complaint in different words: people loved the idea of the app and stopped using the form within a week. Nobody had connected that pattern to the form itself, because nobody had gone and watched someone actually fill one out in the field.

Making the case

So I went and watched. I sat in on four site visits with two survey crews and timed how the form actually got used against how it was designed to be used. The gap was the whole story: the form assumed two free hands, a stable surface, and good light. Surveyors had a clipboard, one glove off, and maybe ninety seconds before the next reading. They weren't logging in the field at all — they were logging from memory, back at the truck, sometimes a full day later.

I pulled 200 anonymized sessions from the logs and timestamped each entry against the survey it referred to. 68% of entries were logged more than two hours after the observation they described, and accuracy complaints from clients tracked almost exactly with that delay. That was the number that moved the roadmap conversation — not a mockup, not a rewritten form, just a chart showing that the product's core promise, accurate field data, was being quietly defeated by its own interface.

  1. Surveyor observes a defect on-site, hands full, gloves on.
  2. Defers logging — no time, no free hand, screen unreadable in sunlight.
  3. Continues the route; observation held in memory or a paper note.
  4. Returns to the truck at end of shift, sometimes hours later.
  5. Logs from memory, reconstructing details rather than recording them.

Five steps between an observation and a record of it, with the accuracy of the record decaying at every one. The redesign I eventually pitched collapsed that to a single step: log where you're standing, one thumb, before you've moved on.

Diagram: the five-step "log from memory" journey mapped against the one-step "log in place" flow, timestamps annotated at each stage
Diagram: the five-step memory-logging journey the 200-session audit surfaced, set against the single-step flow proposed in the two-week prototype.

The mandate

I didn't ask for a redesign in that meeting — I asked for two weeks to prototype a fix, scoped tightly enough that it wouldn't touch the quarter's committed work. Scoping it small was the actual unlock: leadership could say yes to two weeks of exploration without reopening the whole roadmap. That two-week prototype is what eventually became the mandate for the real seven-week build.

You rarely get handed a redesign — you build the case for one out of a problem that already exists but hasn't been named yet. Evidence scoped small enough to say yes to is worth more than a pitch scoped to be right.

03 Collaboration

Three teams, one form.

Support wanted every field validated before submit; engineering wanted a rebuild I didn't have time for; sales wanted custom fields per client. I resolved all three with the same move — showing, not arguing: a real offline-sync demo and a client-config layer instead of a fork. None of the three fights got settled by who outranked whom — they got settled by whoever brought the working prototype.

The prototype worked. The problem was that three teams now had opinions about what "worked" should mean, and none of them agreed with each other or with me.

Support wanted a stricter form, not a faster one

Support's instinct was reasonable on its face: bad data was worse than slow data, so validate everything before it could be submitted. But strict validation was exactly what made the old form unusable in the field — you can't fix a dropdown error with one thumb and a glove on. I built a real offline-sync demo instead of arguing the point: log now with soft validation, sync when connectivity returns, flag anomalies for a five-second review at that point instead of blocking entry in the moment. Watching it queue and resolve in real time did more than any deck would have — support signed off in the same meeting.

Sales wanted per-client custom fields

Sales had three enterprise clients asking for custom fields on the form, and the easy answer — fork the form per client — would have quietly killed the offline-sync work, since every fork needed its own sync logic. I proposed a config layer instead: one form, one sync path, fields toggled per client from a settings table engineering already had. It shipped two of the three requested fields in week one of the build and made the third a five-minute config change instead of a new release.

Diagram: forked-form architecture (one codebase per client) vs. the shared config-layer architecture that shipped
Diagram: the forked-per-client architecture sales initially wanted, compared against the single form with a client-config layer that actually shipped.

Neither fight was won by seniority — they were won by having a working thing to point at instead of a stronger opinion. A demo that already runs is a hard thing to argue against; a mockup is an easy thing to keep redesigning in a meeting.

Cross-team disagreement isn't a design failure to smooth over — it's the actual site of the design work. Bring the thing that already runs, not the argument for why it should.

04 A Pattern That Scaled

The second time took two days.

Six weeks after the field-form redesign shipped, the inspections team needed the same one-handed, offline-first pattern for their own checklist — and got it in two days, not seven weeks, because the config layer and sync logic already existed. The first redesign wasn't just a form fix; it was reusable infrastructure that happened to be shaped like a form.

The inspections team ran a parallel checklist product with almost the same field conditions — gloved hands, bad light, delayed logging — but I hadn't touched their flow and hadn't been asked to. Six weeks after the survey-form redesign shipped, their PM asked, half-joking, whether "the Fieldnote fix" could be copied over.

It could, almost entirely as-is. The offline-sync engine didn't care what fields it was queueing. The client-config layer already supported toggling fields per team. The one-handed layout was a component, not a one-off screen.

Diagram: the reused sync engine and config layer feeding two separate front-end flows — survey form and inspection checklist

What had taken seven weeks the first time — because half of that time was spent earning the mandate and negotiating the three fights — took two days the second time, because the mandate and the architecture were already sitting there. The only new work was the checklist-specific field set, which their own PM configured directly through the settings table without needing engineering time.

A well-scoped fight for one team's problem quietly becomes infrastructure for the next team's, if you build the underlying pattern instead of just the screen in front of you. The redesign that took seven weeks was actually two products' worth of work, paid for once.

05 The Idea We Waited On

Patience, shipped.

During the original audit I'd proposed voice-logging as a true hands-free option, and it got shelved for scope reasons — correctly, since the team didn't have appetite for it yet. It shipped nine months later, once the transcription infrastructure it needed already existed from unrelated work. Waiting on an idea until the infrastructure catches up isn't giving up on it — it's the only way it ships without a fight.

During the original field audit, one surveyor had said something I kept coming back to: even a one-thumb tap flow assumed a hand was free at all, and half the time neither hand was. The honest fix was voice — describe the observation, transcribe it, review later. I sketched it, tested a rough version with two crews, and the qualitative signal was strong.

I didn't fight for it, because the case for waiting was better than the case for shipping it then. Voice logging needed transcription infrastructure the config layer didn't have yet, and pushing it into the same release as the one-handed redesign would have reopened exactly the scope conversation I'd just closed. I wrote it up, attached the test recordings, and let it sit.

Timeline: the nine-month gap between the shelved voice-logging proposal and the unrelated transcription feature that made it possible
Timeline: the nine months between shelving voice-logging and the unrelated project that quietly built the infrastructure it needed.

Nine months later, an unrelated project added transcription support for customer-service notes. The infrastructure I'd been waiting on showed up for a completely different reason, and voice-logging for Fieldnote became a two-week feature instead of a new initiative, because the hard, expensive part had already been justified and built by someone else's problem.

Not every good idea needs to win its fight immediately. Some ideas are better served by a well-documented pause than a battle you'd have to win twice.

06 The End

The alignment was the design.

None of the four stories above are really about the form. The form itself — one-handed, offline-first, config-driven — is the kind of design decision that looks almost obvious in hindsight, the sort of thing a portfolio slide makes look inevitable. It wasn't. Getting to build it took a self-initiated audit, three separate stakeholder fights resolved with working prototypes instead of arguments, and one idea that only shipped because I was willing to let it wait nine months.

The alignment, the persuasion, and the patience aren't preliminaries to the design. They are the design. The screens were the easy 20% — and they only got to exist because the other 80% got done first.