← Field Notes FN — 001 / Four kinds of user, and why each one matters differently
Filed under — FIELD-NOTES / USER-RESEARCH / TAXONOMY / UX-DESIGN 6 min · 1,395 words

Four kinds of user, and why each one matters differently

For years I treated "user" as a uniform noun. The data didn't. Four kinds of user — First-Level, Second-Level, Passive, Hostage — and what each one's feedback actually means.

For years I treated “user” as a uniform noun. The data didn’t.

I trained on user-centric design the way most product designers did: the user is the center of the work, study them carefully, design around their needs. Fine. True. Insufficient. The thing nobody told me — and that I had to learn over five or six years of misreading product feedback — is that the kind of relationship a person has with your product changes what their feedback means. The same complaint, from two different kinds of user, is two different signals. Treating “user” as a single category is treating four phenomena as one.

There are at least four. I started naming them in 2021. I haven’t found a more useful taxonomy since.

First-Level User (FLU) — the person who chose you

These are the people who actively detected a need, researched options, and chose your product as the best solution. They arrive because something specific about you solves something specific for them. They want to learn how to use everything you offer.

In most teams, they’re the loudest voice in the user-feedback channel — and that’s exactly the trap. Their feedback is aspirational. They’ll suggest advanced features. They’ll forgive minor issues you should have fixed. They’ll defend the product in conversations with the doubters. They become unconscious ambassadors.

For testing new features, they’re the easiest cohort. For honest signal about what’s broken, they’re the worst — they’ve already decided to forgive you.

Second-Level User (SLU) — the person who could have picked anyone

This person uses your product but isn’t in love with it. They detected the same need an FLU did, but they picked you for a forgettable reason: you were the first option they found, the easiest to install, the one their colleague mentioned. They feel neither attachment nor rejection. They’re not interested in learning more than they need to optimize the workflow they already had.

If a competing product solves part of their problem slightly better, they won’t hesitate to adopt the competitor in parallel — not switching, just supplementing. They’ll keep using you for one thing and use someone else for another. They are the canonical churn risk.

For research, this is the most useful group, in proportion. Their churn rate is a diagnostic instrument. Where do they leak away from you? What did the parallel product do that you didn’t? The answer to those questions is the most actionable signal in your funnel — and you only get it if you’re sampling from this cohort, not just from the FLUs.

Passive User (PU) — the person who didn’t know they had the problem

Passive users have a vague sense that something in their workflow is uncomfortable, but they haven’t named it as a need. They land on your product through a referral or a passing exposure, not through active search. They don’t know what most of your features do. They’re open to learning, but they need to be invited.

The difference between a Passive User and a Second-Level User is intent: SLUs chose you (badly); PUs arrived at you. They have growth potential — they can become FLUs over time if your product educates them well — but they can also disappear quietly if the environment doesn’t carry them along.

The design lever for this group is feature awareness. Most of what they need already exists in your product; they just don’t know about it. Onboarding flows, contextual help, progressive disclosure — these aren’t UX niceties for PUs, they’re the entire activation mechanism.

Hostage User (HU) — the person who has no choice

Hostage Users use your product because their environment requires it. The company adopted you before they joined. The industry standardized on you. Switching would cost more time or money than it would save. They may love or hate the product; that’s not the point. The point is that they can’t leave.

Their feedback is the most distorted. They’ve internalized resentment that has nothing to do with your specific decisions. They’ll complain about features that aren’t broken because the friction of unrelated processes has accumulated into a generalized hostility. They’ll also defend features that are broken, because they’ve built workflows around the brokenness.

The positive case for Hostage Users: their existence proves you’ve achieved a degree of standardization that smaller competitors can’t easily disrupt. Everyone in their organization speaks the same product-language. The workflow is integrated. New hires inherit the system.

The negative case: any meaningful change you make will face resistance from this group, regardless of whether the change is an improvement. The cost of relearning is real and resented. Hostage Users are the reason every “we’re updating the UI” announcement triggers a small revolt.

The categories aren’t static

This is the part I most often skipped when I first started using the taxonomy. People move between categories. The same person can be a Hostage User at work and a First-Level User at home with the same product. A Passive User can become a First-Level User over six months of good experience. A First-Level User can decay into a Second-Level User after a year of unfixed bugs.

In a single team using a single product, you’ll find all four categories simultaneously, distributed across different members for different reasons. The taxonomy isn’t a label you stamp on a person — it’s a snapshot of a person’s current relationship with a product, and the relationship changes with time.

What this changes about user research

The biggest mistake I see in user research recruitment is single-type sampling. Test only with First-Level Users and everything looks fine. Test only with Hostage Users and everything looks broken. Test only with Second-Level Users and you’ll get an endless list of competitive table-stakes you don’t have time to build.

The mix matters. My current rule of thumb, after years of getting this wrong:

  • ~30–40% First-Level Users — for aspirational signal
  • ~30–40% Second-Level Users — for reality checks and churn diagnosis
  • ~20–30% Passive Users — for activation and discoverability
  • ~10% Hostage Users — for understanding constraint, not for prioritization

The exact proportions depend on the product’s stage. Early products have almost no Hostage Users (nothing to be hostage to yet). Mature B2B platforms have too many to ignore. Adjust accordingly. The principle — sample across all four — is invariant.

Where each type concentrates

After working across trading platforms, institutional treasury systems, and industrial monitoring, I’ve noticed each of these substrates skews differently:

Trading platforms are dense with Second-Level Users. The space is competitive, switching cost is low, and traders carry loyalty to outcomes (PnL) rather than to tools. Most of the people using your platform could have picked someone else, and they’ll add a second tool the moment one solves something better. Designing here means treating SLU feedback as the dominant signal.

Institutional treasury systems are dense with Hostage Users. The vendor decision was made by procurement two years ago; the operators have been navigating the consequences ever since. Resistance to change is high; standardization is the asset. Designing here means budgeting heavily for change management around any meaningful UI shift.

Industrial monitoring platforms skew First-Level User at the buyer level (the person who selected the platform was solving a specific operational pain) and Hostage User at the operator level (technicians inherit whatever the buyer chose). The split is structural, not accidental. Designing for these systems means designing two products in one — the buyer’s narrative and the operator’s daily reality.

Different substrates, same four categories, different distributions. The taxonomy isn’t a generic framework; it’s a lens you point at a specific product to understand which kind of work each of its users is doing.

The summary I wish I’d had in 2021

A user is not a category. A user is a person whose relationship with your product is a snapshot of how they arrived at it, what alternatives they had, and what their environment will let them do next. Limiting the concept to “anyone who uses a product” is a category mistake that costs you research signal, prioritization clarity, and design accuracy.

The four kinds of user — First-Level, Second-Level, Passive, Hostage — aren’t exhaustive. People are more complicated than four boxes. But four boxes is more than one, and “user” is one box, and that’s the upgrade.