HCD / RESEARCH-LED PRODUCT DEVELOPMENT
リサーチを「画面の検証」ではなく、「プロダクト意思決定を変えるため」に使った。
プロジェクト開始時には、「何を作るべきか」についていくつかの仮説がすでに存在していました。
私の役割は、すぐにSolutionへ飛びつくのではなく、何が事実で何が仮説なのかを整理し、実際のユーザーと業務を理解し、その結果をチームが使えるプロダクト判断へ変換することでした。
課題設定・DiscoveryからResearch、Design Exploration、Validation、ImplementationまでUXプロセス全体をリード。
Solutionを答えではなくHypothesisとして扱い、User Evidenceを使ってProduct Priorityを判断。
ResearchをProduct Prioritizationへ接続し、未検証のAssumptionに依存する意思決定を減らした。
担当は、ユーザー理解をプロダクト判断につなげること。
Problem Definition、Discovery、Research、Design Exploration、Validation、DeliveryまでUXプロセスをリードしました。
UIを制作するだけではなく、実際のユーザーと業務への理解をProduct Decisionへ反映することを責任範囲としました。
私自身はResearch Planning・Synthesis、Design PrincipleとJourney Requirementへの変換、Concept Design・Evaluation、EngineeringとのImplementation Reviewを担当しました。
Product、Engineering、Operationsは、それぞれ事業知識、技術的専門性、業務制約を持ち寄りました。
- UXを下流の制作工程ではなく、Product Decisionの一部として位置づけた。
Solutionを考える前に、AssumptionとEvidenceを分けた。
Business RequirementをそのままScreenへ落とし込むのではなく、Stakeholderとともに「何が分かっているか」「何を仮定しているか」「何を検証すべきか」を整理しました。
Research自体を目的にせず、意思決定に影響する問いを優先しました。
- Stakeholder Assumption
- Existing Workflow Problem
- Support / Complaint Pattern
- Operational Constraint
- Product Directionを変える可能性のあるQuestion
Product Decisionへの影響度を基準にResearch Questionを優先する。
- Discoveryを具体的なProduct Decisionへ接続。
リサーチ結果を、DesignとProduct Priorityへ変換した。
User Interview、Workflow Analysis、Contextual Understanding、Usability Evaluationから、共通するPain Point、Behavior、Unmet Needを特定しました。
Research Reportを作ることを成果とは考えませんでした。
- Recurring User Needs
- Behavior Patterns
- High-friction Workflow
- System LanguageとUser UnderstandingのMismatch
- Failure / Recovery Scenario
- FindingをDesign Principleへ変換。
- Journey Improvementを明確化。
- User Evidenceを使ってProduct Priorityを議論できるようになった。
デザイン案を「答え」ではなく「検証すべき仮説」として扱った。
複数の方向性をUser Evidence、Business Objective、Technical Constraint、Usability Findingをもとに比較しました。
Researchが初期仮説と異なる結果を示した場合には、デザインを守るのではなく方向性を見直しました。
User Evidence、Business Value、Feasibility、Usabilityのバランスが最も良い方向を選ぶ。
- 議論を「どのDesignが好きか」から「どの方向がEvidenceで支持されるか」へ変えた。
ResearchとDesign Rationaleを可視化し、チームで判断できる状態をつくった。
Workshop、Prototype、Usability FindingをProduct Stakeholder、Designer、Engineerの共通Artifactとして活用しました。
これにより、個人の好みによる議論を減らし、Trade-offを具体的に話せるようにしました。
- Prioritizationの根拠を強化。
- Handoff前にEngineering ConstraintをDesignへ反映。
- DeliveryまでDesign Rationaleを維持。
HCDをHandoffで終わらせなかった。
検証済みConceptを詳細UX/UIへ展開し、Implementation・ReviewまでEngineeringと連携しました。
Edge Case、State、Accessibility、Technical Constraintも設計段階から扱いました。
- 実装されたExperienceとResearch Insightのつながりを維持。
- 明確なUser Requirementを基準にImplementation DecisionをReviewできるようになった。
大きな成果は、Evidence-drivenなProduct Developmentへ近づけたこと。
Product Experienceの改善だけでなく、組織的な価値もありました。
ResearchによってStakeholderがPrioritizationや方向性を判断するための根拠を持ち、Assumptionだけに依存する意思決定を減らすことができました。
- より再現性のあるHCD Process。
- ResearchとPrioritizationの接続。
- Design Rationaleの可視化。
- Opinion-drivenなProduct Decisionへの依存を低減。
JAPAN / U.S. HCD LENS
HCDは、組織の意思決定文化に合わせて運用する必要がある。
すべての日本企業・米国企業を一括りにするものではなく、Collaboration Designの観点です。
日本の組織では、EvidenceとDecision Rationaleを可視化することで、Stakeholder間の合意形成や暗黙の不同意を減らしやすくなる。
米国型Product Teamでは、Ownership、Trade-off、Next Actionを明確にし、Evidenceを素早い意思決定へつなげることが重要になる場合が多い。
Research Methodが同じでも、Findingの伝え方とDecisionへの接続方法は組織文化に合わせる必要がある。
WHAT THIS PROJECT DEMONSTRATES
意思決定を変えないリサーチには、ほとんど価値がない。
HCDの価値は、すべてのResearch Methodを実施することではありません。
Product Developmentの各段階で、より良い判断を可能にすることにあります。
Researchは、チームが次に何をするかを変えるためにある。