Kulcha App

Snack, socialise and stop Googling

A guide to effortless restaurant exploration

This work predates my current AI-augmented practice. It’s from 2023, pre-Claude era. I’ve kept the project here as a record of how I worked then.

Role

Product Designer

Client

Kulcha (live app)
General Assembly client project

Timeline

May 2023
three-week design sprint

Team

A team of three:
David J, Jessica H and me

At a glance

The problem
Finding somewhere new to eat had turned into a research task, spread across reviews, socials and word of mouth, with no single place to keep any of it.
What I did
Designed on a three-person team through a three-week client sprint: more than fifty behavioural interviews across ages 16 to 45, a survey and a competitor analysis, then paper and mid-fidelity prototypes tested and reworked over two rounds.
What it produced
A tested prototype where all five participants completed the core task of finding a restaurant, plus a recommendation flow and a save interaction they used without confusion.

The Problem

Kulcha was already live and already had an audience, which made this harder rather than easier: there was no blank page to design onto, and no licence to break what people were already doing. What the app had not solved was the thing those people actually cared about, which was finding a recommendation they could trust without doing an hour of homework first. That research was scattered across reviews, social posts and group chats, and nothing held it in one place long enough to be useful.

Kulcha splash + login screens

Who’s the client?

Kulcha is a social app for finding places to go: restaurants, cafes, bars, hotels and activities, anywhere in the world.

You follow people, you build lists of recommendations, and you share those lists with whoever follows you.

The main challenge

The challenge we were handed was finding recommendations people could trust.

The discovery workshop with the client broke that into three:

  1. Navigation issues
  2. Selling the social aspect of Kulcha
  3. Simplifying the onboarding and app’s ease of use

Research goal

To understand how people behave, and what they are actually after, when they are searching for or recommending somewhere to go.

The Approach

Three weeks, three of us, and five things to get through:

  1. Market research
  2. Competitor research
  3. Ten interviews with existing users
  4. More than fifty behavioural interviews
  5. Sixty-one survey responses

Market research

The market is crowded, so the first thing to settle was where Kulcha actually sits, which is between travel and leisure apps on one side and social networking on the other.

Working through both, I found that the travel and leisure app market holds 1.5 billion users worldwide and is forecast to grow 10.6% from 2019 to 2026, while the social media app market holds 4 billion users and is forecast to grow 26.2% from 2023 to 2030.

Both are growing, and neither one owns the overlap. That gap is the room Kulcha had to move into.

Market forecast

10.6%

Travel and leisure app market
growth from 2019 to 2026

26.2%

Social networking app
growth from 2023 to 2030

Competitor analysis

Apps like Out of Office, and Tabelog in Japan, already cover all five of the things people expect: uploading photos, adding friends, viewing details, adding recommendations and saving to a wishlist. Kulcha covered three of the five.

Competitor feature comparison table

That set the baseline: not a wish list, but the table stakes for anything in this category.

User research

The interviews started with ten people already using Kulcha.

Grid of 50+ Zoom interviews

What came back most often:

  • Looking for places to eat above anything else
  • Using Kulcha purely for recommending places they’ve been
  • Relying on word of mouth and Google searches to discover new places
  • Keeping track of recommendations using the Notes or Maps app on their phones
  • Researching using other platforms before deciding which place to visit

Kulcha’s existing users

What they’re doing

  • Only using Kulcha for recommending
  • Relying on word of mouth and Google searches to discover new places
  • Keeping track of recommendations using Notes or Maps app on their phones
  • When searching for places to go, searches on other platforms before deciding.
  • Usually looking for places to eat above anything else

What they’re saying

  • “New users wouldn’t find value in a recommendations app on a page with no recommendations”
  • “Kulcha funnels you to do certain things, but it takes too long to get you there”
  • “Too many buttons to push”
  • “I love Kulcha, but I don’t use it that frequently, I only add data after visiting a place”
  • “Multiple buttons to do the same thing”

Behavioural interviews

We then interviewed more than fifty people from a range of countries and backgrounds, aged 16 to 45, who had never opened Kulcha.

People who already use an app tell you about the app. People who have never seen it tell you about the problem, and the problem was what we were there for.

Key insights

Most people recommend restaurants to others

People bookmark or create lists on Google Maps/Notes App

People use Instagram/TikTok when searching for places & verifying the vibe, atmosphere, comments, photos, popularity, etc.

People cross check against multiple sources when researching and tend to do a lot of research to verify/manage their expectations

Survey data

A survey ran alongside the interviews, to put numbers against what people had been telling us one at a time.

These results come from sixty-one respondents:

Key insights

How do you typically organise and save recommendations that you receive from friends/family or online platforms?

Pie chart of the survey responses. The largest slice, 35%, is saving recommendations in a social media app or messages, followed by 21.7%, 13.3% and 10%, then a fan of much smaller answers.

What factors do you consider when choosing a local restaurant/cafe?

Price
6 (75%)
Location
6 (75%)
Reviews
5 (62.5%)
Recommendations from friends/family
6 (75%)
Atmosphere/ambience
6 (75%)
Availability of reservations/bookings
3 (37.5%)
How it looks in photographs
7 (87.5%)
Type of activity or attraction
1 (12.5%)

35% of people save recommendations inside a social app or their messages

87.5% of people look at photos when they are choosing a local restaurant or cafe

Food for thought: an audit of Kulcha as it stood

Before designing anything we ran a contextual inquiry and sat with five people while they used Kulcha as it was. Watching someone struggle with a screen you are about to redesign is the fastest way to stop arguing about it.

What that turned up:

  • It took some people 10 minutes to find recommendations at all, on an app whose whole purpose is recommendations
  • Four of five could not tell the save button from the recommend button
  • Three of five could not work out how to search
  • People told us the Restaurant Overview screen felt unfinished, and that they wanted more on it before they would act on anything it said

One thing came back the same way through every method, and it was not on the client’s list: people were looking for places to eat above anything else.

Key insights

Choice paralysis:

Too many ways to do the same thing and too many options

Icon ambiguity/confusion:

Too many icons meaning the same thing/confusing text

Lack of structure:

Information and hierarchy that needed structuring

Overwhelmed with all the insights…

All of that left a wall of notes and no order in them, so the three of us grouped and regrouped until the priorities were something we could argue about.

Affinity mapping animated GIF

Which led us to…

Nina persona

We built ‘Nina’ as Kulcha’s core user, out of the traits that came up most often across the interviews.

She is there so that a disagreement about the design has a specific person to be about. “The user” can be argued into wanting anything. Nina cannot.

Understanding Nina

We mapped what she does and how she feels at each step, against what the app could realistically do about either.

Empathy map

We then concluded…

The delicious truth: what the research narrowed it to

Nina needs to consolidate her restaurant research so that she can make an informed decision about which restaurant to visit.

The user journey

This is the path Nina takes now, every time she wants somewhere to eat:

Asking friends for recommendations

Asks friends for recommendations through word of mouth, messages or chat.

Takes notes or copies data from chats and social media replies to save it.

Feeling: Excited

Searching for restaurants

Searches name of place and address to find websites/or articles.

Checks Google Maps for the distance and reads the reviews, without being sure she can trust them.

Feeling: Overwhelmed & Unsure

Cross-checking sources

Looks at social media accounts or hashtags of the venue to look at images of food and interior.

Reads in-depth listicles/blogs.

Feeling: Doubtful & Apprehensive

Deciding and saving the restaurant

Discards any options that don’t meet her expectations or look low quality.

Saves/pins the good venues and data to a list.

Takes screenshots of the place.

Feeling: Relieved & Excited

Visiting the restaurant

Refers back to notes to access map info.

Uses map directions to get there.

Goes to venue and has a meal.

Takes photos and shares.

Feeling: Apprehensive, Relieved & Content

Five steps, and not one of them is the meal. Nina goes from source to source to find the information, and then again to convince herself the place is worth the evening.

That is the gap we went after.

Idea generation

We brainstormed against four prompts, written from what the journey had exposed:

How might we…

  1. Provide relevant information about the restaurant?
  2. Consolidate restaurant data?
  3. Help Nina form accurate expectations of restaurants?
  4. Make it fun to organise restaurant information?
Paper sketches and brainstorming

The winning dish: what we chose to solve

Feature Prioritisation Map

The feature prioritisation map left four contenders, and three weeks left room to be right about one of them:

  • A simpler search screen, with the writing and prompts reworked
  • Different information shown in the restaurant list
  • A new icon language for the buttons and interactions
  • And the one it turned on: an expanded Restaurant Overview screen

Prototypes, usability testing and user feedback

Paper prototype cards laid out on table Paper prototype sketch animation

We mocked up a paper prototype and a task flow around one idea: a collated Restaurant Overview screen.

Its order is the research, made literal. What people said they needed first sits at the top, and what they said they needed least is what you scroll to.

Usability testing: the first paper prototype

We tested the paper prototype with five people. It exposed these flaws.

Paper prototype usability results

Usability testing: the mid-fidelity prototype

We changed what the first round had exposed, built it up to mid fidelity and tested again. This is what the second round found.

Mid-fidelity prototype usability results

Updating the buttons and icons

That left the buttons, which were what four of five people had been getting wrong.
I ran a short survey on the icons alone, asking people what they thought each one meant, with no screen around it to give the game away.

Convention already had an answer for the ‘recommend’ button, and I had read it. What a convention cannot tell you is why the people in front of you keep reading it as something else, so I tested it here rather than taking it on trust.

Existing

Existing icon survey results

The new icon language

New button/icon language

Creating micro-interactions

Testing also turned up something quieter: three of five finished a task without being sure they had finished it.
The micro-interactions answer that directly. Every action now says back, immediately, that it landed.

Save/bookmark micro interaction Recommend button micro interaction Add to list micro interaction

How to order: the hierarchy of content

The final Restaurant Overview screen comes down to four bands of content, in the order people like Nina told us they wanted them.

Hierarchy of content - 4 key features

The Outcome

Prototype walkthrough

The final prototype, start to finish:

Outcome
  • Every participant completed the task of finding a restaurant
  • People said the Restaurant Overview screen gave them enough to decide whether the place was worth going to
  • The recommendation task was completed without confusion, which is where the icon work paid
  • Saving a restaurant to a list worked, and it was the feedback on the button that told people it had
Measuring success

The MVP is the Restaurant Overview screen, and specifically the fact that everything is on it.

It carries the details the research said people actually needed, in one place, so the decision can be made on that screen instead of across the five stops the journey map laid out. That is the whole claim, and it is the thing worth measuring.

The metrics I would watch:

  • User attrition
  • Number of recommendations
  • Number of ‘saves’ to list
Value for Kulcha
  • People stop needing the other apps to fill the gaps, which is the reason to open Kulcha first rather than last
  • A recommendation worth passing on is how the app grows without paying for it
  • The content people want to see is the content other people want to share, so the two feed each other
  • Recommending gets quick enough to be worth doing, and every recommendation is content Kulcha did not have to make
Next steps
  • Take the icon changes through the Activity Feed and Home screens
  • Let people upload their own photos and reviews inside the recommendation flow
  • Add table booking through The Fork and Open Table rather than building it
  • Either simplify the Explore screen or fold it into Search as filtering, because two screens are doing one job
  • Rework the List screen

Reflection

Three weeks and three of us meant we could research broadly or design deeply, and not both. The client arrived with three problems, and what the research kept returning to was none of them exactly: it was the Restaurant Overview screen, which people told us felt unfinished and which they wanted more from before they would act on anything it said. Choosing to spend what was left of the sprint there, rather than spreading it thinly across the brief we had been handed, is the decision the project turned on, and deciding what not to build was harder than deciding what to build.

The icon work is the part I would do the same way again. Convention had an answer for what ‘recommend’ should look like, and I ran a survey on it anyway, because we had already watched four of five people read save as recommend and no amount of best practice was going to tell us why they did.

What I would change is the order. We ran the process end to end, more or less A to Z, when the audit of the live app had already shown us where the pain was. Going deeper on the thing that was plainly broken, sooner, would have bought us another round of testing on it.