SfSkills Domains Docs GitHub

Home / admin / persona-and-journey-mapping-sf

persona-and-journey-mapping-sf

Build Salesforce-anchored personas and journey maps where every persona ties to a Permission Set Group, primary record types, list views, dashboards, automation, and a measured mobile/desktop posture, and journeys walk each task end-to-end with friction tags that drive UX decisions.

Open the skill folder on GitHub

Persona And Journey Mapping (Salesforce-Anchored)

This skill activates when an admin, BA, or architect needs to define who actually uses the org and how, in a way that drives concrete Salesforce configuration decisions rather than abstract UX deliverables. Every persona must anchor to org artifacts the platform exposes — Permission Set Groups, record types, list views, dashboards, automation — and every journey must walk a real task with measured friction so the output feeds downstream auditing and design agents.

Before Starting

Gather this context before producing any persona artifact:

Core Concepts

Persona = User × Org Artifacts

A Salesforce-anchored persona is the join between a user population and the concrete artifacts the platform uses to constrain and serve them. The five anchors are non-negotiable: PSG (what they can do), record types (what they work on), list views (what they see), dashboards (how they measure success), automation (what fires for them). A persona missing any anchor cannot drive a configuration decision.

Mobile vs Desktop Posture

Salesforce mobile (the Salesforce app) and Lightning Experience desktop are different products with different UX rules: mobile favors Compact Layouts, mobile-only Quick Actions, and brief related-list summaries; desktop favors Dynamic Forms, multi-tab record pages, and dense related lists. The mobile_pct / desktop_pct split — measured, not guessed — is what tells you which surface to optimize. A 70% mobile field rep persona and a 95% desktop SDR persona need very different record pages even on the same object.

Journey Map vs Process Flow

A journey map is persona-first: one persona, one task, every step they take, with friction tagged. A process flow is system-first: the sequence of system events regardless of who triggers them. Journey maps drive UX decisions (Dynamic Forms, Quick Actions, page redesign, path); process flows drive automation decisions (Flow vs Apex, callouts, approvals). Do not conflate them. If you find yourself describing a callout, you are writing a process flow — stop and switch artifacts (admin/process-flow-as-is-to-be).

Friction Taxonomy (Fixed Enum)

Every friction point must be tagged from this enum so downstream agents can route work:

Friction TagMeaningTypical Fix
cognitive_loadToo many fields, sections, or related lists in view at onceDynamic Forms, conditional visibility, page redesign
click_countTask takes more navigation clicks than necessaryQuick Action, Path step, list view inline edit, related list tuning
mode_switchForces user from mobile→desktop or app→browser mid-taskMobile-friendly Quick Action, mobile-aware Lightning page, offline-capable LWC
data_inputRepeated typing, no defaults, no picklist where appropriateDefault field values, validation rule with a useful message, picklist conversion
searchUser cannot find a record, list view, or related itemList view tuning, search layout, pinned list views, Einstein Search config

Common Patterns

Pattern: PSG-First Persona Sketch

When to use: brand-new persona work, or when an existing persona doc has drifted from org reality.

How it works: start from the PSG (or planned PSG) — extract assigned object permissions, record types, layouts, and tabs. Bind that to a named persona. Every claim in the persona profile must trace back to a PSG, a record type, a list view, a dashboard, or an automation in the org.

Why not the alternative: title-based personas ("Sales Rep") describe a stereotype, not a user. They drift, they collide, and they cannot be audited.

Pattern: One Task Per Journey Map

When to use: every primary persona task — captured one task per journey artifact, not bundled.

How it works: the journey artifact has a single task (e.g. "Log a visit", "Triage an inbound case", "Update opportunity stage to Negotiation"), the frequency (daily / weekly / monthly / quarterly), the steps in order, the friction tag on each problematic step, and the next task the persona moves to (so the journey doesn't end at "saves record").

Why not the alternative: combining tasks into a single map produces a deliverable nobody reads and a friction list nobody can route.

Decision Guidance

SituationRecommended ApproachReason
Asked for personas with no PSG roadmap yetFlag the gap. Do not write personas; write a PSG sketch first.Personas without PSG anchors cannot be audited or kept current.
Asked to map mobile vs desktop and no measurement existsFlag the gap. Pull from Lightning Usage app or EventLogFile, then resume.Inventing mobile_pct corrupts every downstream UX decision.
Persona task ends at "record saved"Extend it — what task does the persona do next, on what surface?A journey that ends at save misses the most common friction (mode switch to next task).
9+ personas in a single phaseReduce to ≤7 by merging adjacent personas.More than 7 personas is noise; signal-to-decision ratio collapses.
Persona references a dashboard nobody can find in the orgRemove or replace with a real dashboardHallucinated artifacts make the persona untrustworthy.
Friction tag does not fit the taxonomyEither re-frame to fit the enum or capture as notesFree-text tags break the routing handoff.
  1. Identify personas from PSG roadmap. Pull the planned (or current) Permission

    Set Groups; one persona per distinct user population the PSGs serve. If a PSG covers two distinct populations with different journeys, split it.

  2. Anchor each persona to org artifacts. Fill the canonical schema:

    psg_assigned, primary_record_types[], primary_list_views[], dashboards[], automation_touched[], and the measured mobile_pct / desktop_pct. No anchor → not a persona.

  3. Build a journey map per primary task. One task per artifact. Record

    frequency, every step in order, friction points tagged from the fixed taxonomy, and the next task the persona transitions to.

  4. Flag friction that needs UI work. cognitive_load, click_count, and

    mode_switch typically route to record-page redesign, Quick Actions, Path, or Dynamic Forms — handed off to lightning-record-page-auditor.

  5. Flag friction that needs automation. data_input and some click_count

    friction routes to Flow, defaults, validation rules, or assignment rules — handed off to the automation agents.

  6. Hand off to downstream agents. Emit the handoff JSON: persona id, anchor

    artifacts, friction backlog, and target agents (lightning-record-page-auditor, list-view-and-search-layout-auditor, path-designer, plus UAT test design which runs each case as a persona).

  7. Revisit per release. Personas drift as PSGs and record types change;

    re-run the anchor check every release train.

Canonical Persona Schema

{
  "persona_id": "outside_sales_rep",
  "name": "Outside Sales Rep",
  "headcount": 42,
  "psg_assigned": "PSG_Sales_Field",
  "primary_record_types": ["Account.Customer", "Opportunity.Field_Deal", "Visit__c.Standard"],
  "primary_list_views": ["My_Open_Opps_This_Week", "Visits_Due_Today"],
  "dashboards": ["Field_Sales_Daily"],
  "mobile_pct": 70,
  "desktop_pct": 30,
  "automation_touched": [
    "Flow:Visit_After_Save",
    "ValidationRule:Opp.Field_Stage_Required_Fields",
    "AssignmentRule:Lead_Field_Territory"
  ]
}

Canonical Journey Schema

{
  "persona_id": "outside_sales_rep",
  "task": "Log a customer visit between meetings",
  "frequency": "daily",
  "steps": [
    {"step": "Open Salesforce mobile app", "surface": "mobile"},
    {"step": "Tap Visits Due Today list view", "surface": "mobile"},
    {"step": "Open visit, tap Log Visit Quick Action", "surface": "mobile"},
    {"step": "Enter notes, attendees, next step", "surface": "mobile", "friction": "data_input"},
    {"step": "Save", "surface": "mobile"},
    {"step": "Move to next visit on list", "surface": "mobile"}
  ],
  "friction_points": [
    {"step_index": 3, "tag": "data_input", "note": "No default for Visit Type; user retypes territory each time"}
  ],
  "desired_outcome": "Visit logged in <60s without leaving the mobile app",
  "next_task": "Drive to next account and repeat"
}

Handoff JSON Shape

{
  "personas": [ /* persona records */ ],
  "journeys": [ /* journey records */ ],
  "friction_backlog": [
    {
      "persona_id": "outside_sales_rep",
      "task": "Log a customer visit between meetings",
      "friction_tag": "data_input",
      "recommended_target": "lightning-record-page-auditor",
      "recommended_intervention": "Default Visit Type from territory; review mobile compact layout"
    }
  ]
}

Review Checklist

Salesforce-Specific Gotchas

  1. PSG drift after release. PSGs change between releases as new objects ship; re-run anchor checks every release train or personas go stale silently.
  2. Mobile usage measurement gaps. Lightning Usage app shows desktop-only by default; you must enable Mobile App usage and EventLogFile UriEvent to get the real split.
  3. List view personalization invisible to admins. Users create personal list views the admin never sees; persona list-view anchors should bias to shared list views or you misread the journey.

Output Artifacts

ArtifactDescription
personas.jsonArray of persona records following the canonical schema.
journeys.jsonArray of journey records, one per persona-task pair.
friction_backlog.jsonRouted friction items with target agent and recommended intervention.
handoff.jsonCombined handoff envelope consumed by downstream auditing agents.

Package files