HKSM

A human-centered, iterative technique that uses empathy, ideation, prototyping, and testing to discover and refine requirements. It helps teams frame the right problem, explore options, and validate what users truly need before locking down scope.

Key Points

• Centers on users and their real-world context, not just stated requests.
• Alternates between divergent thinking (exploring many ideas) and convergent thinking (choosing and refining).
• Emphasizes fast, low-cost experiments to learn early and reduce rework.
• Relies on visual artifacts such as empathy maps, journey maps, and sketches.
• Works best in facilitated workshops with cross-functional stakeholders.
• Feeds prioritized, testable requirements into the backlog or requirements repository.
• Complements, not replaces, analysis and validation techniques.

Purpose of Analysis

Use this technique to expose latent needs, clarify the problem, and align stakeholders on value before specifying detailed requirements.

• Transform observations into actionable insights and opportunity areas.
• Reduce ambiguity and assumption risk by testing early concepts with users.
• Link user outcomes to business objectives to guide prioritization.
• Produce clear acceptance criteria informed by real usage scenarios.

Method Steps

• Empathize: Interview, observe, and shadow users; capture pain points, motivations, and environmental constraints.
• Define: Synthesize findings into problem statements and “How might we” prompts; map the current journey and identify breakpoints.
• Ideate: Run time-boxed brainstorming using techniques like SCAMPER and Crazy 8s; encourage quantity before quality.
• Prototype: Build low-fidelity sketches, wireframes, paper mockups, or simple click-throughs; keep them quick and disposable.
• Test: Conduct short user walkthroughs and usability checks; capture reactions, confusion points, and improvement ideas, then iterate.
• Converge: Select concepts that best meet user needs and business goals; translate them into user stories and acceptance criteria.

Inputs Needed

• Stakeholder list, personas, or initial user segments.
• Business goals, value metrics, and key constraints (budget, timeline, policy, compliance).
• Existing process maps, service tickets, analytics, and customer feedback.
• Initial assumptions, risks, and known technical/platform capabilities.
• Access to users or user proxies for interviews and testing sessions.

Outputs Produced

• Empathy maps, journey maps, and “How might we” statements.
• Defined problem statements and prioritized opportunity areas.
• Sketches, wireframes, paper prototypes, and test notes.
• User stories with acceptance criteria and example scenarios.
• Validated and refined requirements, ready for backlog prioritization.
• Updates to the requirements traceability and assumptions log.

Interpretation Tips

• Look for patterns across users rather than one-off comments.
• Separate symptoms from root causes; confirm with a quick test or second source.
• Translate insights into testable statements and measurable acceptance criteria.
• Balance desirability (user), feasibility (tech), and viability (business) before committing.
• Link outputs to scope elements and maintain traceability to user needs.

Example

A team improving an internal ticketing tool observes support agents across shifts. They map the journey and find repeated delays when categorizing tickets.

• They define the challenge: “How might we reduce classification time without hurting accuracy?”.
• They ideate options and prototype a guided form with smart defaults.
• Five agents test a paper mockup; confusion around labels triggers quick changes.
• The team writes user stories with acceptance criteria for auto-suggestions and validation rules, then prioritizes them in the backlog.

Pitfalls

• Jumping to a favorite solution before validating the real problem.
• Over-polishing prototypes, slowing learning and inviting sunk-cost bias.
• Testing with internal staff only and missing real user context.
• Failing to capture decisions and trace them to requirements and scope.
• Ignoring nonfunctional needs like security, accessibility, or performance.
• Groupthink in workshops; mitigate with anonymous idea capture and dot voting.

PMP Example Question

During a requirements workshop, the team uses journey mapping and paper mockups to explore options, then conducts quick user walkthroughs to gather feedback. What should the project manager do next to turn these findings into actionable scope?

1. Develop the work breakdown structure to detail all deliverables.
2. Convert validated concepts into user stories with acceptance criteria and add them to the backlog.
3. Finalize the project schedule since concepts are now approved.
4. Conduct a quantitative risk analysis on all ideas generated.

Correct Answer: B — Convert validated concepts into user stories with acceptance criteria and add them to the backlog.

Explanation: Design thinking outputs should be translated into clear, testable requirements for planning and prioritization. WBS and detailed scheduling come after requirements are defined and agreed.