How expanding our design framework to include emotional outcomes creates more human-centered products

The Missing Piece

We've all seen it: requirements defined, user stories mapped, jobs-to-be-done identified. The product launches. It works. Users can accomplish their tasks. Yet adoption lags. Engagement drops.

The jobs-to-be-done framework revolutionized how we think about user needs. But it's incomplete. Between "I need to book a service appointment" and clicking "confirm" lies an entire psychological journey that determines whether the feature actually gets used.

What Are Psychological States?

Psychological states are the emotional and cognitive conditions users need to successfully interact with our products. While jobs-to-be-done asks "what task must be accomplished?", designing for psychological states asks "how must the user feel to accomplish this successfully?"

Three essential states:

Trust - Critical for financial transactions, sharing personal data, or high-stakes decisions. Every interaction either builds or erodes this state.

Confidence - Necessary when navigating unfamiliar territory or making technical choices. A user booking their first car service needs confidence they're selecting the right options.

Calm - Vital during emergencies or high-stress moments. When designing active crash protection systems, I realized even intelligent users might have the mental capacity of a child during a crisis.

These aren't nice-to-haves. They're functional requirements that determine whether features get used at all.

The Framework

1. Identify Required Psychological States

During requirements gathering, ask: "What psychological state must users be in for this feature to succeed?"

For a mobile payment feature, the answer wasn't just "complete transaction." It was "trust the security enough to enter card details" and "feel confident they won't accidentally authorize wrong amounts."

2. Define State-Specific Design Actions

Create design actions for states, just as you create user stories for tasks:

• To instill trust: Display security indicators, show third-party validations, make data usage transparent

• To build confidence: Provide reversible actions, clear progress indicators, optional detailed explanations

• To maintain calm: Minimize cognitive load, use clear language, provide single focused actions

3. Map States to the Journey

Different journey stages require different states:

• Discovery phase: curiosity and openness

• Decision phase: confidence and clarity

• Action phase: focus and ease

• Completion phase: satisfaction and trust

Real-World Application: Service Booking

Standard service booking focuses on jobs: select vehicle, choose dealer, pick date, confirm. But mapping psychological states revealed the real barriers:

1. Initial uncertainty → Required state: Informed confidence
   Design action: Simple indicators, not technical jargon
   
   

2. Dealer selection anxiety → Required state: Trust
   Design action: Transparent pricing, service history, reviews
   
   

3. Commitment hesitation → Required state: Control
   Design action: Obviously easy rescheduling
   
   

4. Post-booking doubt → Required state: Reassurance
   Design action: Immediate confirmation with modification path

The functional journey didn't change. Designing for psychological states at each step addressed the real barriers to completion.

Ethical Considerations

Designing for psychological states is powerful and dangerous.

Low willpower exploitation: Research into mood detection shows we can identify when users have depleted self-control. Using this for safety is ethical. Using it to push impulse purchases crosses the line.

False reassurance: Simplified explanations create comfort, but when truth must be revealed later, trust shatters permanently.

Manufactured urgency: Creating anxiety to drive action may boost conversion, but it's not sustainable.

The principle: Design for psychological states that serve the user's genuine wellbeing, not just business metrics.

Conclusion

Jobs-to-be-done gave us a powerful lens for functional requirements. But humans aren't task-completion machines. We're emotional beings managing anxiety, building trust, and seeking confidence.

A feature that enables task completion but requires users to overcome fear or confusion hasn't truly succeeded. It's created workarounds to its own design flaws.

When we treat psychological states as first-class design requirements alongside functional ones, we create products that don't just work technically, they work humanly.

The real job-to-be-done isn't just booking a service or completing a transaction. It's feeling confident enough to book, trusted enough to transact, and calm enough to proceed.

That's the design challenge worth solving.