design-protocol 1.0.0

package/skills/dp-journey/references/journey-types.md

@@ -0,0 +1,97 @@
+# Journey Artifact Types — Decision Guide
+
+This reference helps pick the right artifact type for the situation. Source: NNGroup's UX Mapping Methods cheat sheet (Sarah Gibbons) plus related Kaplan, Salazar, and Flaherty articles.
+
+---
+
+## Decision Tree
+
+```
+Is the scope tied to a specific product or service?
+├── No, broader human behavior across providers
+│   ├── Whole-day or whole-life context?
+│   │   ├── Yes → Day-in-the-Life Map
+│   │   └── No  → Experience Map
+│   └──
+└── Yes, specific product/service
+    ├── Do channels/handoffs matter?
+    │   ├── Yes → Omnichannel Journey Map
+    │   └── No  → Continue
+    ├── Do internal operations/backstage matter?
+    │   ├── Yes → Service Blueprint
+    │   └── No  → Customer Journey Map
+    └──
+```
+
+---
+
+## Comparison Matrix
+
+| Method | Perspective | Scope | Chronological? | Tied to product? | Primary output |
+|---|---|---|---|---|---|
+| Customer Journey Map | One actor | One scenario | Yes | Yes | Emotional arc + opportunities |
+| Experience Map | Generic human | Whole domain | Yes | No | Context + upstream opportunities |
+| Day-in-the-Life Map | One actor | Whole day | Yes | No | Context + unmet needs |
+| Service Blueprint | Organization | One service | Yes | Yes | Frontstage/backstage alignment |
+| Omnichannel Journey Map | One actor | Multi-channel journey | Yes | Yes | Channel transitions + gaps |
+
+---
+
+## Current-State vs Future-State vs Day-in-the-Life
+
+Three purposes for a journey map, per Kaplan:
+
+| Variant | Purpose | When to use |
+|---|---|---|
+| **Current-state** | Diagnose how the journey works *today* | Improving an existing experience; aligning on reality; onboarding new team members |
+| **Future-state** | Envision how the journey *should* work | Vision-setting; pitching a North Star; designing something that doesn't exist |
+| **Day-in-the-Life** | Understand the person's *wider context* | Finding new opportunities; pre-product discovery; designing for moments not screens |
+
+**Rule of thumb:** Use current-state to fix. Use future-state to envision. Use day-in-the-life to find.
+
+---
+
+## Examples Per Type
+
+### Customer Journey Map — "First-time SaaS trial signup"
+Actor: IT manager evaluating tools
+Scenario: from email ad click → 14-day trial → purchase decision
+Phases: Discover → Evaluate → Trial → Expand → Decide → Purchase/Abandon
+
+### Experience Map — "Learning a new skill"
+Actor: self-directed adult learner
+Scope: not tied to any one course platform
+Phases: Awaken desire → Explore options → Commit → Practice → Plateau → Apply → Share
+
+### Day-in-the-Life Map — "Remote knowledge worker"
+Actor: mid-career software engineer
+Scope: 6am–11pm weekday
+Swimlanes: activities, tools, emotional state, meeting load, unmet needs
+
+### Service Blueprint — "Home appliance warranty claim"
+Actor: customer with broken dishwasher
+Customer actions: call support → schedule visit → technician arrives → repair done
+Frontstage: phone agent, scheduling app, technician
+Backstage: CRM, parts inventory, dispatch system
+Support: vendor parts supplier, SLA contracts
+
+### Omnichannel Journey Map — "Buy online, pick up in store"
+Actor: working parent
+Channels: web (browse), mobile (pay), email (receipt), SMS (ready-for-pickup), in-store (counter)
+Transitions: 4 channel handoffs, each requiring context persistence
+
+---
+
+## When NOT to Use Journey Mapping
+
+Use something else when:
+
+| Situation | Use instead |
+|---|---|
+| You need to synthesize user research | Empathy map, affinity diagramming |
+| You need to design a specific screen flow | User flow diagram (part of UX) |
+| You need to document information architecture | Sitemap, IA diagram |
+| You need feature requirements | PRD |
+| You need persona detail | Persona document |
+
+Journey maps are for *narrative and alignment*, not for *specification*.

package/skills/dp-journey/references/map-structures.md

@@ -0,0 +1,177 @@
+# Map Structures — Templates Per Artifact Type
+
+Full swimlane templates for each of the five artifact types. Use these as the scaffold when synthesizing research into a draft.
+
+---
+
+## 1. Customer Journey Map — Full Template
+
+### Zone A — The Lens
+```
+Actor: [Persona name] — [one-line description]
+Scenario: [Specific time-bounded scenario with entry and exit points]
+Expectations Entering:
+  1. [What they expect]
+  2. [What they expect]
+  3. [What they expect]
+Goal: [What success looks like from their POV]
+Research basis: [interviews N=X, usability N=Y, analytics source] OR [HYPOTHESIS]
+```
+
+### Zone B — The Experience
+
+**Phase row (top):** 4-7 high-level phases, chronological
+**Standard phase archetypes:**
+- Commerce: Awareness → Consideration → Purchase → Onboarding → Use → Advocacy
+- SaaS: Discover → Evaluate → Trial → Adopt → Expand → Renew/Advocate
+- Service: Trigger → Research → Decide → Engage → Experience → Follow-up
+- Support: Problem → Search → Contact → Diagnose → Resolve → Verify
+
+**Swimlanes (per phase):**
+
+| Swimlane | Prompt |
+|---|---|
+| Actions | What does the actor literally do? |
+| Thoughts | What are they asking themselves? What questions? |
+| Emotions | How do they feel? Plot as 1-5 value |
+| Touchpoints | Which interfaces/channels at this moment? |
+| Pain Points | What friction or frustration occurs here? |
+| Quotes | Verbatim or paraphrased — "..." from research |
+
+**Emotion Curve:** draw as a single line across all phases showing peaks (delight) and valleys (frustration).
+
+### Zone C — The Insights
+
+- **Opportunities** per phase (ranked)
+- **Key Moments of Truth** — where experience succeeds or fails
+- **Ownership Map** — who owns each phase
+- **Metrics** — what to measure to know if the journey improves
+
+---
+
+## 2. Experience Map — Full Template
+
+Same structure as Customer Journey Map but:
+- Actor = generic human (not a customer of any one company)
+- Scenario = life context, not product context
+- Touchpoints = may include competitive/substitute options
+- Opportunities = category-level, not product-level
+
+---
+
+## 3. Day-in-the-Life Map — Full Template
+
+### Header
+```
+Actor: [Persona]
+Time horizon: [6am–11pm / full workday / weekend]
+Context: [Location, role, constraints]
+```
+
+### Timeline Swimlanes
+
+| Swimlane | Prompt |
+|---|---|
+| Time blocks | Hourly or by natural breaks |
+| Activities | What they're doing |
+| Tools used | Apps, devices, services, physical tools |
+| Social context | Alone / with family / with colleagues |
+| Emotional state | Stress level, energy level |
+| Cognitive load | Focused work / reactive / ambient |
+| Unmet needs | What's missing or painful |
+| Opportunity tags | Potential product/service intervention |
+
+---
+
+## 4. Service Blueprint — Full Template
+
+### 5 Layers (top to bottom)
+```
+┌─────────────────────────────────────────────────────────────┐
+│ Physical / Digital Evidence                                  │
+├─────────────────────────────────────────────────────────────┤
+│ Customer Actions                                             │
+│ ══════════════════════════ Line of Interaction ═══════════ │
+│ Frontstage Actions                                           │
+│ ══════════════════════════ Line of Visibility ════════════ │
+│ Backstage Actions                                            │
+│ ══════════════════════ Line of Internal Interaction ══════ │
+│ Support Processes                                            │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### Layer Definitions (NNGroup, Sarah Gibbons)
+
+| Layer | Contents |
+|---|---|
+| **Physical / Digital Evidence** | Props, places, UIs the customer encounters — receipt, signage, app screen, email |
+| **Customer Actions** | Steps, choices, activities the customer performs to reach a goal (this IS the journey row) |
+| **Frontstage Actions** | Actions occurring directly in view of the customer — contact employees or self-service tech |
+| **Backstage Actions** | Steps behind the scenes that support frontstage — kitchen prep, order entry into KDS, CRM lookup |
+| **Support Processes** | Internal systems, third parties, policies, SLAs that enable the layers above |
+
+### Critical Nuance
+A frontstage *employee* can perform a backstage *action*. Example: a waiter typing the order into the kitchen display system is a backstage action even though the waiter is a frontstage employee. The distinction is about visibility of the *action*, not the *role*.
+
+### The 3 Lines
+
+| Line | Separates |
+|---|---|
+| Line of Interaction | Customer Actions ↔ Frontstage Actions |
+| Line of Visibility | Frontstage ↔ Backstage |
+| Line of Internal Interaction | Backstage ↔ Support Processes |
+
+### Building Process (5 steps — Gibbons)
+1. **Find support** — build cross-disciplinary team, establish stakeholder support
+2. **Define the goal** — scope and alignment on why
+3. **Gather research** — from customers, employees, stakeholders
+4. **Map the blueprint** — low-fidelity first
+5. **Refine and distribute** — to high-fidelity, distribute to clients and stakeholders
+
+---
+
+## 5. Omnichannel Journey Map — Full Template
+
+### Additional rows beyond the Customer Journey Map
+
+| Row | Prompt |
+|---|---|
+| **Channel** | web / mobile / email / SMS / phone / in-person / chat / kiosk |
+| **Device** | phone / laptop / tablet / kiosk / POS / voice assistant |
+| **Touchpoint** | channel + device + task composite |
+
+### Channel Transition Markers
+
+At every transition, insert a block:
+
+```
+╔═══════════════════════════════╗
+║ TRANSITION: [From] → [To]    ║
+║ What carries: [context]       ║
+║ What breaks: [failures]       ║
+║ Priority: [H / M / L]         ║
+╚═══════════════════════════════╝
+```
+
+### Channel Inventory Table
+
+| Channel | Role | Strengths Leveraged | Known Limitations |
+|---|---|---|---|
+| Web | Primary research | Deep content, filters, comparison | Large screen assumed |
+| Mobile app | Transactional | Quick actions, notifications, camera | Small screen, attention-fragmented |
+| Email | Async confirmation | Persistent record | One-way, delayed |
+| SMS | Real-time alert | Immediate, high open-rate | 160 chars, no rich media |
+| Phone | High-touch resolution | Human empathy, complex cases | Queue wait, scheduling |
+| In-person | Trust-building, physical | Full sensory, high bandwidth | Geographic limits, hours |
+| Chat (live) | Mid-touch support | Real-time, multitask-compatible | Requires agent availability |
+
+---
+
+## Output Conventions
+
+- Always Zone A (lens), Zone B (experience), Zone C (insights) order
+- Always one actor per map
+- Always chronological left-to-right phases
+- Always emotion as a continuous line, not discrete values
+- Always opportunities ranked (severity × reach × strategic fit)
+- Always a named journey owner in Zone C

package/skills/dp-journey/references/omnichannel-patterns.md

@@ -0,0 +1,208 @@
+# Omnichannel Patterns — Deep Reference
+
+Extended reference for omnichannel journey mapping. Based on NNGroup's 5-component framework (Kim Flaherty), Kim Salazar's touchpoint model, and common cross-channel patterns.
+
+---
+
+## The 5 Components (Verbatim Definitions — NNGroup, Kim Flaherty)
+
+### 1. Consistent
+*"Providing a consistent, cohesive, and familiar experience across all channels."*
+
+**4 consistency dimensions:**
+- **Visual** — brand, typography, color, layout language
+- **Functional** — core capabilities work the same way
+- **Content / Voice** — tone, terminology, information hierarchy
+- **Data / State** — account, cart, preferences are the same everywhere
+
+**Benefits (NNGroup):**
+- Familiarity & confidence — sets expectations
+- Learnability — prior channel experience transfers
+- Efficiency — users complete tasks faster
+- Trust — builds credibility
+
+### 2. Optimized (for context)
+*"Creating individual channel experiences that are best suited for that particular device, channel constraints, and contexts of use."*
+
+**Context variables:**
+- Device (screen size, input modality)
+- Session length (seconds to hours)
+- Attention available (full / fragmented / passive)
+- Environmental constraints (hands-free, one-handed, ambient noise)
+- Permission/privacy context (public space vs. private)
+
+**Principle:** *Consistent what, contextual how.* Keep brand/data/core capability consistent; let UI/interaction/detail adapt to channel.
+
+### 3. Seamless
+*"Making channel transitions as effortless as possible and helping customers pick up where they left off when they switch from one channel to another during a task."*
+
+**Seamlessness requirements:**
+- Persist state across channels (cart, form data, progress)
+- Carry context forward (identity, intent, last action)
+- Minimize re-authentication, re-typing, re-explaining
+- Provide a visible "continue where you left off" affordance
+
+### 4. Orchestrated
+*"Proactively leading customers through their individual journeys with the right personalized interactions and messages at the right time."*
+
+**Orchestration maturity levels:**
+- **Reactive** — respond after user acts (send receipt after purchase)
+- **Scheduled** — planned sequence (onboarding email drip)
+- **Behavioral** — triggered by user signals (cart abandonment email)
+- **Predictive** — engine decides next-best-action based on state + history + context
+
+### 5. Collaborative
+*"Enriching the customer journey by allowing customers to take advantage of multiple channels at the same time to improve the overall user experience."*
+
+**Examples:**
+- Second-screen (TV + mobile companion)
+- Agent phone call + screen-share on web
+- In-store app scanner while physically browsing
+- QR code handoff from print to mobile
+- Voice assistant + screen display
+
+---
+
+## Touchpoint Inventory — How to Build
+
+Per Kim Salazar: **Touchpoint = Channel × Device × Task.**
+
+### Step 1 — Enumerate channels
+List every way the actor can interact with the organization:
+- Web (marketing site, app, logged-in product)
+- Mobile app (iOS, Android)
+- Email
+- SMS
+- Push notification
+- Phone (inbound, outbound)
+- In-person (store, branch, event)
+- Chat (live, chatbot, WhatsApp)
+- Social (DMs, comments)
+- Print (mail, receipt, signage)
+- Kiosk / POS / self-service
+- Voice assistant
+
+### Step 2 — Enumerate devices
+For each channel, which devices support it?
+
+### Step 3 — Enumerate tasks per phase
+For each journey phase, what tasks might the actor attempt?
+
+### Step 4 — Create the inventory grid
+
+| Phase | Channel | Device | Task | Actor goal | Frequency |
+|---|---|---|---|---|---|
+| Discover | Web | Desktop | Browse product pages | Evaluate fit | High |
+| Discover | Mobile app | Phone | Tap ad | Investigate | High |
+| Purchase | Web | Desktop | Enter payment | Complete checkout | High |
+| Purchase | Mobile | Phone | Apple Pay | Complete checkout | Medium |
+| Support | Phone | Phone | Call agent | Resolve issue | Low |
+| Support | Chat | Desktop | Live chat | Resolve issue | Medium |
+
+### Step 5 — Identify gaps
+- Channels the actor uses that the org doesn't support
+- Tasks that only work on one channel but should work on more
+- Handoffs that break context
+
+---
+
+## Channel Transition Patterns
+
+### Pattern A — Research-to-purchase handoff
+User researches on desktop, purchases on mobile, or vice versa.
+
+**Required context persistence:**
+- Cart contents
+- Account identity
+- Viewed items / comparisons
+- Discount codes / referral source
+
+**Common failures:**
+- Cart empties on channel switch
+- Comparison lists don't sync
+- Must re-login
+
+### Pattern B — Digital-to-physical handoff (BOPIS: buy online, pickup in store)
+User buys online, picks up in physical location.
+
+**Required context persistence:**
+- Order ID + contents
+- Identity verification
+- Ready-for-pickup notification
+- Substitution consent (if item unavailable)
+
+**Common failures:**
+- Store employee sees nothing in system
+- Customer has to show email on phone (re-prove order)
+- Substitution not communicated
+
+### Pattern C — Self-service-to-human handoff
+User tries bot/FAQ, escalates to agent.
+
+**Required context persistence:**
+- Conversation history with bot
+- Customer identity
+- Issue category already identified
+- Steps already attempted
+
+**Common failures:**
+- Agent has no chat transcript
+- Customer must re-describe problem from zero
+- Identity re-verification required
+
+### Pattern D — Outbound-to-inbound (email/SMS → web)
+Marketing or service message triggers user to visit web.
+
+**Required context persistence:**
+- Campaign source
+- Offer ID (if promotional)
+- Personalization context
+- Deep link to relevant destination
+
+**Common failures:**
+- Link goes to homepage, not offer
+- Offer not applied automatically
+- Must re-authenticate when message implied authenticated state
+
+### Pattern E — Synchronous multichannel (agent + customer on same screen)
+Agent on phone, customer on web, both navigating together.
+
+**Required real-time sync:**
+- Shared cursor / co-browse
+- Form field sync
+- Mutual viewing of artifacts
+- Agent access to customer's session state
+
+**Common failures:**
+- Agent can't see what customer sees
+- Screen-share tools require customer install
+- Privacy concerns around session visibility
+
+---
+
+## Anti-Patterns
+
+1. **Channel parity** — replicating the desktop UI on mobile instead of optimizing for mobile's context
+2. **Siloed ownership** — each channel owned by a separate team with separate KPIs
+3. **Data-state divergence** — account balance different on web vs. app vs. branch
+4. **Marketing-only omnichannel** — "omnichannel" that's really just "consistent branding across ads"
+5. **Invasive orchestration** — proactive messaging that feels creepy, not helpful
+6. **Forced channel switching** — channel A can't complete the task, user must switch to B
+7. **Happy-path-only design** — channel transitions designed only for success, not recovery
+8. **No identity continuity** — same user treated as stranger when they switch channels
+
+---
+
+## Maturity Self-Assessment
+
+Use this to label the current experience state in the output:
+
+| Tier | Signal |
+|---|---|
+| **Single-channel** | Only one channel exists |
+| **Multichannel** | Multiple channels, each siloed, no shared state or transitions designed |
+| **Cross-channel** | Channels are coordinated (deep links, email → web session) but not fully unified |
+| **Omnichannel** | Unified customer identity, shared state, designed transitions, channel-appropriate UI |
+| **Orchestrated Omnichannel** | All of the above + proactive, personalized next-best-action across channels |
+
+Most organizations believe they are omnichannel and actually operate at the multichannel or cross-channel tier. Stating this honestly in the map is a feature, not a flaw.

package/skills/dp-journey/references/research-methods.md

@@ -0,0 +1,125 @@
+# Research Methods for Journey Mapping
+
+How to fill each swimlane with evidence. Never fabricate. If research is missing, enter hypothesis mode and log the gap.
+
+---
+
+## Swimlane → Method Matrix
+
+| Swimlane | Best method | Acceptable substitutes | Red flags |
+|---|---|---|---|
+| **Actions** | Contextual inquiry, usability testing, analytics funnels | Support ticket review, sales call recordings | Assumptions from product team ("users probably…") |
+| **Thoughts / Mindset** | Semi-structured interviews, think-aloud usability | Diary studies, session replays with narration | Marketing-voice ("delighted users say…") |
+| **Emotions** | Interviews with emotional probes, diary studies | Sentiment analysis of reviews, survey NPS comments | Designer-projected feelings without user validation |
+| **Touchpoints** | Touchpoint inventory workshop + analytics | Support team interviews (they know every channel) | Only listing channels the org *wants* used |
+| **Pain Points** | Support tickets + interviews + churn exits | Session replays, heatmaps, complaint reviews | Only listing polite / survey-compliant feedback |
+| **Opportunities** | Derived from pain points + jobs-to-be-done | Ideation workshops grounded in research | Ideas generated without pain-point anchors |
+| **Backstage (blueprints)** | Employee interviews, process observation | SOP docs, Slack archives | Customer-side assumptions about internal ops |
+
+---
+
+## How Much Research Is Enough?
+
+Per NNGroup's "base it on truth" principle:
+
+### Minimum viable research (for one map)
+- **5-8 user interviews** with people who match the actor persona
+- **Review of 20+ support tickets** from the last 90 days (if applicable)
+- **1 touchpoint inventory workshop** with CS, sales, ops
+- **Analytics pull** for the key funnel (if quantitative exists)
+
+### Stronger basis (for consequential maps)
+- 10-15 interviews across 2-3 segments of the actor persona
+- Diary study (5-10 participants, 1-2 weeks)
+- Usability test of 2-3 scenarios (N=5 minimum, Nielsen)
+- Employee interviews if service blueprint (minimum 3 per team)
+
+### Hypothesis mode triggers
+Enter hypothesis mode if any of these are true:
+- Zero user interviews have been conducted
+- Only indirect data (exec opinions, sales calls, surveys with <20 responses)
+- The actor/persona is aspirational (you don't have any yet)
+- The scenario is future-state and the team hasn't tested a prototype
+
+---
+
+## Interview Question Bank — Journey-Focused
+
+Use these in `/dp:research` interviews to feed journey synthesis:
+
+### Warm-up (establish context)
+- Walk me through the last time you [did the scenario activity]
+- What triggered you to [start the journey]?
+
+### Phase exploration (per phase)
+- What did you do at that point?
+- What were you trying to figure out?
+- What were you thinking when [specific event]?
+- What made you feel [emotion observed]?
+
+### Pain discovery
+- What was the most frustrating part?
+- What almost made you quit?
+- What did you have to work around?
+
+### Expectation check
+- What were you expecting that didn't happen?
+- What surprised you?
+
+### Comparison (for experience maps)
+- How else could you have [achieved the goal]?
+- What else did you try?
+
+### Closure
+- If you could change one thing about that experience, what would it be?
+
+---
+
+## Synthesizing Research Into Swimlanes
+
+### Step 1 — Transcribe and tag
+Tag every research statement with:
+- Phase it belongs to
+- Swimlane (Action / Thought / Emotion / Pain / Opportunity / Touchpoint)
+- Emotional valence (+2 / +1 / 0 / -1 / -2)
+
+### Step 2 — Affinity diagram
+Cluster tagged statements per (phase, swimlane). Patterns emerge where 3+ participants converge.
+
+### Step 3 — Extract the narrative
+For each phase, write 1-3 sentence narrative summarizing the cluster. Attribute quotes.
+
+### Step 4 — Plot emotion curve
+Average emotional valence per phase. Draw the line.
+
+### Step 5 — Derive opportunities
+For each pain point (valence -1 or -2), ask: what would need to change to move this to 0 or +1?
+
+---
+
+## Validating a Journey Map
+
+Post-synthesis, run the map by:
+
+1. **3-5 users who match the actor** — do they recognize themselves?
+2. **2-3 employees who serve this actor** — does it match what they see?
+3. **The journey owner** — are the opportunities aligned with strategy?
+4. **Engineering / ops** — are the backstage claims (if service blueprint) accurate?
+
+Red flag: if validation reveals >20% of the map is wrong, the research basis is too thin — redo with more participants before shipping the map as an alignment tool.
+
+---
+
+## Quantitative Overlays
+
+Once qualitative is solid, overlay quantitative:
+
+| Overlay | What it adds | Source |
+|---|---|---|
+| Drop-off % per phase | Objective severity ranking | Analytics |
+| Time-in-phase | Identifies stuck points | Analytics |
+| Support contact rate per phase | Confirms pain points | Support system |
+| NPS by phase | Confirms emotion curve | Survey |
+| Completion rate | Overall journey health | Analytics |
+
+Quantitative validates qualitative — it does not replace it.