← UI/UX Atlas
プロセス早見表Process Reference
INPUT · PROCESS · OUTPUT

プロセス早見表Process Reference

各デザイン方法論を「INPUT（何を持ち込むか）」「PROCESS（何をするか）」「OUTPUT（何が生まれるか）」で整理した実務参照資料。概念の詳細は UI/UX Atlas 本編 を参照してください。 A practical reference organizing each design methodology by INPUT (what you bring), PROCESS (what you do), and OUTPUT (what is produced). For concept details, see the UI/UX Atlas main text.

HCD系HCD-based
01
人間中心設計（HCD）Human-Centered Design (HCD)
ISO 9241-210 準拠の4活動モデルfour-activity model
HCD系 全階層横断All layers プロジェクト全期間Full project lifecycle
ユーザーを設計プロセスの中心に置き、利用状況調査・要件定義・設計・評価を反復する国際規格準拠アプローチ。規制産業や公共サービスで特に有効。 Standards-compliant approach placing users at the center of design; iterates context research, requirements, design, and evaluation. Especially effective in regulated industries and public services.
INPUT · PROCESS · OUTPUT
INPUTPROCESSOUTPUT
  • 問題記述・ビジネス目標Problem statement & business goals
  • ビジネス要件・制約条件Business requirements & constraints
  • 既存システム・競合分析Existing system & competitive analysis
  • ユーザーへのアクセス機会User access (interviews, observation)
  • ステークホルダーの関与Stakeholder involvement
  1. 利用状況の把握Context of Use Analysisコンテキスチュアルインクワイアリー・観察・日記調査Contextual inquiry, observation, diary studies
  2. ユーザー要求の明示User Requirements Specificationペルソナ・CJM・ユーザーゴール整理Personas, CJM, user goal mapping
  3. 設計解の作成Design Solution CreationIA・ワイヤーフレーム・プロトタイプIA, wireframes, prototypes
  4. 設計の評価Design Evaluationユーザビリティテスト・ヒューリスティック評価 → ②へ反復Usability testing, heuristic eval → iterate to ②
  • ユーザー要求仕様書（URS）User Requirements Specification (URS)
  • ペルソナ・シナリオドキュメントPersona & scenario documents
  • 評価済みプロトタイプEvaluated prototypes
  • ユーザビリティ評価レポートUsability evaluation report
  • （規制産業）ISO 9241適合宣言(Regulated) ISO 9241 conformance statement
✓ 向いている状況When to UseISO/規制準拠が必要な医療・公共・金融システム。長期プロジェクト。エビデンスを重視する組織。ISO/regulatory compliance required (medical, public, financial). Long-term projects. Evidence-driven organizations.
✕ 向いていない状況When Not to Use短期スプリント。ユーザーアクセスが困難。スタートアップの初期仮説検証フェーズ。Short sprints. Limited user access. Early-stage startup hypothesis validation.
👥 UXデザイナー・リサーチャー・PdM・エンジニアUX Designer, Researcher, PdM, Engineer → 本編で詳しく読むRead full text
02
ゴール指向デザイン（GDD）Goal-Directed Design (GDD)
Alan Cooper — About Face
HCD系 戦略〜骨格層Strategy→Skeleton 3〜6ヶ月3–6 months
ユーザーの「ゴール（目標）」を起点に機能要件を導出する6フェーズアプローチ。ペルソナを設計の唯一の基準として機能させ、複雑なエンタープライズシステム設計に強みを持つ。 A 6-phase approach deriving functional requirements from users' "goals." Uses personas as the sole design criterion; strong for complex enterprise system design.
INPUT · PROCESS · OUTPUT
INPUTPROCESSOUTPUT
  • ステークホルダーインタビュー（経営・PdM・営業・CS）Stakeholder interviews (exec, PdM, sales, CS)
  • ユーザーインタビュー・観察User interviews & field observation
  • 競合製品・業界分析Competitive & industry analysis
  • 既存システムの問題データExisting system problem data
  1. Research行動・目標・フラストレーションを収集Gather behaviors, goals, frustrations
  2. Modelingペルソナ・文脈シナリオ作成Create personas & context scenarios
  3. Requirementsゴール→機能要件マッピングMap goals → functional requirements
  4. Frameworkインタラクションフレームワーク（主要画面構造）Interaction framework (key screen structure)
  5. Refinement → Support詳細設計・開発サポートDetailed design & dev support
  • ペルソナドキュメント（1〜5体）Persona documents (1–5)
  • 文脈シナリオ・キーパスシナリオContext & key-path scenarios
  • 要件行列（ゴール×機能）Requirements matrix (goals × features)
  • インタラクションフレームワークInteraction framework
  • 詳細デザイン仕様書Detailed design specification
✓ 向いている状況When to Use複雑なエンタープライズ・B2Bシステム。機能要件が多い大規模プロダクト。Complex enterprise/B2B systems. Large products with many functional requirements.
✕ 向いていない状況When Not to Use小規模・短期プロジェクト。ペルソナ調査に十分な時間が取れない場合。Small or short-term projects. Insufficient time for persona research.
👥 UXデザイナー・インタラクションデザイナー・PdMUX Designer, IxD Designer, PdM → 本編で詳しく読むRead full text
発想・革新系Innovation-based
03
デザイン思考Design Thinking
IDEO / Stanford d.school
発想・革新Innovation 戦略・要件層Strategy & Scope 1日〜数ヶ月1 day – months
問題定義そのものから始める非線形・反復的アプローチ。共感→定義→発散→プロトタイプ→テストの5フェーズで問題を探索する。ワークショップから中長期プロジェクトまで適用可能。 Non-linear, iterative approach starting from problem definition itself. Explores problems through 5 phases: Empathize → Define → Ideate → Prototype → Test. Applicable from workshops to long-term projects.
INPUT · PROCESS · OUTPUT
INPUTPROCESSOUTPUT
  • 漠然とした課題・テーマ（HMWの起点）Vague challenge / theme (HMW starting point)
  • 多職種チーム（デザイナー・エンジニア・ビジネス・専門家）Cross-functional team (designers, engineers, business, domain experts)
  • ユーザーへのアクセス機会Access to users for interviews/observation
  • プロトタイプ素材（付箋・紙・ホワイトボード）Prototyping materials (sticky notes, paper, whiteboard)
  1. Empathize観察・インタビュー・シャドーイングで共感データ収集Observation, interviews, shadowing
  2. Defineアフィニティ図→POVステートメント→HMW問い設定Affinity diagram → POV → HMW questions
  3. Ideateブレスト・クレイジーエイツ・発散後に収束Brainstorm, Crazy 8s, diverge then converge
  4. Prototype低忠実度モック（紙・Figma）を素早く作成Rapid low-fi mockups (paper, Figma)
  5. Test5人以上でテスト→学習→次サイクルへTest with 5+ users → learn → next cycle
  • 共感マップ・インタビュー記録Empathy maps, interview notes
  • POVステートメントPOV (Point of View) statement
  • HMW問い一覧HMW question list
  • アイデアスケッチ群Idea sketches
  • テスト済みプロトタイプ＋洞察サマリーTested prototype + insight summary
✓ 向いている状況When to Use問題が不明確な新規事業・サービス開発。チームの視点が固まっているときの発散。組織横断ワークショップ。New business/service with unclear problems. Divergence when team is stuck. Cross-org workshops.
✕ 向いていない状況When Not to Use問題が既に明確な場合。厳格な規制準拠が求められる場合（HCDを使う）。Problem already clearly defined. Strict regulatory compliance required (use HCD instead).
👥 多職種チーム（5〜8名）+ ファシリテーターCross-functional team (5–8) + Facilitator → 本編で詳しく読むRead full text
04
デザインスプリントDesign Sprint
Jake Knapp / Google Ventures — Sprint
発想・革新Innovation 要件〜骨格層Scope→Skeleton 5日間（短縮版3日）5 days (3-day condensed)
5日間でアイデア創出からユーザーテストまでを完結させるタイムボックス型の意思決定加速フレームワーク。Decider（意思決定者）の参加が必須条件。 Time-boxed decision-acceleration framework completing idea generation through user testing in 5 days. Requires a Decider (key decision-maker) to participate.
INPUT · PROCESS（5日間）· OUTPUT
INPUTPROCESS（5日間）OUTPUT
  • スプリントクエスチョン（中心課題）Sprint Question (central challenge)
  • Decider参加の5〜7名チーム5–7 person team incl. Decider
  • 関連リサーチ・競合データRelevant research & competitive data
  • 5名のテストユーザー（事前確保）5 test users recruited in advance
  1. Day 1 – Map長期目標確認・HMW・ターゲット絞り込みLong-term goal, HMW, target selection
  2. Day 2 – SketchLightning Demos→4ステップスケッチLightning Demos → 4-step sketch
  3. Day 3 – Decideドット投票→ストーリーボード確定Dot vote → storyboard decision
  4. Day 4 – PrototypeFigmaでリアリスティックモック（8時間）Realistic prototype in Figma (8 hrs)
  5. Day 5 – Test5人のユーザーテスト→パターン分析User tests with 5 people → pattern analysis
  • リアリスティックプロトタイプRealistic prototype
  • 5人分のインタビュー記録5 user interview recordings/notes
  • 洞察サマリー・パターン分析Insight summary & pattern analysis
  • Go / No-Go / Pivot 意思決定記録Go / No-Go / Pivot decision record
✓ 向いている状況When to Use意思決定が急ぎ・チームが発散した状態・新機能・新サービスの検証・ピボット判断。Urgent decisions, divergent team, validating new features/services, pivot judgment.
✕ 向いていない状況When Not to UseDeciderが参加できない。5日間確保できない。方向性がすでに決まっている。Decider cannot participate. Cannot secure 5 days. Direction already decided.
👥 Decider（必須）＋デザイナー・エンジニア・PdM・専門家 計5〜7名Decider (required) + Designer, Engineer, PdM, Expert — 5–7 total → 本編で詳しく読むRead full text
アジャイル系Agile-based
05
Lean UX
Jeff Gothelf — Lean UX (2013)
アジャイル系Agile-based 戦略・要件層Strategy & Scope スプリント単位（継続）Per sprint (ongoing)
アジャイル環境でのUX実践を体系化したフレームワーク。「仮定→実験→学習」のBuild-Measure-Learnサイクルと設計を統合し、成果物よりも学習と検証を優先する。 Framework systematizing UX in Agile environments. Integrates design with Build-Measure-Learn cycle, prioritizing learning and validation over deliverables.
INPUT · PROCESS · OUTPUT
INPUTPROCESSOUTPUT
  • ビジネス仮定（ユーザー・問題・解決策・価値に関する前提）Business assumptions (users, problems, solutions, value)
  • 既存のユーザーデータ・アナリティクスExisting user data & analytics
  • スプリントバックログSprint backlog
  • Lean UX Canvas（前サイクルから）Lean UX Canvas (from previous cycle)
  1. 仮定の宣言と優先順位付けDeclare & Prioritize Assumptionsリスクの高い仮定を特定Identify highest-risk assumptions
  2. MVP設計Design MVP / Experiment最小限のデザイン（スケッチ・ワイヤー）Minimal design (sketches, wireframes)
  3. 実験実行（Build）Run Experiment (Build)プロトタイプまたは実装Prototype or implementation
  4. データ収集（Measure）Collect Data (Measure)定量・定性データ取得Quantitative & qualitative data
  5. 学習・仮定更新（Learn）Learn & Update (Learn)→ 次サイクルの仮定を更新→ Update assumptions for next cycle
  • Lean UX Canvas（更新版）Lean UX Canvas (updated)
  • 検証済み／棄却済み仮定リストValidated / invalidated assumption list
  • MVP・実験レポートMVP & experiment report
  • 更新されたプロダクトバックログUpdated product backlog
✓ 向いている状況When to Useアジャイル開発チームとのUX統合。スタートアップの仮説検証フェーズ。市場適合性が不確かな新機能開発。Integrating UX with Agile teams. Startup hypothesis validation. New features with uncertain market fit.
✕ 向いていない状況When Not to Use成果物の納品が主目的のプロジェクト。規制上の文書化要件が厳格な場合（HCDを使う）。Projects where deliverable documentation is primary. Strict regulatory documentation requirements (use HCD).
👥 UXデザイナー・エンジニア・PdM（スクラムチーム内）UX Designer, Engineer, PdM (within Scrum team) → 本編で詳しく読むRead full text
06
Dual-Track Agile（二軌道アジャイル）Dual-Track Agile
Jeff Patton / Marty Cagan — INSPIRED
アジャイル系Agile-based 全階層（継続的）All layers (continuous) スプリント単位（継続）Per sprint (ongoing)
DiscoveryトラックとDeliveryトラックを並走させ、UXが1〜2スプリント先行して設計を検証するモデル。アジャイルとUXの構造的な摩擦を解消する最も実用的な解決策。 Runs Discovery and Delivery tracks in parallel, with UX running 1–2 sprints ahead to validate designs. The most practical solution to structural friction between Agile and UX.
INPUT · PROCESS（並走2トラック）· OUTPUT
INPUTPROCESS（並走2トラック）OUTPUT
  • プロダクトバックログ（機能・ユーザーストーリー）Product backlog (features, user stories)
  • ユーザーリサーチキュー（未解決の問い）UX research queue (unresolved questions)
  • スプリント計画・チームキャパシティSprint plan & team capacity
  • 前スプリントの学習・レトロ知見Previous sprint learnings & retro insights
🔍 Discovery Track （1〜2スプリント先行）(1–2 sprints ahead)
  1. ユーザーインタビュー・テストUser interviews & testing
  2. プロトタイプ作成・検証Prototype creation & validation
  3. 仕様確定→Deliveryへ渡すFinalize spec → hand off to Delivery
🚀 Delivery Track （実装・リリース）(implement & release)
  1. スプリントプランニング（Discovery成果を反映）Sprint planning (incorporating Discovery output)
  2. 開発実装・QADevelopment implementation & QA
  3. リリースRelease
  • 検証済みプロトタイプ・デザイン仕様Validated prototype & design spec
  • 実装済みUI・機能Implemented UI & features
  • 更新されたデザインバックログUpdated design backlog
  • テストサマリーレポートTest summary report
✓ 向いている状況When to UseスクラムチームにUXを統合したい場合。Lean UXでは成果物が不足する場合。Integrating UX into a Scrum team. When Lean UX produces insufficient deliverables.
✕ 向いていない状況When Not to UseUXデザイナーが1人でDiscovery・Deliveryを兼任せざるを得ない少人数チーム。Small teams where one UX designer must handle both Discovery and Delivery alone.
👥 UXデザイナー（Discovery担当）・エンジニア・PdMUX Designer (Discovery) + Engineers + PdM (sprint team) → 本編で詳しく読むRead full text
システム・組織・参加系Systems / Org / Participatory
07
参加型デザインParticipatory Design
スカンジナビア発・1970年代〜Scandinavian origin, 1970s–
システム・組織Systems/Org 戦略〜構造層Strategy→Structure プロジェクト全期間Full project lifecycle
ユーザー・当事者・コミュニティメンバーを設計チームの一員として参加させる民主的アプローチ。公共サービスや社会的影響の大きいシステムで特に有効。 Democratic approach including users, stakeholders, and community members as design team members. Especially effective for public services and systems with significant social impact.
INPUT · PROCESS · OUTPUT
INPUTPROCESSOUTPUT
  • 参加者の特定・招集計画（ユーザー・当事者・周辺的ユーザー）Participant identification & recruitment (users, stakeholders, marginal users)
  • ファシリテーション設計Facilitation design
  • プロトタイプ素材（紙・付箋・モック）Prototyping materials (paper, sticky notes, mockups)
  • 多様性確保の戦略（マイノリティの参加）Diversity strategy (inclusion of minority voices)
  1. 参加者招集・チーム組成Participant Recruitment & Team Formation
  2. コ・デザインセッションCo-Design Sessions共同プロトタイピング・ワークショップJoint prototyping workshops
  3. 共同評価・フィードバック統合Joint Evaluation & Feedback Integration
  4. 共同意思決定Shared Decision-Making設計判断を参加者と共に行うDesign decisions made with participants
  • 共同作成プロトタイプ・スケッチCo-created prototypes & sketches
  • 参加者の知見・語りの記録Participant insights & narratives
  • 要件ドキュメント（参加者の言葉で）Requirements document (in participants' words)
  • プロセスドキュメント（誰がどう参加したか）Process document (who participated and how)
✓ 向いている状況When to Use公共サービス・行政・コミュニティ向けサービス。多様な当事者の声が必要な設計。Public services, government systems, community-focused services requiring diverse stakeholder voices.
✕ 向いていない状況When Not to Use参加者の時間的コミットが得られない場合。B2Bなど特定専門家のみが対象のシステム。When participant time commitment cannot be secured. B2B/specialist-only systems.
👥 ファシリテーター・UXリサーチャー・当事者ユーザー・ステークホルダーFacilitator, UX Researcher, end users & stakeholders as co-designers → 本編で詳しく読むRead full text
08
パターンランゲージPattern Language
Christopher Alexander — A Pattern Language (1977)
システム・組織Systems/Org 構造〜表層Structure→Surface 長期・継続的蓄積Long-term, continuous
繰り返し現れる設計問題とその解決策を「パターン」として体系化・共有する知識管理手法。デザインシステムのコンポーネント定義や組織のデザイン知識体系化に応用される。 Knowledge management method systematizing recurring design problems and solutions as "patterns." Applied to design system component definition and organizational design knowledge.
INPUT · PROCESS · OUTPUT
INPUTPROCESSOUTPUT
  • 繰り返し現れる設計問題の観察・記録Observations of recurring design problems
  • 成功した設計事例の蓄積Accumulated successful design cases
  • 既存パターンライブラリ（参照・拡張）Existing pattern libraries (for reference & extension)
  • 文脈情報（ユーザー環境・技術制約）Context info (user environment, technical constraints)
  1. パターン発見Pattern Discovery成功事例を体系的に観察・分析Systematically observe & analyze successes
  2. パターン記述Pattern Documentation名前・問題・文脈・解決策・結果の形式で記述Document: Name / Problem / Context / Solution / Consequences
  3. パターン言語の構築Build Pattern Languageパターン間の関係をネットワーク化Network patterns and relationships
  4. パターンの適用・更新Apply & Update Patterns新規設計へ照合・適用し、結果でパターンを更新Match to new problems; update from usage results
  • パターンカタログ（名前・問題・文脈・解決策・結果）Pattern catalog (Name, Problem, Context, Solution, Consequences)
  • パターン言語マップ（関係図）Pattern language map (relationship diagram)
  • デザインシステムのコンポーネント定義Design system component definitions
  • デザインガイドライン・スタイルガイドDesign guidelines & style guide
✓ 向いている状況When to Useデザインシステム構築。組織のデザイン知識体系化。複数チーム・プロダクトで一貫性を保ちたい場合。Building a design system. Systematizing org design knowledge. Consistency across multiple teams/products.
✕ 向いていない状況When Not to Use単発プロジェクト。継続的な知識更新に投資できない組織。One-off projects. Organizations unable to invest in ongoing knowledge updates.
👥 デザインシステムチーム・シニアUXデザイナー・アーキテクトDesign system team, Senior UX designer, Architect → 本編で詳しく読むRead full text
09
ウォーターフォール + UXWaterfall + UX
規制産業・大規模フェーズ型開発Regulated industries & large-scale phased development
システム・組織Systems/Org 全階層（順次）All layers (sequential) プロジェクト全期間（フェーズ固定）Full project (fixed phases)
要件定義→設計→実装→テストの逐次フェーズでUXを関与させるモデル。医療機器・航空・公共調達など要件が安定した規制産業で有効。IEC 62366などの規制準拠UXプロセスと整合する。 UX involvement in sequential Requirements → Design → Implementation → Test phases. Effective in regulated industries (medical devices, aviation, public procurement) with stable requirements. Aligns with IEC 62366 and similar regulatory UX processes.
INPUT · PROCESS · OUTPUT
INPUTPROCESSOUTPUT
  • ビジネス要件書・RFPBusiness requirements document / RFP
  • 予算・スケジュール制約Budget & schedule constraints
  • 規制・コンプライアンス要件Regulatory & compliance requirements
  • ステークホルダー承認プロセスStakeholder approval process
  1. 要件定義フェーズRequirements PhaseUXリサーチ・ペルソナ・ユーザーストーリー・受け入れ基準UX research, personas, user stories, acceptance criteria
  2. 設計フェーズDesign PhaseIA・ワイヤーフレーム・プロトタイプ・フォーマティブ評価IA, wireframes, prototypes, formative evaluation
  3. 実装フェーズImplementation PhaseUI仕様書・スタイルガイド伝達・デザインレビューUI spec handoff, style guide, design reviews
  4. テストフェーズTest Phase受け入れテスト・サマティブ評価（規制産業）Acceptance testing, summative evaluation (regulated)
  • UX要件定義書・ユーザーストーリー集UX requirements doc & user story collection
  • ワイヤーフレーム・プロトタイプWireframes & prototypes
  • UI仕様書・スタイルガイドUI specification & style guide
  • ユーザビリティ評価レポート（フォーマティブ・サマティブ）Usability evaluation report (formative & summative)
✓ 向いている状況When to Use規制準拠が必要な医療機器・航空・金融・公共調達。要件が安定しており変更が少ないシステム。Medical devices, aviation, finance, public procurement requiring regulatory compliance. Systems with stable, low-change requirements.
✕ 向いていない状況When Not to Use要件が不確かな新規プロダクト。市場反応を見ながら反復したいデジタルプロダクト。New products with uncertain requirements. Digital products requiring iterative market feedback.
👥 UXデザイナー・リサーチャー・PdM・QAエンジニア・規制アフェアーズ担当UX Designer, Researcher, PdM, QA Engineer, Regulatory Affairs → 本編で詳しく読むRead full text