Pawly

The starting brief was “Uber for dogs”: open the app, find somebody nearby, book and follow the route. The primary situation was concrete — an owner is at work, needs help during the day and has about fifteen minutes to decide whether a stranger can be trusted with the dog and access to the home. A quick list of profiles answers only the easiest part of that decision.

The market research showed a split. Self-service products made the transaction fast but kept verification shallow; services with institutional trust relied on a manager, a phone call and manual assignment. The gap was not another map with more pins. It was a way to combine speed with evidence without pretending that an early marketplace already has supply everywhere.

The economics narrowed the everyday story as well. Twenty weekday walks at the researched price range would cost eighteen to twenty-two thousand roubles a month, so the realistic starting behaviour became one to three bookings a week, not a daily habit. That moved the product away from a universal convenience promise and toward reliability on the occasions that matter.

A green check next to a portrait compresses seven different claims into one word: identity, legal status, training, interview, practical skill, references and the date on which any of those were last checked. It asks the owner to trust the interface instead of letting them inspect what the interface knows.

The same problem repeats during the service. A live dot on a map looks precise, but a lost connection can make a safe walk look like a missing dog. A completed route does not prove who was handed over at the door, or that the dog came home. The evidence has to survive failure: last signal instead of a blank map, locally buffered route and photos, pickup and drop-off proof, and an explicit final state that says the pet is home.

So the product object changed from “a walker nearby” to the whole chain: compatible person, visible verification, handover, route, return and recovery. Speed remained a requirement, but never by hiding the part the operation could not guarantee.

I started with secondary research, five competitors and a focused audit of the closest analogue. The primary-persona interview was simulated, not recruited, and used only to challenge the first hypothesis. It did: the final pickup and drop-off photos mattered more than watching the whole route, and “pet is home” mattered more than a perfect GPS line. Those remain hypotheses for live interviews, but they were strong enough to change what the prototype had to make testable.

Scope came next: 42 Must-haves out of 65 requirements, then a 95-screen product map with 81 core nodes and seven user flows. I deliberately did not turn every node into a frame. Eighty-one were designed at flow and group level; sixteen decision-heavy screens were assembled into seventeen routed frames, plus the landing. That kept the built layer on the questions worth testing — compatibility, verification, handover proof, replacement and two-sided money — instead of spending the same time on routine settings screens.

Then the visual system and the build: 63 primitive tokens, 30 semantic tokens, fourteen text styles and 33 React components with named Storybook matrices. Figma, specifications, React and the catalogue use the same semantic names. The prototype went through structural review, parity review, visual acceptance and synthetic agent runs; the findings returned to the same source instead of being patched only in screenshots.

The first full review found a contradiction in the product’s strongest claim. The landing promised a price with the platform fee included; the booking screen added a separate service fee; the walker payout was calculated from a third model. Each surface looked plausible alone. Together they described two different businesses on the page that asked users to trust one number. The fix began with one price table in the decision log, then made every surface read from it.

The prototype also remembered too much. Cancelling one synthetic booking wrote the state to local storage, and the next visitor could arrive to an empty owner home with no way to reset it. In the gallery, seventeen live screens were mounted inside links, leaving the controls inside every preview in the keyboard order. Both passed a frame review because neither exists in a frame; they appeared only when the build was used as a product.

The main review and consistency pass examined 58 findings; the visual acceptance added fifteen more. Seventy-one were resolved and two were dismissed as false positives. A synthetic agent run found the state-persistence defect, the fix was retested, and the final pass covered seventeen routes and the landing with 91 screenshots, nine reports and no console errors. None of those numbers is user validation. They are evidence that the prototype now tells one story and survives its own interactions.

The system has 63 primitive and 30 semantic tokens, fourteen text styles and 33 React components. Component code never reaches for a raw colour, radius or type size; the same semantic layer mirrors the Figma library and the screen specifications. Storybook renders every declared combination from the actual component, so the catalogue cannot quietly become a second implementation.

A full Figma audit covered 448 instances and found zero broken instances, zero text nodes without a design-system style, zero unbound fills or strokes and zero spacing values outside the scale. The screen-to-code parity pass found the opposite class of problem — specifications that had fallen behind a component already used in the build — and fixed the wrong side instead of forcing the code back to an old document.

The matrices below matter because the service lives outside the default state: the network drops, proof is missing, a disclosure opens, a timeline is waiting, an action becomes unavailable. Those are not edge decorations around the interface. They are the interface when trust is at risk.