Doggio —
Designing Trust Signals into a Service Marketplace
How do you convince someone to hand their dog to a stranger? I designed a dual-role marketplace that solves the trust problem through surfaced verification, live GPS tracking, and a linear booking flow — serving both dog owners and walkers in a single localised app.
Trust is the
conversion barrier
In service marketplaces, trust is the single biggest barrier to a first transaction. Dog owners need to hand a living being to a stranger — and existing platforms in Lisbon offered fragmented listings, opaque vetting, and no visibility into what happens during a walk. The result: high browse-to-bounce rates and owners defaulting to word-of-mouth referrals instead.
The design challenge was threefold: (1) surface trust signals early enough to prevent drop-off, (2) serve two distinct user roles — owners and walkers — within a single coherent app, and (3) localise the entire experience for Lisbon (EUR pricing, Portuguese names, distance-based discovery, multi-language support for an expat-heavy city).
End-to-end
ownership
I was the sole designer on this project, responsible for every deliverable from research through to interactive prototype:
- User research — competitive audit (Rover, Wag, Gudog), user interviews, persona development
- Information architecture — 80+ screens mapped across two user roles with role-switching logic
- Design system — 40+ reusable components built on shadcn/ui with design tokens in Figma
- Visual design — high-fidelity screens for both Owner and Walker flows, localised to Lisbon
- Interactive prototype — fully functional React app (Next.js + Tailwind) with live data, navigation, and AI support bot
- Design-dev handoff — component documentation, token specs, and annotated flows
Interactive Prototype — Scroll & tap to explore
Best experienced on mobile viewport · Open in new tab
App Flow Walkthroughs
Key screen sequences for both the owner and walker experiences — swipe or scroll to browse.
Dog Owner Flow
Dog Walker Flow
Who I'm
designing for
- Find a trustworthy walker within walking distance in Lisbon
- Book recurring walks without friction — in their preferred language
- Track their dogs' walks in real-time via GPS
- Manage multiple dogs (Max, Bella, Charlie) with distinct profiles and care instructions
- Language barriers — expat walkers may not speak Portuguese
- Can't assess trustworthiness without meeting in person
- No visibility into what happens during the walk
- Existing platforms don't show distance or availability clearly
- Get discovered by nearby owners through distance-based search
- Display language skills (PT/EN) to attract expat and local clients
- Manage walk requests, active walks, and earnings in one place
- Build credibility through verified badges and reviews
- Competing with unverified, cheaper alternatives on social media
- No way to show qualifications or language skills upfront
- Managing bookings across WhatsApp, Instagram, and phone is fragmented
- No professional tool for walk logging, photo sharing, or reporting
What research
revealed
I audited Rover, Wag, and Gudog, interviewed dog owners in Lisbon, and synthesised findings into actionable design responses:
| Key Insight | Design Response |
|---|---|
| Trust is the primary conversion barrier for first-time bookings | Verification badges (Email / ID / Phone) surfaced on the browse card — visible before opening any profile |
| Users shortlist 2–3 walkers before deciding — comparison is the core browse behaviour | Persistent filter bar + all key comparators (price, distance, rating, language) visible on the card itself |
| Language matching is a key comfort factor in Lisbon's multilingual community | Language badges (flag + code) visible on every walker card; dedicated language filter in browse |
| Distance is the deciding factor — owners want walkers within walking distance | Distance shown prominently on cards; radius filter slider; all walkers geo-located in Lisbon neighbourhoods |
| Owners need real-time visibility into active walks to feel safe | Live GPS tracking with route map, duration, distance, and photo updates — addressing the core anxiety gap |
12 weeks,
5 phases
• User interviews in Lisbon revealed language matching as key factor
• Defined dual-role persona model
• Scoped localisation requirements (EUR, distance, 5 languages)
• Designed 9-step linear booking flow to reduce drop-off
• Defined role-switching logic between flows
• Validated core journey against persona goals
• Established design tokens (colour, type, spacing)
• Created language badge & flag switcher patterns
• Ensured Figma library mirrors React implementation
• Applied localisation (EUR pricing, Lisbon names, distance)
• Ran consistency audit across 80+ screens
• Surfaced trust signals at browse-card level
• Implemented AI support bot with guided flows
• Conducted usability testing and iterated
• Produced design-dev handoff documentation
The booking
flow
The primary conversion path — from discovery to confirmed booking — was designed as a 9-step linear flow that eliminates decision fatigue. Each step answers exactly one question, with trust signals visible throughout.
Strategic
trade-offs
Every design decision was backed by research. Here are the five highest-impact choices that shaped the product:
| Decision | Rationale | Alternative Rejected |
|---|---|---|
| Trust signals surfaced on browse cards | Research showed shortlisting happens at card level. Users opened 5-6 profiles before finding trust info — adding friction before the first decision. Surfacing verification badges (Email/ID/Phone) on the card reduced browse-to-profile drop-off. | Trust info in profile only — most users never reach a profile if the card doesn't earn initial trust |
| Live GPS tracking during walks | Real-time visibility is the highest-impact trust feature post-booking. Owners see their dog's route, photos, and can message the walker — addressing in-walk anxiety which interviews identified as the core trust gap. | Post-walk report only — doesn't address real-time anxiety |
| Dual-role app with role switching | User interviews revealed many walkers are also dog owners. A single app with “Switch to Owner/Walker” reduces install friction, shares authentication, and halves the maintenance cost of two separate products. | Separate apps — doubles maintenance, confuses users who are both |
| Distance-based hyper-local discovery | Dog walking is hyper-local — a walker 8km away is impractical for daily use. Distance shown in meters on every card makes proximity the primary filter, matching the mental model of “who's in my neighbourhood.” | City-wide list without distance — useless for a service that requires physical proximity |
| Language badges (flag + code) on walker cards | In multilingual Lisbon (large expat population), language matching is a key comfort factor. Visible flag badges let owners instantly identify walkers they can communicate with — no profile drill-in required. | Language info in profile only — requires drilling into every profile to check compatibility |
High-fidelity screens
Visual foundations
What I
delivered
As sole designer, I took this project from a blank canvas to a fully interactive prototype in 12 weeks — demonstrating that trust, localisation, and dual-role complexity can be systematically designed into a marketplace product.
What I
learned
Designing for two user roles in a single app taught me that shared components and consistent patterns are non-negotiable at scale — without the design system, maintaining coherence across 80+ screens would have been impossible. The biggest insight was that trust signals must appear at the earliest decision point (the browse card), not buried in detail views. If I were to revisit this project, I would conduct usability testing earlier in the process and explore progressive disclosure more aggressively in the booking flow to further reduce cognitive load.
What this project demonstrates
This case study shows marketplace UX focused on trust — progressive disclosure in booking, transparent pricing, and profile signals that reduce anxiety in a high-stakes service category, validated in a fully interactive React prototype.
