User Perona

Problem

When I joined various product teams, I noticed something troubling: personas existed, but they were often too vague and generic—statements like “works a lot, cares about speed” that could apply to almost anyone. These shallow personas rarely guided design decisions; instead, they often became decoration. More critically, teams lacking deep empathy for users would fall back on assumptions or analytics alone—and end up designing features that missed the emotional or contextual drivers of behavior.

The real challenge was: How do we build personas that don’t just describe users, but guide real design decisions—especially around moments of interaction, emotion, and context?

In other words: How can a persona help you know why someone taps, swipes, or waits—especially under stress or distraction?

Process

Grounding in Real Users & Context

First, instead of starting with analytics or demographics, I begin with qualitative research:

• I talk to customer support teams, the frontline voices who hear real user complaints and anxieties daily.
• I engage sales teams, who listen to potential customers’ desires, hesitations, and how they pitch value.
• I interview users directly, in their natural environments (ethnographic research), to capture not just what they say, but how they behave.
• I audit competitors’ approaches to see what users are used to or frustrated by.
• I layer in quantitative data—analytics and metrics—to validate usage patterns and anomalies.

By combining all these sources, I find the unique patterns of behavior, pain, and motivation in the specific product domain (not generic “millennial professionals” or “power users”).

Shifting to Interaction Personas

Instead of personas focused on long-term goals or static traits, I create interaction personas. These are rooted in specific touchpoints where a user interacts with the product. Key elements include:

• Emotional state at that moment (stress, optimism, distraction)
• Environment (on-the-go, in a noisy cafe, low light, unstable network)
• Cognitive load / willpower (how much mental energy the user has)
• Attention span (is the user fully focused or multitasking?)
• Touchpoints (mobile, voice, in-person, notifications)
• Inclusion / accessibility (considering impairments or temporary situational constraints)

I sketch scenarios: for instance, waiting at a bus stop, expecting the bus to arrive, but facing delay and uncertainty. The persona’s frustration manifests: “Why is the bus late? Did it skip my stop? Should I wait or take a taxi?” This narrative moment reveals design opportunities—like status updates, delay estimation, or alternative suggestions.

I encourage visualizing the moment—storyboards, quick sketches, or situational maps—to make the persona feel alive to the team.

Embedding Personas Into Design

From there, I use interaction personas as decision filters:

When proposing a feature, I ask: “How would Maria (persona) feel and act at this point?”

During wireframe reviews, I check whether the interface respects the persona’s cognitive load, context, and emotional state.

I limit persona scope to only things relevant to the problem: any persona detail that doesn’t influence behavior or design is trimmed.

I maintain open persona artifacts so that all team members—from engineering to product to marketing—can refer to them and use consistent language around who we design for.