Stop Describing Users. Start Defining Behavior.

Why describing the user isn’t enough, and how to translate those conditions into interface decisions.

The relevant connections rarely follow the obvious pattern.

If you’re not a Medium member, you can still read the full article here → Friend Link

In the redesign of BCP’s turn management system, we noticed something curious. The problem wasn’t that users were older adults or that they had little digital experience. People with very different profiles ended up showing similar behavior in front of the system: they hesitated before acting, looked for confirmation, and depended on staff to complete simple tasks.

The explanation wasn’t in who they were. It was in the conditions under which they were interacting.

That observation led to a question: what information about a person is actually actionable for designing an interface?

In UX, there is a widely accepted practice: defining users.

We create personas. We segment audiences. We build profiles.

The intention is correct. We need to understand who we are designing for.

But there is a limitation: many user definitions describe who the person is, but they do not explain under what conditions that person interacts.

And interfaces do not respond to abstract people. They respond to people under specific conditions.

The limit of turning user profiles into design decisions

A person can be described as: 35 years old. A professional. A frequent user of digital products.

But that same person can behave in completely different ways depending on the conditions surrounding the task. They can be a new user who doesn’t know the product, a person under pressure solving an urgent problem, a frequent user looking for speed, or someone making a decision where mistakes have consequences.

The user profile may remain stable. But the way that person interacts changes as those conditions change.

This is one of the reasons personas lose effectiveness when they become static artifacts, as Nielsen Norman Group notes in Why Personas Fail: personas remain valuable for aligning teams; the limitation appears when their attributes are translated directly into interface decisions. The point isn’t to abandon them, but to stop treating them as predictive design variables.

When demographics lead to wrong design decisions

Imagine a banking system designed for: “Older adults with low digital experience.”

The most common interpretation might be to simplify everything: fewer options, less information, fewer features.

But that decision assumes age explains behavior. And it doesn’t necessarily.

An older user who performs banking operations daily may need speed and efficiency. A younger user making an important transfer for the first time may need more guidance, confirmations, and reassurance.

Age alone doesn’t sufficiently explain behavior. The condition under which the person is acting tends to explain the variation in behavior better: how familiar they are with the task, how much risk they perceive, and what the consequences of a mistake are.

This same logic appears in Jobs to Be Done, Clayton Christensen’s theory: behavior is better explained by the goal a person is trying to accomplish in a specific situation than by their demographic attributes.

User definition as a design variable

When we define users through behavior, the definition stops being only a descriptive document.

It becomes a design input rather than a descriptive artifact: a condition that shapes the interface before design decisions are made.

It influences decisions related to:

• Information architecture
• Visual hierarchy
• Layout
• Interaction
• System feedback
• Visual language

Not because there is a universal formula. But because certain human conditions create recurring needs that can become design principles.

A condition, in this sense, is any factor that changes how a person approaches a task or makes decisions during an interaction.

Within the framework, interaction conditions define the general category, while interaction patterns represent recurring situations that can be translated into design decisions.

These conditions are not all the same type. Some describe the person’s internal state: their cognitive load, their level of familiarity with the task. Others describe the external situation they are acting within: perceived risk, the consequences of a mistake, the time available. Distinguishing between the two prevents two people from applying the framework differently to the same scenario.

High-risk condition

Type: Situational condition.

Description: The person perceives a high level of risk, uncertainty, or possibility of error during the interaction.

Need: Certainty.

Translation rule: Reduce ambiguity and increase confidence.

Interface decisions:

• Visible system states.
• Clear confirmations.
• Immediate feedback.
• Strong hierarchy.
• Important actions that are easy to identify.

High cognitive load condition

Type: User condition.

Description: The person needs to process too much information or make too many simultaneous decisions.

Need: Reduce mental effort.

Translation rule: Simplify interpretation and prioritize relevant information.

Interface decisions:

• Lower visual density.
• Group related information.
• Step-by-step progression.
• Removal of unnecessary decisions.

Nielsen Norman Group documents this same principle in Minimize Cognitive Load to Maximize Usability, explaining that while not all cognitive load can be removed, designers can reduce unnecessary extraneous load through clear hierarchy, grouping, and familiar interaction patterns.

High familiarity condition

Type: User condition.

Description: The person knows the product and wants to complete tasks faster.

Need: Efficiency.

Translation rule: Reduce friction for experienced users.

Interface decisions:

• Quick actions.
• Personalization.
• Shortcuts.
• Less dependence on instructions.

Interaction conditions also need evidence

Defining behavior does not mean replacing one assumption with another.

Saying: “The user is anxious” is not automatically more valid than saying: “I think this button should be larger.”

Both statements can be wrong if they aren’t backed by evidence.

The purpose of a Translation Framework is not to make decisions appear more scientific. It is to make visible the logic that connects an observation to a decision.

Interaction conditions must be grounded in evidence:

• User research.
• Observation.
• Behavioral data.
• Product metrics.
• Operational context.
• Usability testing.

Here’s what that looks like in practice, for the three patterns described above:

High risk

• Observable evidence: hesitation before confirming, re-reading the screen, support inquiries before completing the action.
• How to gather it: session recordings, post-task interviews, support ticket review.

High cognitive load

• Observable evidence: sequencing errors, mid-flow abandonment, elevated task time.
• How to gather it: funnel analytics, eye-tracking, moderated usability testing.

High familiarity

• Observable evidence: use of shortcuts, fluid navigation without reading instructions, low error rate.
• How to gather it: repeat-behavior analytics, interviews with frequent users.

The goal is not to eliminate human interpretation. It is to make it traceable.

Without this foundation, many decisions end up expressed as preferences.

“I think this button should be larger.” “I think this screen should have fewer elements.” “I think this flow should be simpler.”

These decisions may be correct. But the conversation stays limited to opinions.

When a definition based on behavior exists, the conversation changes.

It’s no longer: “Let’s make the button more visible because it looks better.”

It becomes: “The user is interacting under a low-confidence condition, so we need to increase perceived control through greater visibility, feedback, and confirmation.”

A user is not only a profile. A user emerges from the interaction between person, goal, and conditions.

People do not have a single behavior. They change depending on the situation.

An expert can become a beginner when facing an unfamiliar tool. A frequent user can become an anxious user when a significant consequence is at stake. A person can experience accessibility barriers in certain contexts even when they don’t normally have them.

Because behavior doesn’t depend only on who you are. It depends on the conditions under which you’re acting.

Microsoft formalized this idea with its Persona Spectrum, an inclusive design framework that understands access barriers as permanent, temporary, or situational.

A person holding a baby with one arm experiences, in that moment, an interaction constraint similar to someone with a permanent disability in that limb. Designing for the condition, not only for the diagnosis or profile, expands who can use a product.

User Definition within the Translation Framework

Within the Translation Framework, the process I use to translate human understanding into interface decisions, User Definition functions as the first level of translation.

It does not describe only a target audience. It defines the conditions affecting interaction.

The goal is not to eliminate user definition. It is to redefine what becomes actionable within it.

The process is:

How the Translation Framework reframes each step of traditional UX practice.

An interface is not designed only for who a person is. It is designed for the conditions under which that person is trying to act.

Because those conditions are what turn human understanding into design decisions.

The question changes from: Who is our user?

To: What conditions are shaping their interaction?

This is what it looks like in a real case

In the redesign of BCP’s (Banco de Crédito del Perú) turn management system, the dominant pattern combined two types of condition: a situational high-risk condition, high anxiety in a financial environment and a user condition of low familiarity, low digital literacy, infrequent use of the system, mostly older adults who hesitated before interacting and depended on branch staff to initiate any task.

Translating those two conditions into interface decisions meant: increased spacing and lower layout density, high-affordance interaction patterns, clearly labeled actions with simplified iconography, large touch targets, and a high-contrast visual hierarchy designed to convey calm.

The design wasn’t trying to make the interface look simpler: it was trying to change an observable behavior, from staff dependency to digital autonomy. The result was a 70% increase in autonomous system use and a 60% reduction in help requests to staff.

In practice, these conditions rarely appear in isolation. Most interfaces operate at the intersection of two or more.

→ Full case study: BCP Turn Management System

Where this model is applied

This translation layer doesn’t stay in theory: it has been documented across 35 recurring interaction patterns and 184 associated interface decisions, drawn from project documentation, applied research, and the synthesis of patterns observed across different contexts.

→ Behavioral Translation Dictionary

→ Explore the complete framework

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation. ***Linkedin | [Instagram](https://www.instagram.com/usemuzli/) | [Twitter](https://x.com/usemuzli)***