Needs Articulation

Needs Articulation

Overview

Clearly articulate what stakeholders actually need (vs. what they ask for) to guide solution design.

When to Use

• After conducting research with stakeholders
• When stakeholders make feature requests
• During Define phase when framing the problem
• When evaluating ideas against user needs

How to Apply

1. Distinguish Wants from Needs

Users often express solutions, not underlying needs:

User says: "I want a dashboard with 20 widgets" Underlying need: "I need to monitor system health without checking multiple places"

User says: "Add more features like Tool X" Underlying need: "I need to accomplish Y task more efficiently"

2. Ask "Why" Repeatedly

Use the 5 Whys technique:

Request: "Make the button bigger"

• Why? "Hard to click on mobile"
• Why? "I'm wearing gloves in the field"
• Why? "Can't remove gloves, hands get dirty/cold"
• Why? "Environmental conditions require protective equipment"

Need: Design for gloved interaction in field conditions

3. Express as User Needs

Format: [Stakeholder] needs [capability] so they can [outcome]

Examples:

• "Field technicians need offline data access so they can work in low-connectivity areas"
• "Managers need aggregated team metrics so they can identify bottlenecks quickly"
• "New users need clear onboarding so they can become productive without training"

4. Validate Needs

Check with stakeholders:

• Show them your articulation
• Ask if it captures their situation accurately
• Look for recognition: "Yes, that's exactly it!"
• Refine based on feedback

5. Prioritize Needs

Not all needs are equal:

• Critical: Without this, solution fails for this stakeholder
• Important: Significantly impacts experience or efficiency
• Nice-to-have: Improves experience but not essential

6. Document in currentstate.json

Update stakeholder profiles:

{
  "id": "s1",
  "name": "Field Technician",
  "type": "group",
  "needs": [
    "Work effectively in low/no connectivity areas",
    "Quick data capture with minimal interaction",
    "Reliable sync when back online"
  ],
  "pain_points": [
    "Data loss when connection drops",
    "Too many steps to log information",
    "Interface unusable with gloves"
  ]
}

Red Flags

Watch out for:

• Assumed needs: "Users need feature X" (no, they need outcome Y)
• Technology-first: "Users need an API" (no, they need integration)
• One size fits all: Different stakeholders have different needs
• Feature requests: Focus on the problem, not the solution

Tips

• Listen for frustration and workarounds
• Observe behavior, not just stated preferences
• Test your articulation with stakeholders
• Needs are timeless, solutions change
• One pain point may reveal multiple needs
• Prioritize ruthlessly
• Keep updating as you learn more

Converted and distributed by TomeVault — claim your Tome and manage your conversions.