OUTCOME Three different mental states at rest. A crowded mind is not the default. It describes one-third of users.
Uyara - Journaling App
User Research
UYARA had two user personas, both based on assumptions. Before any design started, we ran a 10-question survey with 6 real users to test those assumptions with actual data.
Research that decided who a product was for.
UYARA is a mental-wellness product for urban Indians. When I joined the work it had two user personas, and both of them had been written from assumption rather than evidence.
My job was to test those assumptions before any design started. A 10-question survey with six real respondents replaced the guesswork with four archetypes: three to design for, and one to deliberately leave out.
You can't design for a user you invented.
Invented personas feel productive. They give a team something to point at in meetings and a reason to stop arguing. The trouble is that everything built on top of them inherits the guess.
UYARA's two personas described a user who journals every day and responds to streaks. Nobody had checked whether that person existed, or whether the people who actually needed the product looked anything like them.
I ran the research and wrote the archetypes.
I wrote the survey, chose the question framing, ran it, read every response, and built the archetype model from the answers. I also wrote the anti-persona, which is the part most teams skip.
The interface designs shown further down were produced by the product team afterwards. They are here to show what the research changed, not as work I'm claiming.
Ask in a way that lets the answer be inconvenient.
A survey confirms whatever it is written to confirm. So each question was built to split the group rather than gather agreement, and none of them mentioned journaling, streaks or wellness apps.
Six respondents is a small sample and I treated it as one. The aim was not statistical confidence; it was to find out whether the assumed user showed up at all.
Each question was designed to reveal differences, not confirm assumptions.
OUTCOME Half the respondents don’t find self-reflection useful. This became the key signal for the anti-persona.
OUTCOME 4 in 6 avoid typing when processing emotions. This validated voice input as the right default.
OUTCOME 5 in 6 find typing frustrating when mentally drained. It’s a barrier, not a preference.
OUTCOME 4 in 6 can’t speak freely in their environment. A quiet/whisper mode moved from nice-to-have to required.
OUTCOME 5 in 6 said Calm and Headspace don’t fit their context. There is a clear product gap in the Indian market.
OUTCOME The audience split evenly. UYARA’s target user is in the half that does not want streak-based mechanics.
THE FIND The one person who chose the tree matched every other UYARA target signal: mentally overloaded, distrusts wellness apps, finds typing frustrating. The target user is the minority in this sample, but a large minority in the real world.
OUTCOME The real competition is not Calm or Headspace. It’s the Notes app and calling a friend.
OUTCOME Four different user needs emerged from this one question. Each became the basis for one archetype.
Three user types to design for. One to consciously exclude.
The survey revealed four consistent patterns: 4 in 6 felt mentally overloaded when trying to rest. 4 in 6 found typing frustrating when tired. 4 in 6 said existing wellness apps don’t fit their context. Only 1 in 6 preferred a visual progress indicator over a streak counter, but that 1 in 6 represents 50 million urban working Indians.
"Get the thoughts out of my head so I can sleep."
"Externalise the day, without performing a wellness ritual."
"Forget the day happened. Just give me direct advice if anything."
Same user, same need. A completely different design.
The research clarified who UYARA is actually for. The first version was a standard journaling app: a blank page and a streak counter. The research showed both were wrong for this user. Here is what changed.
Now
How are you feeling?Talk whenever you’re ready.
here with you with you
Your journal
The research changed what UYARA is: from a journaling tool you fill in, to a companion you simply talk to. The product now fits how people actually process their thoughts, rather than how a traditional journal expects them to.
What this research can't tell you.
The sample is small. Six respondents cannot be projected onto a population. Every distribution on this page is a signal about six people, and I've labelled the counts rather than converting them into percentages that would imply more confidence than exists.
It's self-reported. People describe their own habits inaccurately, particularly around rest, mood and screen use. Nothing here was observed directly.
The recruitment wasn't random. Respondents came from a reachable network, which skews urban, working and English-comfortable. That happens to match the intended audience, but it's a convenience sample, not a representative one.
It has no follow-up. The archetypes were never re-tested after the redesign, so this case shows research changing a direction, not research proven right by outcomes.
Small research still beats no research.
Naming who you're not for is the useful half. The anti-persona settled more arguments than the three target archetypes combined, because it gave the team permission to say no to features.
Ask about the situation, not the product. Nobody was asked whether they'd use a journaling app. They were asked what their head is doing at night. The answers were far more honest for it.
Six honest answers beat two invented personas. The point wasn't statistical proof. It was replacing a guess nobody had checked with evidence somebody could argue with.
Do it before design, not after. Had this run three months later, the streak counter and the blank page would already have been built, and the research would have become a debate about whether to throw work away.
Ten questions changed the whole product.
UYARA started as a journaling app for a user who had been imagined rather than found. Ten questions and six honest answers later, it became a voice-first companion for a user the team could actually describe.
None of that required a big budget or a long timeline. It required asking before building, and being willing to hear that the original idea was aimed at the wrong person.