B
Case Study B · Travel App

ATAY

Role

Service Designer · Solo

Duration

10 Weeks

Platform

iOS · Mobile

Tools

Figma · FigJam · Maze

Methods

User Interviews · Competitive Analysis · Prototype Testing

10 Traveler Interviews 4 countries · Mixed backgrounds
06 Local Contributors Chicago · Rabat · London
03 Prototype Iterations Lo-fi → Mid-fi → Hi-fi
05 Usability Sessions Moderated · Task-based
08 Weeks Duration Research → Prototype
01

Overview

Tourism has a flattening effect. Every city — from Marrakech to Chicago — gets reduced to its most photographed, most Googled, most tripadvisored version of itself. Travelers leave having seen the representation of a place, not the place itself.

Atay (Arabic: أتاي, "tea") is a travel companion app built on a simple premise: the best guide to a city is someone who actually lives there. It connects travelers with hyperlocal recommendations from verified residents — not algorithms, advertisers, or other tourists.

The name is intentional. In Moroccan culture, sharing tea is an act of radical hospitality — you don't rush it, you sit with it, you let it open conversation. That's the experience Atay tries to replicate in a travel context.

The Problem

Existing travel apps surface popular, commercially-driven, tourist-reviewed content. The local perspective — the thing travelers actually want — is structurally invisible.

The Opportunity

Residents know their cities in ways no algorithm does. The design challenge is building the trust, verification, and discovery systems that make local knowledge accessible without losing its authenticity.

My Role

Solo UX/UI — research synthesis, information architecture, interaction design, visual design, and prototype testing.

How Might We

Help tourists experience a city the way its residents live it — not the way its tourism board photographs it?

02

Research

10

User Interviews

Interviewed two distinct groups: frequent travelers (5) and urban locals in cities they'd received visitors (5). Both perspectives were essential — the supply side and the demand side of local knowledge.

05

Competitive Analysis

Audited TripAdvisor, Google Maps, Airbnb Experiences, Yelp, and Foursquare — analyzing trust signals, recommendation provenance, and where the "local voice" was either absent or manufactured.

3

Shadow Sessions

Observed three travelers navigating Chicago using only existing apps for a day. Documented decision points, moments of frustration, and what they asked locals directly when the app failed them.

Key Insights

The gap between what travelers want and what apps provide is structural, not cosmetic.

"I always feel like I'm missing the real city. The tourist spots are fine but they feel staged — like a theme park version of the place."

Insight 01 · The Staged Experience Problem

"TripAdvisor is just tourists reviewing experiences made for tourists. It's circular. I want to know where the locals actually eat."

Insight 02 · Tourist Reviewing Tourist

"When I ask a local — even a stranger on the street — I always get a better recommendation in 30 seconds than 20 minutes of app research."

Insight 03 · The Local as Living Algorithm

"I'd trust a recommendation from someone who actually lives there — if I could verify they actually live there. That's the thing apps haven't solved."

Insight 04 · Trust Requires Verification

Traveler Journey Map

Mapping the emotional arc of a typical city visit revealed exactly where friction and disappointment concentrate.

Stage 01

Pre-Trip Planning

Opens TripAdvisor, Google Maps, Reddit. Overwhelmed by the volume of "Top 10" lists. Frustrated that they all recommend the same places.

Mood
Low
Stage 02

Arrival

Arrives with a list of "must-sees." Follows the app. First stop is crowded, overpriced, and nothing like the photos. Mood dips.

Mood
Low
Stage 03

Discovery

Wanders off-plan. Stumbles on a local market, a café the app doesn't mention, a neighborhood that feels real. Best moment of the trip.

Mood
High
Stage 04

Navigation

Tries to get from the market to a restaurant. App routes them through a tourist corridor. Gets lost. Misses dinner reservation.

Mood
Low
Stage 05

Reflection

Tells friends about the trip. The stories are all from the unplanned moments — the market, the café, the stranger who gave directions. Not the tourist sites.

Mood
High
03

Competitive Analysis

Every major platform aggregates opinions — but none distinguish between resident knowledge and tourist opinion. That's the gap.

Platform Content Source Strengths Critical Gap
TripAdvisor Tourist-generated reviews ScaleCoverage Reviews are from visitors, not residents. Commercial bias. Ranking manipulation well documented.
Google Maps Algorithm + mixed reviews NavigationReal-time data Optimized for popularity and SEO. Local voice is statistically drowned out.
Airbnb Experiences Host-curated activities Local hostsCuration Monetized "local" — hosts are incentivized to perform authenticity, not express it. Tourism-first, not resident-first.
Foursquare / Swarm Check-in data + tips Location contextResident mix No verification of local vs visitor. Tips are minimal, unstructured, and rarely updated.
Atay ↗ Verified residents only Authentic sourceVerified localsNon-commercial Challenge: building the local contributor network and maintaining trust without commercial incentives.
04

User Personas

[ Photo ]
Primary Persona · The Traveler

Sofia

29 · Product Manager · New York, NY · Frequent traveler (6+ trips/year)

Sofia travels for curiosity, not leisure. She does extensive research before every trip but consistently finds that the best moments are the ones her research didn't surface. She's tried every travel app and describes most of them as "tourist traps wrapped in good UX." She's started asking hotel staff and strangers for recommendations instead.

Travel Style

Independent, cultural immersion

App Behavior

Heavy pre-trip, light during

Trust Signal

Peer recommendations, local voice

Pain Points

Every "best of" list leads to the same places, optimized for Instagram not experience.
Can't tell if a reviewer is a tourist or a resident — the context changes everything.
Navigation apps route her efficiently but not meaningfully — she doesn't want the fastest route, she wants the right route.
[ Photo ]
Secondary Persona · The Local

James

37 · Teacher · Chicago, IL · 14-year resident

James is proud of his city and quietly frustrated that visitors only ever see the same three neighborhoods. He recommends places to visiting friends all the time and loves the expression on their faces when they discover something unexpected. He'd contribute to a platform like Atay if it didn't feel like unpaid marketing work for a corporation.

Motivation

Pride of place, local advocacy

Barrier

Time investment, trust in platform

Trust Signal

Non-commercial, community-driven

Concerns as Contributor

Doesn't want his favorite spots to become overrun with tourists if he recommends them.
Skeptical of platforms that monetize his knowledge without giving back to the community.
Wants control: the ability to update or remove recommendations, and see who's visiting the places he shared.
05

Information Architecture

The IA problem was dual-sided: the app needed two distinct entry points — one for travelers exploring, one for locals contributing — while keeping the experience unified.

ATAY
Explore
Map
Saved
Contribute
Profile
Categories
Local Filter
Local Day Route
Collections
Add a Place

↑ Simplified site map — full IA available in Figma prototype

06

Design Process

01 — Discover

Research + Journey Mapping

Interviews with travelers and locals. Shadow sessions. Identified the dual-persona problem and the trust gap as primary design constraints.

02 — Define

HMW + Design Principles

Defined three principles: Local First, Trust is Earned (not Claimed), and Discovery over Direction.

03 — Ideate

Sketching + Concept Testing

Sketched 4 concept directions. Validated the "Local Badge" verification model and the "Local Day" itinerary builder through concept testing.

04 — Prototype

Lo-Fi → Hi-Fi

Built flows in FigJam, then two full hi-fi iterations in Figma. First iteration tested the map; second tested the contributor flow.

05 — Test

Usability Testing

3 rounds of moderated testing — split between traveler and local contributor perspectives. Key fix: simplified the Local Badge verification from 7 steps to 3.

From Sketch to Screen

Lo-Fi Wireframe

[ Insert Figma export ]

01 · Lo-Fidelity

Structural sketches focused on information hierarchy and navigation model. Validated the tab structure and map-primary layout.

Mid-Fi Prototype

[ Insert Figma export ]

02 · Mid-Fidelity

Introduced the Local Badge and category filter. First round of usability testing revealed the filter toggle needed stronger visual differentiation.

Hi-Fi Design

[ Insert Figma export ]

03 · Hi-Fidelity

Full visual design with verified local iconography, neighborhood-based map clusters, and the Local Day itinerary builder.

07

Design Decisions

Map with Local Filter

[ Insert Figma export ]

Decision 01

The Local / Tourist Toggle — Not a Filter, a Lens

Early versions used a dropdown filter to switch between "Local Recommendations" and "All Reviews." Testing showed users didn't use it — it felt like an advanced setting, not a core choice.

Redesigned as a persistent toggle embedded in the map header, visually switching the entire map layer — color scheme, pin types, and category density — to signal that this is a fundamentally different view of the same city.

Design Rationale

The toggle needed to feel like choosing a different guide, not adjusting a search filter. The visual mode shift communicates: you're now seeing this city through different eyes.

Decision 02

Local Badge — Verification Without Bureaucracy

The original verification flow had 7 steps — address upload, ID check, selfie, manual review. Drop-off in testing was 80% before step 4. The trust signal that made the product valuable was killing the contributor pipeline.

Simplified to 3 steps: location history check (passive, opt-in), one local landmark question, and a community endorsement request. Verification communicates "enough confidence to trust" rather than "airtight identity proof."

Design Rationale

Trust in a platform like Atay is probabilistic, not absolute. The verification UX needed to reflect that — rigorous enough to be meaningful, light enough to not deter honest contributors.

Local Verification Flow

[ Insert Figma export ]

Local Day Builder

[ Insert Figma export ]

Decision 03

"Local Day" — Curated Itinerary Builder

Research showed travelers don't just want individual recommendations — they want a narrative: a coherent day that flows geographically and thematically. Point-of-interest apps don't do this.

The Local Day feature lets verified locals build full-day itineraries (morning → afternoon → evening) tied to a neighborhood, a theme, or a mood. Travelers get a curated experience, locals get a canvas for storytelling about their city.

Design Rationale

Individual spots are data. A Local Day is a story. The product becomes more valuable when it shifts from information retrieval to experience curation — and more human when locals are the authors.

08

Usability Testing

Testing was split across two user types: travelers and local contributors. Three rounds, 5 participants each. Core tasks: find a local recommendation in an unfamiliar neighborhood, and add a recommendation as a local.

Issue 01 · Round 1 · Travelers

Local filter was invisible

4 of 5 users never switched to the Local view. They didn't notice the toggle in the map header, and one described it as "a settings thing, not a main feature."

Fix Applied

Promoted the toggle to the primary navigation bar with distinct icon states. Added an onboarding tooltip on first launch: "See this city through local eyes."

Issue 02 · Round 1 · Locals

Verification felt like surveillance

All 5 local participants expressed discomfort with the original 7-step verification. Two dropped out. Common phrase: "This feels like I'm applying for something."

Fix Applied

Redesigned verification as a 3-step lightweight flow. Reframed the language: from "Verify Your Identity" to "Earn Your Local Badge." Completion rate improved to 4/5.

Issue 03 · Round 2 · Travelers

No sense of route or distance between recommendations

Users exploring multiple local spots couldn't tell if they were walkable or required transit. Discovery stalled because the spatial relationship between places wasn't communicated.

Fix Applied

Added walk-time and transit-time indicators directly on place cards in list view. Introduced the "Local Day" route builder in Round 3 as a full solution — a curated, geo-logical sequence of local spots.

09

Final Design

Four core screens representing the complete traveler journey: Explore landing, Local map view, Place detail with Local Badge, and Local Day itinerary.

Explore

[ Figma export ]

01 · Explore

Let Discover

[ Figma export ]

02 · Local View

Place Detail

[ Figma export ]

03 · Place Detail

Map / Route

[ Figma export ]

04 · Local Day

10

Reflection

What Worked

+ Designing for two personas simultaneously forced rigor. Every decision had to serve the traveler without exploiting the local — that tension produced better solutions than designing for one user alone.
+ The Local Day feature emerged directly from usability testing — not from the initial brief. Following the research rather than the plan led to the product's most differentiated feature.
+ Reframing verification as "earning a badge" instead of "proving identity" was a copy change that drove a UX shift. Language is design.

What I'd Push Further

The economics for local contributors need deeper design thinking. What makes contribution sustainable long-term without introducing commercial incentives that corrupt the local voice?
Overtourism risk: Atay could accelerate the gentrification it's trying to counter if a "hidden gem" goes viral. A recommendation visibility system and neighborhood impact awareness would need UX design.
With more time: A longitudinal study comparing travel satisfaction scores between Atay users and traditional app users — the qualitative research suggested the difference is real; quantifying it would be compelling.