Dog Tracker app /
adapting to unexpected constraints and realigning the team

Task flows and handover. I took over the flow documentation from a colleague, cleaned it up, worked through the interaction details and wrote the descriptions the developers would build from. It was a waterfall setup, so everything went across at once. In hindsight that meant the developers got a large specification with no chance to question it while it was being written, which is a lot to ask of any team.

Route history. While the build started, the client asked for a new feature: a way to see where the dog had been. Pick a moment on a slider and see the position, or pick a range and see the whole path. I designed the interaction model for it.

The first beta. Rougher than any of us hoped. The build had real gaps against the spec, and at the same time all of us, client included, were learning things about the hardware that would have been useful months earlier. The GPS was less precise than assumed. The geofence alarm could fire while the dog was still inside the boundary. Pairing between tracker and phone failed often, for reasons spread across the client, the developers and the manufacturer. A good part of what we'd designed had been drawn for a device that didn't behave that way.

Communication. Under that pressure the conversation between the agency and the developers narrowed to email, and email to positions. It's an understandable place to end up when two teams are each being held to something the situation doesn't really allow. My UX lead felt it wasn't our role to make the developers' work easier, and there was a fair argument for that given the contract. I saw it differently, though I raised it carefully, being the junior person in the room.

The lead leaves. My UX lead moved on from the project and the office. I became the UX presence on the team and carried the collaboration with the client and developers for the remaining months.

A QA process that was easier to act on. I rewrote how we documented issues. Structured and specific so as to reduce misinterpretation. For complex or repeated issues, I provided more specific details. The first-time-user flow was a critical case. It had been built several times and come out wrong each time, so I documented every action and every path, reducing ambiguity to a minimum.

Changing how we talked. I pushed for regular calls instead of threads and offered to walk the team through anything that kept reappearing between betas. Internally I argued that their constraints were real, because they were. Once we were talking rather than writing we got further in an afternoon than we had in a fortnight, and I think both sides were relieved.

Designing for the hardware we had. Where a limitation was genuinely fixed I worked with it. Looser geofence tolerances so the alarm stopped firing on a dog that hadn't gone anywhere, and in-app wording that was honest about accuracy instead of promising precision the device couldn't deliver.

Still improving the product. Alongside that, I kept filling gaps in the concept. A proper dog profile, for one, so a tracker belonged to a specific animal with a breed and characteristics rather than to an anonymous device.