A user persona is a short, research-based profile of a typical user: who they are, the context they use your product in, what they’re trying to get done, what frustrates them, and how they behave. Teams write a handful of them so that “the user” stops meaning whoever happens to be in the room. A persona is only as good as the research behind it, though. Made up in a meeting, it’s just your own assumptions with a stock photo attached, and that matters most when the user is nothing like you.
I’m a Kiwi developer in Seoul, and the product I work on is a community for people who are serious about skincare and cosmetics. I am not that person. My skincare routine is sunscreen, on a good day. Which means my instincts about what our users want are wrong often enough that I’ve learned to stop trusting them.
If you’re building for an audience with different needs, backgrounds, or preferences to your own, your gut is miscalibrated. Here’s what I do about it.
Research beats instinct#
When your gut is tuned to the wrong user, the only fix is contact with the real ones. Surveys and interviews give you the raw material — people will tell you exactly what frustrates them if you ask open questions and then shut up. Lurking in the forums and communities where your users already hang out is even cheaper, and the daily complaints and enthusiasms there tell you more than any workshop. Existing reports and studies round it out; they’re mostly useful for checking whether the pattern you spotted is real or just the three loudest people.
An example persona#
Here’s the shape I’d boil that research into, for a community app like the one I’ve described. Min-ji is made up for this post; a real persona should come straight out of your interviews and forum reading.
| Example persona | Min-ji, 29 |
|---|---|
| Context | Office worker in Seoul with sensitive, combination skin. Browses the community on her commute and posts a review every month or so. |
| Goals | Find products that won’t irritate her skin, and work out whether a new serum is worth the money before she buys it. |
| Frustrations | Reviews that turn out to be sponsored, reviewers whose skin is nothing like hers, and long threads with one useful answer buried in them. |
| What she needs from the product | Reviews she can filter by skin type and concern, a clear label on sponsored posts, and a quick way to ask people with skin like hers. |
A persona earns its keep when it feeds the backlog. Each goal or frustration turns into a user story in the usual “As a …, I want …, so that …” shape: As a shopper with sensitive skin, I want to filter reviews by skin type, so that I only read about products from people whose skin reacts like mine. If a story can’t be traced back to a persona, it’s worth asking who it’s really for.
Get inside their head, then into their routine#
Empathy mapping sounds like consultant theatre, but the exercise of writing down what a persona thinks, feels, says and does forces you to notice where you’ve been projecting your own preferences. The sticky notes aren’t the point. Catching yourself assuming is.
The stronger version is immersion: use the products your users use, watch the content they watch, go where they go. Actually trying the routines our users discuss has taught me more about what the product needs to explain than any spec document ever did.
Prototype, test, listen, repeat#
No amount of research survives first contact with a prototype. So build the smallest testable version, put it in front of actual target users, and treat their confusion as data, not as them “using it wrong”. Keep real feedback channels open after launch too, because understanding isn’t a one-time achievement — the audience shifts, trends move, and last year’s insight quietly goes stale. The loop doesn’t finish. That’s fine.
Borrow better-calibrated eyes#
Some gaps you can’t close alone. Colleagues who actually belong to the target group will spot things you’d never see, and I lean on mine constantly. When the gap between you and your audience is a canyon rather than a crack, hire for it — a consultant if you must, or better, a team member who simply is the user.
Underneath all of it is one discipline: remembering the goal is to make something that resonates with them, not something that pleases you. I still catch myself designing for me. The research, the testing, and the borrowed eyes are just ways of catching it early. Do that consistently and you end up with a product that works for the people actually using it — which was the whole point.