Customer Segmentation and Persona Archetypes¶

Summary¶

Introduces segmentation methods while distinguishing primary, secondary, negative, adversarial, international, accessibility, and customer-state archetypes.

Learners will be able to assemble a diverse persona portfolio that represents meaningful market differences.

Concepts Covered¶

This chapter covers the following 20 concepts from the learning graph:

Customer Segmentation
Behavioral Segmentation
Demographic Segmentation
Psychographic Segmentation
Needs-Based Segmentation
Value-Based Segmentation
Customer Archetypes
Primary Persona
Secondary Persona
Negative Persona
Edge-Case Persona
Adversarial Persona
International Persona
Accessibility Persona
Skeptical Customer
Loyal Customer
New Customer
Lapsed Customer
Budget Customer
Premium Customer

Prerequisites¶

This chapter builds on concepts from:

Segmentation Is a Choice About Difference¶

Customer Segmentation divides a broad market or customer population into groups whose differences matter for a decision. The goal is not to create as many groups as possible. It is to find patterns that justify different research questions, experiences, messages, or service choices.

A segment should satisfy three tests. It must be distinguishable using evidence, relevant to the marketing decision, and actionable enough to change what the team does. “People who like good service” fails because nearly everyone could fit and the label suggests no different action.

Segmentation is a model of reality, not reality itself. A customer can belong to several segments, move between them, or behave differently by context. Teams should record how segments were formed, what data supports them, and which people do not fit neatly.

Five segmentation bases are especially useful:

Behavior: what customers do
Demographics: observable or categorized characteristics
Psychographics: attitudes, values, and orientations
Needs: outcomes and conditions required for progress
Value: value customers receive or contribute in a defined relationship

Diagram: Segmentation Basis Classifier¶

Segmentation Basis Classifier

Type: interactive infographic sim-id: segmentation-basis-classifier
Library: p5.js
Status: Specified

Bloom level: Apply (L3)

Bloom verb: classify

Learning objective: Classify customer evidence by segmentation basis and judge whether the proposed difference is decision-relevant and actionable.

Interaction: Learners sort evidence cards into Behavioral, Demographic, Psychographic, Needs-Based, or Value-Based zones. They then select the marketing decision each distinction could inform.

Feedback: Cards can fit more than one basis; feedback explains the strongest interpretation and why mixed bases must remain explicit. Weak cards such as “modern customers” are rejected until operationalized.

Scenarios: Subscription renewal, nonprofit donation, commuter service, and business software. Include contradictory and missing evidence.

Responsive design: Five zones wrap into an accordion on narrow displays. Provide keyboard sorting, text alternatives, and resize handling.

Instructional rationale: Sorting evidence and connecting it to action supports applying rather than merely recalling category names.

Implementation: Responsive p5.js sorting canvas with semantic HTML cards.

Five Ways to Segment¶

Behavioral Segmentation groups customers by actions such as purchase frequency, feature use, channel use, renewal, abandonment, or response to an offer. Behavioral evidence is powerful because it shows what happened, but it does not always reveal why. Two customers can abandon the same page for different reasons.

Demographic Segmentation groups by characteristics such as age range, region, occupation, household structure, or income band. It can support eligibility, access, media planning, or life-stage analysis. It becomes harmful when demographic membership is treated as the cause of behavior without evidence.

Psychographic Segmentation groups by attitudes, values, priorities, interests, or lifestyles. It can explain differences hidden by demographics, yet measurement is difficult and labels can become vague. Use observed language, repeated choices, and validated instruments where appropriate.

Needs-Based Segmentation groups customers by the outcomes or conditions they require. It often maps well to product and message decisions because it asks what progress the customer seeks. Needs can cross demographic boundaries and change by circumstance.

Value-Based Segmentation groups customers by a defined form of value. The company may consider revenue, retention, cost to serve, referrals, or strategic importance. The customer may consider time saved, risk reduced, access gained, or meaning created. State whose value is being measured; otherwise the label hides a one-sided assumption.

The following table summarizes the approaches after they have been defined.

Basis	Strong Input	Useful Decision	Common Failure
Behavioral	Observed actions over time	Journey and intervention design	Assuming action explains motivation
Demographic	Relevant, ethical customer attributes	Access, eligibility, and media reach	Stereotyping behavior
Psychographic	Validated attitudes and values	Framing and message resonance	Vague lifestyle labels
Needs-based	Desired outcomes and constraints	Offer and experience design	Treating every request as a root need
Value-based	Transparent value definition and period	Service and investment choices	Valuing customers only by revenue

Segmentation bases can be combined, but combinations should not become tiny fictional categories unsupported by data. Start with the decision, choose the minimum useful distinctions, and test whether each segment changes an action.

Archetypes Are Testing Roles¶

Customer Archetypes are recurring customer patterns or research roles used to organize persona portfolios. A segment describes a pattern in a population or dataset. An archetype highlights a strategically important perspective. One archetype may represent several segments, and one segment may require multiple archetypes for different scenarios.

A Primary Persona represents the customer pattern most central to the current design decision. Primary does not mean most valuable in every business sense. It means the design must work for this perspective to succeed.

A Secondary Persona represents another important pattern whose needs should be supported without displacing the primary decision. Secondary personas expose trade-offs and prevent an apparently universal design from serving only one workflow.

A Negative Persona represents someone the offer is not designed to serve or a use that should be discouraged. The purpose is focus, not contempt. A negative persona might lack a required use case or seek a prohibited application. Use respectful, evidence-based criteria.

The table below reinforces these roles.

Archetype	Portfolio Function	Governance Question
Primary persona	Anchors the central design decision	Why is this pattern primary now?
Secondary persona	Tests compatibility and trade-offs	Which needs must also be supported?
Negative persona	Clarifies exclusions and misuse	Is exclusion relevant, fair, and disclosed?

Diagram: Persona Portfolio Balancer¶

Persona Portfolio Balancer

Type: microsim sim-id: persona-portfolio-balancer
Library: p5.js
Status: Specified

Bloom level: Create (L6)

Bloom verb: design

Learning objective: Design a persona portfolio that balances primary, secondary, negative, edge-case, adversarial, international, accessibility, and customer-state perspectives.

Controls: Marketing decision selector, portfolio size from three to twelve, evidence coverage toggles, and role assignment. Persona candidate cards show needs, behaviors, context, source quality, and uncertainty.

Visual elements: A coverage matrix compares selected personas across research roles, needs, channels, geography, access conditions, and lifecycle state. No demographic score is treated as diversity by itself.

Feedback: The tool flags redundant personas, unsupported roles, missing critical perspectives, unfair negative-persona criteria, and token diversity that does not change behavior. Learners justify every inclusion.

Responsive and accessible design: Matrix becomes stacked role cards below 750 pixels; provide keyboard selection, patterns, text report, and resize handling.

Instructional rationale: Portfolio construction supports creating because learners synthesize evidence and testing goals into a bounded system.

Implementation: p5.js portfolio workspace with semantic controls and exportable coverage report.

Edge Cases and Adversarial Perspectives¶

An Edge-Case Persona represents an uncommon but relevant condition that can expose a design failure. Examples include extremely low connectivity, shared-device use, unusual account structures, or a deadline outside normal service hours. Edge cases are not automatically low priority; severity and fairness matter alongside frequency.

An Adversarial Persona actively probes claims, assumptions, and failure conditions. “Adversarial” describes the testing role, not a hostile customer identity. The persona might challenge a vague guarantee, seek loopholes, compare fine print, or imagine how a message could be misread.

The Skeptical Customer is an archetype with a higher proof threshold. Skepticism may come from prior disappointment, category risk, unfamiliarity, or a claim that sounds too broad. A skeptical persona should ask for evidence rather than reject everything automatically.

These roles improve stress testing when they remain plausible. An edge case should connect to a real condition. An adversarial perspective should challenge the asset fairly. A skeptic should become more confident when appropriate evidence appears; otherwise the simulation is a caricature.

Use role-specific questions:

Edge case: Under which uncommon condition does the experience fail?
Adversarial: Which claim cannot survive close reading?
Skeptical: What evidence would change the judgment?
Negative: Which use or customer is intentionally outside scope?

Diagram: Stress-Testing Role Lab¶

Stress-Testing Role Lab

Type: interactive infographic sim-id: stress-testing-role-lab
Library: p5.js
Status: Specified

Bloom level: Analyze (L4)

Bloom verb: differentiate

Learning objective: Differentiate negative, edge-case, adversarial, and skeptical persona roles and select the correct role for a research risk.

Interaction: Scenario cards describe a customer, condition, or test goal. Learners assign the appropriate role, identify the evidence required, and write a fair prompt.

Feedback: The tool flags insulting negative personas, implausible edge cases, adversarial prompts that manufacture failure, and skeptics who cannot be persuaded by evidence.

Scenarios: Free-trial misuse, low-bandwidth checkout, exaggerated sustainability claim, hidden renewal term, and unsupported medical claim.

Responsive design: Cards and role zones stack on narrow screens, with keyboard controls and resize events.

Instructional rationale: Comparing closely related testing roles requires analysis of purpose, conditions, and fair behavior.

Implementation: Responsive p5.js classification lab with editable prompt feedback.

International and Accessibility Personas¶

An International Persona represents a customer operating in a particular national, linguistic, regulatory, economic, or cultural context. Translating a domestic persona is not enough. Research should address local payment practices, units, law, channels, trust signals, language variation, infrastructure, and social norms relevant to the task.

International does not mean “nonstandard.” Every persona has a locale. Teams should avoid treating one home market as neutral and all others as special. Use local evidence and reviewers, and distinguish country from culture, language, and individual behavior.

An Accessibility Persona represents task conditions involving access needs, assistive technology, or barriers in the environment. It should support inclusive design without claiming to reproduce lived experience. Relevant details might include keyboard navigation, screen-reader workflow, caption use, cognitive load, motor constraints, color perception, or situational impairment.

Accessibility personas belong in the primary design process, not only an edge-case appendix. A checkout that blocks keyboard users is a core failure. Validate important findings with affected people and qualified accessibility experts.

Ask these quality questions:

Is the international or accessibility context supported by relevant evidence?
Does the profile describe tasks and barriers rather than stereotypes?
Are local and affected reviewers involved?
Does the test include actual technical and content conditions?
Are findings labeled synthetic and scheduled for validation?

Customer-State Archetypes¶

Some archetypes represent the customer's relationship with the brand rather than a stable segment. A Loyal Customer has a pattern of continued choice or advocacy, but loyalty can come from trust, habit, switching cost, rewards, or limited alternatives. The profile should name the mechanism.

A New Customer lacks experience with the brand or product. New customers often need orientation, category language, trust evidence, and clear expectations. They can expose assumptions hidden from experienced users.

A Lapsed Customer previously engaged but stopped purchasing, renewing, or participating. The lapse may result from changed needs, dissatisfaction, a competitor, price, access, or simple inactivity. Do not assume anger; investigate the mechanism.

A Budget Customer gives price and financial predictability strong weight. Budget is a decision condition, not a moral trait. Such a persona may pay more when the total cost, durability, or risk case is stronger.

A Premium Customer is willing and able to pay for particular added value. Premium does not mean careless about price. Expectations for quality, service, status, convenience, or risk reduction may be higher, and disappointment may carry greater reputational cost.

These states can change. A new customer can become loyal; a premium customer can lapse; a budget customer in one category can be premium in another. Preserve context and avoid turning a relationship state into an identity.

Diagram: Customer State Transition Explorer¶

Customer State Transition Explorer

Type: microsim sim-id: customer-state-transition
Library: p5.js
Status: Specified

Bloom level: Understand (L2)

Bloom verb: explain

Learning objective: Explain how experience, value, trust, price, changing needs, and service recovery can move customers among new, loyal, lapsed, budget, and premium states.

Data visibility requirements: Show a customer timeline, the current relationship state, triggering event, evidence considered, and resulting state. Learners predict the transition before revealing it.

Controls: Next/Previous, scenario selector, service-recovery toggle, value change, price change, and trust event. States are treated as overlapping lenses rather than mutually exclusive boxes.

Feedback: The simulator explains why the same event can produce different transitions under different needs and risk. It rejects deterministic demographic rules.

Responsive design: Timeline becomes vertical on narrow screens, with keyboard controls, text alternative, and resize response.

Instructional rationale: Worked transitions support understanding by making state changes and their evidence visible step by step.

Implementation: p5.js step-through timeline with accessible controls and scenario data.

Auditing Segment and Portfolio Quality¶

A segment can look plausible and still fail as a research tool. Before converting segments into personas, inspect separation, stability, coverage, actionability, and fairness. Separation asks whether the groups differ on evidence relevant to the decision. Stability asks whether the distinction persists long enough to guide an action. Coverage asks who remains unrepresented. Actionability asks whether the team would actually change an asset, experience, or study because of the difference. Fairness asks whether the distinction creates unjustified exclusion or harm.

Run the same audit on the portfolio. A balanced portfolio does not contain equal numbers from every category. It contains enough contrasting perspectives to expose the decision's important opportunities and risks. One well-supported accessibility persona may reveal more than five weak lifestyle personas. An adversarial persona can expose a claim failure that several friendly primary personas miss.

Watch for these warning signs:

Segment names describe personality but not evidence or behavior.
Several personas differ only in names, ages, or stock-photo biographies.
Every persona responds in the direction the marketing team hoped.
International and accessibility perspectives appear only after the main design is complete.
A negative persona encodes an undesirable demographic rather than an out-of-scope use.
Budget and premium labels ignore total value, risk, and category context.
Loyal customers are assumed to approve every message.
Lapsed customers are assumed to be angry without research.
Edge cases are dismissed by frequency without considering severity.

Finally, record a removal rule. A persona should leave the portfolio when its evidence is obsolete, its represented difference no longer changes a decision, or another profile covers the same role more credibly. Versioning the portfolio prevents old assumptions from becoming permanent organizational folklore.

Worked Example: Building a Campaign Portfolio¶

A regional bank wants to test a new small-business account campaign. The decision is whether the campaign explains value and trust across acquisition and retention situations. The team begins with needs-based and behavioral evidence rather than job-title stereotypes.

The primary persona is a new business owner who needs predictable fees and guided setup. A secondary persona is an experienced operations manager comparing integration and approval requirements. A negative persona represents a business seeking unsupported high-risk transactions that the account is not designed to serve; exclusion is tied to product scope, not personal worth.

An edge-case persona operates with intermittent connectivity. An adversarial persona tests whether “no hidden fees” survives close reading. A skeptical customer wants regulatory and security evidence. International context is limited to one supported cross-border payment scenario reviewed by a local expert. An accessibility persona tests keyboard-only onboarding and document clarity.

The portfolio also includes loyal, new, and lapsed relationship states. Budget and premium lenses are applied to decision criteria rather than treated as fixed identities. The coverage audit reveals that several personas differ in biography but share the same behavior; the team removes duplicates and invests in stronger evidence for the remaining roles.

Practice: Design a Persona Portfolio¶

Choose a campaign or customer journey and complete the following steps.

State the decision and available segmentation evidence.
Compare behavioral, demographic, psychographic, needs-based, and value-based bases.
Select the minimum useful segmentation approach.
Choose a primary and at least one secondary persona.
Define any fair, relevant negative persona.
Add an evidence-grounded edge-case, adversarial, and skeptical role.
Include international and accessibility perspectives where the decision requires them.
Consider loyal, new, lapsed, budget, and premium states.
Remove redundant personas whose differences do not change behavior.
Record evidence gaps and real-customer validation needs.

How many personas should a portfolio contain?

Use the smallest set that covers materially different needs, behaviors, contexts, risks, and testing roles. More personas can create an illusion of coverage while repeating the same assumptions.

Key Takeaways¶

Segmentation identifies decision-relevant differences; it does not permanently sort people.
Behavioral, demographic, psychographic, needs-based, and value-based segmentation answer different questions.
Archetypes organize testing roles and should remain grounded in evidence.
Primary and secondary personas express design priority; negative personas clarify fair exclusions.
Edge-case, adversarial, and skeptical roles reveal different failure modes.
International and accessibility personas require local or affected evidence and validation.
Loyal, new, lapsed, budget, and premium archetypes describe contextual relationship states, not fixed identities.
A strong portfolio maximizes meaningful coverage and minimizes redundant fictional detail.

Review Questions¶

What makes a segment actionable?
How does needs-based segmentation differ from psychographic segmentation?
Why is an archetype not identical to a market segment?
How do edge-case, adversarial, skeptical, and negative personas differ?
Why is translation insufficient for an international persona?
When should an accessibility persona be treated as primary rather than exceptional?
Why can a premium customer still be price sensitive?

See Annotated References