Wanderlust Woof — end-to-end mobile UX for dog-friendly travelWanderlust Woof — end-to-end mobile UX for dog-friendly travel

Problem

Travelling with a dog turns an ordinary trip into a research project. Which hotels actually allow pets and not just claim to? Which trails, cafés, and beaches are genuinely dog-friendly versus tolerant? Existing travel apps treat pets as a filter checkbox bolted onto a human-first experience, so dog owners end up cross-referencing three sources before they trust a booking.

Wanderlust Woof started from a single product question: what would a travel app look like if dog-friendliness were the organising principle instead of an afterthought?

Research

I began with the user, not the screens. The research focused on how dog owners actually plan trips — where their anxiety lives, what they verify, and at which point they abandon a booking.

The recurring theme was trust. Owners didn't need more listings; they needed confidence that a listing's 'dog-friendly' claim was real. That reframed the whole product: the job wasn't discovery, it was verified discovery.

• Mapped the end-to-end planning journey, from inspiration to post-trip
• Identified trust and verification as the core unmet need
• Separated four distinct intents that a single feed was conflating

Constraints

This was a focused concept project, which set the boundaries: native-feeling mobile patterns, a scope that one designer-engineer could prototype completely, and a deliverable precise enough to hand to a development team without a translation layer. Every decision had to survive being read by an engineer who wasn't in the room.

Information architecture

The original mental model crammed discovery, booking, in-trip needs, and post-trip sharing into one undifferentiated feed. I restructured the IA around the four journeys a dog owner actually moves through, so each surface answered one question well instead of four questions poorly.

• Discovery — find verified dog-friendly destinations and places
• Booking — reserve with the pet policy surfaced before commitment
• In-trip — navigate to nearby dog-friendly spots while travelling
• Post-trip — review and contribute the verification the next owner needs

UX decisions

The booking flow surfaces the pet policy before the user commits, not buried in fine print after — the single highest-leverage decision, because that's where trust was breaking. Discovery leads with verification signals rather than marketing photography.

Each of the four journeys got its own flow with explicit empty, loading, and error states, so the prototype represented the real experience rather than just the happy path.

Design decisions

The visual language is warm and rounded — approachable rather than utilitarian — to match the emotional context of travelling with a pet. Components were designed as a small, consistent system: cards, policy badges, and journey navigation that repeat across surfaces so the app feels coherent.

Crucially, the design was annotated for handoff: components, spacing, and interaction specs documented inline so a developer could implement without guessing.

Implementation & handoff

The deliverable was a complete, interactive Figma prototype covering all four journeys, structured the way a developer reads a spec: named components, documented interaction states, and annotations that closed the interpretation gap. This is the UX-engineer discipline — designing in a way that an implementation can match exactly, because the same person thinks in both Figma and code.

Results

The outcome was a coherent, handoff-ready product: four distinct journeys, a verification-first information architecture, and a documented prototype that a development team could build directly. The core reframe — from discovery to verified discovery — gave the product a defensible reason to exist in a crowded category.

Lessons learned

The strongest product decision wasn't a screen — it was the reframe from 'more listings' to 'trusted listings', which only surfaced because the research started with the user's anxiety instead of the feature list. And designing for handoff is a discipline in itself: a prototype that can't be implemented faithfully is only half a deliverable.