Behavioral Plan
CanonicalConfidence
Cognitive Load
Medium
Evidence
production validated
Impact
product
Ethical Guardrail
A Behavioral Plan must be written and reviewed before any UI work begins on a new feature.
Design Intent
The most expensive failures in product development are not bugs -- they are features that technically work but nobody uses. A Behavioral Plan prevents this by requiring a narrative map of the user's psychological journey before a single pixel is placed. It forces the team to answer: Who is the actor? What is the target action? Which CREATE gates will they struggle with? What strategy (Cheat, Habit, Conscious Action) fits? What does success look like behaviorally, not just functionally? In an agent-first product, the Behavioral Plan also defines the agent's success criteria: the agent is not done when it completes a task -- it is done when the user has successfully moved through the plan's stages and the behavioral KPIs confirm adoption. Without this artifact, teams build features that demo well but fail in the field.
Psychology Principle
Every feature must begin with a narrative story of how the user progresses from awareness to successful action.
Description
A living document that maps how a user moves from first encounter to habitual use of a feature, using the CREATE funnel as the diagnostic backbone. Written before any UI is designed, it serves as the contract between design intent and implementation. For AI agents, the Behavioral Plan defines success criteria: the agent's job is to move the user through the plan's stages, not just complete a task.
When to use
Before starting UI design on any new feature. This is a pre-design artifact.
Example
Figma design handoff onboarding: map the journey from a designer's first login through their first successful design-to-developer handoff, with specific interventions at each CREATE stage -- Cue (Slack notification when dev marks ready-for-design), Reaction (preview of handoff checklist), Evaluation (time estimate and impact summary), Ability (pre-populated spec fields from Figma auto-inspect), Timing (sprint deadline countdown).
Autonomy Compatibility
Behavioral Objective
Every new feature ships with a validated behavioral map that defines the user's psychological journey from awareness to habitual use.
- Design teams align on the target actor, target action, and strategy before UI work begins
- AI agents have explicit success criteria beyond task completion
- Post-launch measurement is tied to behavioral milestones, not just feature usage counts
Target Actor
role
Product Designer / Product Manager / AI Agent System Designer
environment
Pre-design phase, typically during sprint planning or feature kickoff for product workflows
emotional baseline
Eager to start building but needing a structured framework to channel design energy productively
ai familiarity
medium-to-high (meta-pattern used by builders)
risk tolerance
low -- skipping the plan means shipping a feature without behavioral validation
Execution Model
define_actor
Identify the specific user role, context, emotional state, and constraints. Generic personas are insufficient -- the plan requires the actor's team, experience level, time pressure, and relationship to the target action.
Actor is described generically ('a user') rather than specifically ('a mid-level frontend engineer with 3 years of experience creating their first design handoff spec from a Figma file').
map_journey
Walk through each CREATE funnel stage for this specific actor performing this specific action. At each stage, describe what the user experiences, what could go wrong (failure indicator), and which supporting pattern addresses the failure.
Journey map is generic or skips stages. No failure indicators are identified.
select_strategy
Choose the Three Strategies bucket (Cheat, Habit, or Conscious Action) that fits the target action. Justify the choice based on stakes, frequency, and policy requirements.
No explicit strategy is chosen, or strategy conflicts with the action's policy requirements.
define_kpis
Set behavioral KPIs that measure whether the user is actually progressing through the plan's stages, not just whether the feature is being clicked on.
KPIs measure feature usage (clicks, views) rather than behavioral outcomes (completion, habit formation, deliberation quality).
review_and_commit
Team reviews the Behavioral Plan before any UI work begins. Plan becomes a living document that is updated as user research reveals new insights.
Plan is written but never reviewed, or is abandoned after sprint 1.
Failure Modes
Plan is treated as checkbox compliance rather than genuine design tool
Require specific, testable behavioral predictions in each plan. Plans with generic statements ('users will find it easy') are sent back.
Plan is written but never referenced during implementation
Link plan to sprint tickets. Each ticket references the specific CREATE stage and supporting pattern it implements.
Plan is too detailed, becoming a heavyweight document nobody reads
Limit plan to one page. Use the structured template (actor, action, strategy, CREATE walkthrough, KPIs). No prose beyond what is needed.
Plan does not account for agent behavior, only human UI
Plan template includes 'Agent Role' section defining what the agent does at each CREATE stage and what success looks like for agent-assisted completion.
Agent Decision Protocol
Triggers
- New feature design initiated without a Behavioral Plan
- Agent tasked with recommending a workflow for a new feature
- Post-launch KPIs do not match plan predictions
Escalation Strategy
L1: Classify -- agent drafts a Behavioral Plan using available context (user role, action type, project metadata)
L2: Nudge -- remind design team that no plan exists for a feature entering development
L3: Restructure -- generate plan from CREATE funnel analysis and propose to team for review
L4: Constrain -- block agent-assisted workflow recommendations for features without a validated plan
L5: Yield -- escalate to senior behavioral designer if plan reveals conflicting requirements
Example
Product manager creates ticket for new design handoff feature -> Agent detects no Behavioral Plan exists -> L1 drafts plan: Actor = mid-level designer, Action = complete first handoff spec by sprint deadline, Strategy = Habit (recurring per sprint), CREATE walkthrough identifies Ability as highest-risk stage (designers unfamiliar with spec format) -> L2 notifies design team -> team reviews and refines -> plan becomes the blueprint for sprint work.
Behavioral KPIs
Primary
- % of new features with a completed Behavioral Plan before UI design begins
- Plan prediction accuracy (did the identified failure modes actually occur?)
- Time from plan creation to first user behavioral milestone
Risk
- Features shipped without a Behavioral Plan
- Plan abandonment rate (plans written but never referenced post-kickoff)
Trust
- Team-reported value of Behavioral Plan process (retrospective survey)
- Correlation between plan completeness and feature adoption rate
Behavioral Signals
plan_missing
feature_design_started AND behavioral_plan=null
sprint_ticket_created AND create_stage_reference=null
plan_abandoned
behavioral_plan_created AND plan_referenced_in_tickets=false after 14 days
behavioral_plan_version=1.0 AND feature_version > 2.0 (plan never updated)
plan_shallow
behavioral_plan_actor_description_length < 50 characters
behavioral_plan_failure_indicators_count < 3
Decay Monitoring
Revalidate when
- Team stops writing plans for new features
- Plans are consistently inaccurate in predicting failure modes
- New team members join who have not been trained on the plan process
Decay signals
- Declining plan creation rate across sprints
- Increasing gap between plan predictions and actual user behavior
- Rising feature abandonment rates on features without plans
Pattern Relationships
Requires
Conflicts with