Skip to content

Persona Motivations, Behaviors, and Evidence

Summary

Extends personas with emotional and functional needs, buying behavior, decision criteria, channels, scenarios, evidence bases, specificity, and completeness.

Learners will be able to connect persona behavior to evidence and concrete purchase or communication contexts.

Concepts Covered

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

  1. Emotional Drivers
  2. Functional Needs
  3. Social Needs
  4. Buying Behaviors
  5. Purchase Triggers
  6. Purchase Barriers
  7. Decision Criteria
  8. Information Needs
  9. Media Habits
  10. Channel Preferences
  11. Technology Comfort
  12. Price Sensitivity
  13. Risk Tolerance
  14. Brand Loyalty
  15. Trust Disposition
  16. Persona Quote
  17. Persona Scenario
  18. Persona Evidence Base
  19. Persona Specificity
  20. Persona Completeness

Prerequisites

This chapter builds on concepts from:


From Description to Decision Logic

A persona becomes useful when it can explain a decision. Demographics and narrative provide context, but marketers need to understand what the customer is trying to accomplish, what could block progress, and which evidence could change the choice. This chapter builds that decision logic without pretending that people behave like simple formulas.

Emotional Drivers are feelings or desired emotional states that energize or shape action. A customer may seek confidence, relief, belonging, control, safety, or recognition. An emotional driver is not a permanent personality trait. It emerges in a situation and can conflict with other drivers. A buyer can feel excited by innovation and anxious about implementation at the same time.

Functional Needs are practical requirements for completing a task or achieving an outcome. Examples include comparing total cost, integrating a tool, finding an accessible route, or completing a purchase before a deadline. Functional needs are often visible in workflows and behavior.

Social Needs concern relationships, status, belonging, approval, responsibility, or the effect of a choice on others. A manager may need a solution the team will accept. A parent may need a plan that coordinates several people. A buyer may need evidence that can withstand executive review.

These need types interact. A transparent implementation plan can meet a functional need for scheduling, an emotional need for confidence, and a social need to protect the team from disruption. Persona design should preserve those connections rather than listing needs as unrelated tags.

Need Type Core Question Example Evidence
Emotional driver How does the customer want to feel or avoid feeling? Repeated emotional language tied to a situation
Functional need What must work or be accomplished? Tasks, failures, workarounds, and outcome criteria
Social need Which people, roles, or norms shape the choice? Approval paths, responsibilities, group consequences

Diagram: Need and Driver Trade-Off Map

Need and Driver Trade-Off Map

Type: graph-model sim-id: need-driver-tradeoff-map
Library: vis-network
Status: Specified

Bloom level: Analyze (L4)

Bloom verb: organize

Learning objective: Organize emotional drivers, functional needs, and social needs into a causal network that explains a persona's competing priorities.

Node types: Goal, Emotional Driver, Functional Need, Social Need, Constraint, Marketing Claim, and Evidence. Properties show source and confidence.

Edges: SUPPORTS, CONFLICTS_WITH, REQUIRES, CONSTRAINED_BY, ADDRESSED_BY, and GROUNDED_IN. Every node and edge reveals a definition and example when selected.

Interaction: Learners build a network for a purchase scenario, then change time pressure or stakeholder involvement. The tool highlights which needs become more important and asks the learner to explain why.

Feedback: Disconnected claims and unsupported needs are flagged. A balance panel shows tensions without reducing them to one score.

Responsive design: Force-directed network with zoom, drag, keyboard navigation, a text alternative, and resize handling.

Instructional rationale: Relationship construction supports analysis because the learner must explain how different need types reinforce or conflict with one another.

Implementation: vis-network model editor with accessible side panel and JSON export.

Buying Behavior Is a Process

Buying Behaviors are observable actions customers take while recognizing, researching, comparing, purchasing, adopting, or renewing a solution. Examples include seeking peer recommendations, opening a pricing calculator, downloading a guide, abandoning a form, requesting a trial, or delaying approval.

Behavior should not be confused with intention. A person can say price matters most and repeatedly choose the easiest option. Both statements are evidence, but observed action and reported intention have different status. A persona should preserve that difference.

Purchase Triggers are events or conditions that make a decision active now. A contract renewal, service failure, new regulation, life event, leadership change, budget cycle, or competitor move can create urgency. A trigger is not the same as a motivation: the trigger starts the process, while motivation explains why progress matters.

Purchase Barriers are obstacles that delay, prevent, or redirect a decision. Barriers include unclear value, high switching cost, missing trust, lack of authority, limited cash, implementation risk, inaccessible design, or the effort of comparing alternatives. A barrier may be real, perceived, or both; marketing must not dismiss a perceived risk merely because the product team believes it is unlikely.

Decision Criteria are the standards used to compare options. Criteria can be required thresholds, such as compatibility with an existing system, or relative preferences, such as easier setup. Strong persona profiles distinguish stated criteria from inferred criteria and note how criteria change across the journey.

A simplified buying sequence looks like this:

  1. A trigger makes the status quo difficult or an opportunity timely.
  2. The customer frames the problem using available language and beliefs.
  3. Information is gathered from preferred channels and trusted people.
  4. Options are screened against required criteria.
  5. Barriers create delay, rejection, or a search for reassurance.
  6. A choice is made, deferred, delegated, or abandoned.
  7. Experience after purchase changes future loyalty and trust.

Diagram: Trigger-to-Decision Journey Simulator

Trigger-to-Decision Journey Simulator

Type: microsim sim-id: trigger-decision-journey
Library: p5.js
Status: Specified

Bloom level: Apply (L3)

Bloom verb: demonstrate

Learning objective: Demonstrate how purchase triggers, barriers, decision criteria, evidence, and stakeholder approval alter a buying path.

Controls: Trigger selector, barrier-strength sliders, criterion-priority controls, available evidence toggles, and stakeholder approval status. Defaults model a moderate-risk software purchase.

Visual elements: A branching journey from inactive need to research, shortlist, trial, approval, purchase, defer, or reject. The current path is highlighted and every branch displays the condition that caused it.

Interaction: Learners predict the next state before changing a parameter. The simulator explains why a barrier blocks progress or why evidence satisfies a criterion. It avoids claiming to predict real conversion rates.

Accessibility and responsiveness: Use HTML controls, a text path summary, patterned states, keyboard access, and vertical layout on narrow screens.

Instructional rationale: Parameter exploration supports applying by requiring learners to use decision concepts in unfamiliar scenarios.

Implementation: p5.js state diagram with deterministic teaching rules and scenario JSON.

Information and Channel Behavior

Information Needs are the facts, explanations, comparisons, and proof a customer requires to make progress. They can include price, compatibility, risk, instructions, social proof, terms, evidence, or expected outcomes. Information needs should be connected to a decision criterion or uncertainty; otherwise a profile can become an indiscriminate wish list.

Media Habits are recurring patterns in how a person encounters and uses information. They include when and why someone reads newsletters, watches demonstrations, searches forums, listens to podcasts, or asks a professional community. Habits describe repeated practice, not an age-based stereotype.

Channel Preferences are relative choices among communication or service channels. A customer may prefer chat for a quick factual question and a scheduled call for a high-risk decision. Preferences depend on task, accessibility, urgency, privacy, and the quality of each channel.

Technology Comfort describes confidence and experience with relevant technologies. It should be task-specific. Someone may be skilled with mobile banking and uncomfortable configuring business automation. Replace labels such as “tech savvy” with evidence: tasks completed independently, learning strategies, prior tools, and conditions requiring support.

The following planning table summarizes those distinctions.

Persona Field Weak Entry Stronger Evidence-Grounded Entry
Information need Wants details Needs total three-year cost before requesting approval
Media habit Uses social media Checks peer community discussions during vendor research
Channel preference Prefers email Uses email for records and chat for time-sensitive setup questions
Technology comfort Not technical Can configure templates but needs guided data migration

Diagram: Information and Channel Fit Lab

Information and Channel Fit Lab

Type: interactive infographic sim-id: information-channel-fit
Library: p5.js
Status: Specified

Bloom level: Apply (L3)

Bloom verb: use

Learning objective: Use persona information needs, media habits, channel preferences, technology comfort, context, and accessibility requirements to choose an appropriate communication path.

Layout: A matrix with journey stages as columns and information tasks as rows. Message cards and channel cards sit in a tray.

Interaction: Learners place a message and channel at each stage for a selected persona. Feedback explains mismatches, such as using a public social channel for a private account issue or a long video for an urgent factual check.

Controls: Persona selector, journey stage, urgency, privacy level, device, and accessibility need. Compare mode shows two defensible channel plans.

Responsive design: Matrix becomes an accordion on narrow displays, with keyboard placement and resize handling.

Instructional rationale: Scenario-based placement supports applying because channel fit must be reasoned from context rather than memorized.

Implementation: Responsive p5.js matrix with accessible DOM cards.

Price, Risk, Loyalty, and Trust

Price Sensitivity is the degree to which price differences affect a choice. It depends on budget, perceived value, alternatives, timing, payment structure, switching cost, and who pays. A price-sensitive customer is not simply “cheap.” The same person may accept a premium for reduced risk or reject a small fee when value is unclear.

Risk Tolerance is willingness and capacity to accept uncertain outcomes. Risk may be financial, operational, social, privacy-related, or reputational. Tolerance changes with stakes and reversibility. A marketer testing a draft headline can accept more uncertainty than a health service publishing a claim about patient outcomes.

Brand Loyalty is a tendency to continue choosing or supporting a brand. Loyalty can arise from satisfaction, habit, switching cost, identity, trust, rewards, or lack of alternatives. A loyal customer may still criticize a campaign strongly because expectations are higher.

Trust Disposition is a general tendency to extend or withhold trust under particular conditions. It is not blind optimism or cynicism. In a persona, trust disposition should be expressed through proof thresholds, prior experiences, authority cues, transparency needs, and reactions to uncertainty.

These factors interact. A risk-averse buyer may accept a higher price from a trusted brand. A loyal customer may tolerate one service failure but react sharply to concealment. A low-cost offer may increase suspicion if the persona believes quality requires visible investment.

Quotes and Scenarios

A Persona Quote is a short synthetic statement that captures the persona's decision logic or language. It should be traceable to research patterns and marked synthetic. Quotes are memory aids, not fabricated customer testimony. Avoid clever slogans that make the persona entertaining but less accurate.

A useful quote exposes a tension: “I can pay more for fewer emergencies, but I need proof that migration will not create one.” It connects price sensitivity, risk tolerance, and an information need. A weak quote—“I just want things to be easy”—could fit almost anyone.

A Persona Scenario places the profile in a specific situation with trigger, task, context, asset, constraints, and stakes. Scenarios are necessary because behavior changes across situations. A scenario should state what the persona knows and avoid secretly providing information other personas do not receive.

A scenario template can include:

  • Trigger and current problem
  • Goal for this interaction
  • Asset or experience presented
  • Channel, device, and setting
  • Time, budget, authority, and accessibility constraints
  • Decision criteria and required evidence
  • Relevant prior experience
  • Possible actions and consequences

Evidence, Specificity, and Completeness

The Persona Evidence Base is the collection of sources supporting the profile. It can include interviews, surveys, analytics, observations, support records, market research, or explicitly labeled expert assumptions. The evidence base should record dates, sample boundaries, source quality, and contradictory findings.

Persona Specificity is the level of detail that makes a profile useful for its purpose. Specificity improves action when it clarifies conditions or criteria. False specificity adds exact ages, incomes, percentages, or quotations without evidence. The best level is precise enough to constrain behavior and broad enough to represent a meaningful pattern.

Persona Completeness is fitness for the intended use. A profile is complete when it contains the fields needed to perform the task, marks uncertainty, and passes quality review. Completeness does not mean every template field is filled. “Not relevant” and “unknown—requires research” are often higher-quality entries than invention.

Use a completion audit:

  1. Purpose and excluded uses are explicit.
  2. Context and scenario are sufficiently concrete.
  3. Goals, needs, motivations, triggers, barriers, and criteria connect.
  4. Channel and information behavior fit the scenario.
  5. Price, risk, loyalty, and trust fields have evidence or uncertainty labels.
  6. Quotes are synthetic, representative, and disclosed.
  7. Sources and contradictions are preserved.
  8. Detail is relevant rather than decorative.
  9. Sensitive fields pass privacy and fairness review.
  10. A reviewer can explain why the persona may respond as simulated.

Diagram: Persona Completeness Auditor

Persona Completeness Auditor

Type: microsim sim-id: persona-completeness-auditor
Library: p5.js
Status: Specified

Bloom level: Evaluate (L5)

Bloom verb: assess

Learning objective: Assess a persona for evidence quality, causal coherence, relevant specificity, privacy, and completeness for a stated use.

Controls: Purpose selector, profile-field checklist, source-status toggles, contradiction flag, sensitivity flag, and scenario completeness controls.

Visual elements: A transparent radar-style quality view with axes for Purpose Fit, Evidence, Decision Logic, Scenario, Safety, and Uncertainty. Scores reveal criteria and never hide missing information behind one total.

Interaction: Learners audit two profiles, revise weak fields, and compare improvements. The tool rewards removal of irrelevant fictional detail as well as addition of necessary evidence.

Feedback: Every warning links to the exact field and explains whether to source, revise, remove, narrow, or mark unknown.

Responsive and accessible design: Use labeled HTML controls, a table alternative, patterns, keyboard access, and resize events.

Instructional rationale: Rubric-based revision supports evaluation by requiring judgments about fitness for purpose rather than profile length.

Implementation: p5.js quality visualization with semantic form controls and exportable audit report.

Worked Example: Choosing a Home-Energy Plan

A utility wants to compare messages for a time-of-use electricity plan. The persona is a renter who can shift some appliance use but cannot modify the building. The trigger is a recent bill increase. The functional need is to understand likely savings; the emotional driver is regaining control; the social need is coordinating schedules with a housemate.

Buying behavior includes comparing two plans, checking a neighborhood forum, and opening the rate calculator. Decision criteria are total expected cost, schedule feasibility, and the absence of surprise penalties. Information needs include peak hours, calculation examples, and what happens during unusual weather.

The persona uses a phone for early research and a laptop for the calculator. Technology comfort is moderate and task-specific. Price sensitivity is high because the budget is fixed, but risk tolerance is lower than price sensitivity: uncertain savings can make the existing plan preferable. Brand loyalty is weak after billing confusion, and trust depends on transparent examples.

The synthetic quote is: “Show me a normal month and a difficult month; I do not want the best-case number.” The scenario specifies an evening comparison with a bill nearby and a renewal deadline in one week. The evidence base combines interviews, calculator analytics, support themes, and labeled assumptions.

This profile is complete for evaluating plan explanations. It is not complete for predicting adoption across all renters. Its specificity constrains the simulation without inventing a false population statistic.

Practice: Complete a Persona Decision Model

Using a persona from Chapter 5, add the following layers.

  1. One emotional driver, functional need, and social need
  2. Two observed or reported buying behaviors
  3. A purchase trigger and at least two barriers
  4. Three decision criteria and their required evidence
  5. Information needs, media habits, and context-dependent channel preferences
  6. Task-specific technology comfort
  7. Price sensitivity, risk tolerance, brand loyalty, and trust disposition
  8. One disclosed synthetic quote
  9. A concrete scenario with equal information conditions
  10. Evidence status for every field
  11. A specificity and completeness audit
Should every field be highly specific?

No. Specificity should constrain decisions where evidence supports it. An exact unsupported number is worse than an honest range, a qualitative pattern, or an explicit unknown.

Key Takeaways

  • Emotional drivers, functional needs, and social needs explain different but connected forms of progress.
  • Buying behaviors are actions; triggers activate a decision; barriers block it; criteria compare options.
  • Information needs, media habits, channels, and technology comfort depend on task and context.
  • Price sensitivity, risk tolerance, loyalty, and trust interact rather than operating as fixed scores.
  • Persona quotes are disclosed synthetic memory aids, not customer testimony.
  • Scenarios specify the conditions under which a persona acts.
  • Evidence bases preserve sources and contradictions; specificity must remain relevant; completeness means fitness for purpose.

Review Questions

  1. How do emotional, functional, and social needs differ?
  2. What separates a purchase trigger from a motivation?
  3. Why should technology comfort be task-specific?
  4. How can risk tolerance change the effect of price sensitivity?
  5. What makes a persona quote responsible and useful?
  6. Why is “unknown” sometimes a sign of persona completeness?
  7. How should a team decide whether persona detail is specific enough?

See Annotated References