インタビューは設計が７割～理系の設計手順～
前回は理系的インタビューがいいと思う話を述べました
今回は簡単にどんな手順でプロダクト政策に活かすインタビューを作っていくのか、考えている流れについて、シーン別に紹介したいと思います
今後は流れに合わせて具体的な考え方を書いていくつもりです。。。
シーン１：ユーザーの既存の課題や行動を深堀したい
目的：ペルソナの業務や行動を理解し、プロダクトのあるべき姿を見出す
実施段階：主に企画初期段階（シーン２と合わせて行うことも多い）
主な確認事項：ペルソナの実態、業務・行動のフロー、課題の重大性と代替手段の内容
設計プロセス
プロジェクトにおいて決まっている内容を整理する（対象の人物が先に決まっているか、対象の業務が先に決まっているのか）
決まっていることから、それに関連する人物や業務などを5W2Hの観点から洗い出す（業務が先に決まっているなら、それにかかわるユーザーや場所や時間、またその業務フローの詳細などをわかっている部分を書き出す）
2でわからないとなった部分や疑問になる点をピックアップする（フローのどこに課題が生じているのかわからないなど）
ピックアップした不明点に関して理由を合わせて仮説を立てる（ここに原因があるからなど明確にあってたか間違ってたか判断できる内容にする）
仮説とその理由が回答になる質問を作る
上記の質問を誘導尋問にならないように微調整する
シーン２：プロトタイプを評価したい
目的：開発前に企画の効果検証を行う
実施段階：主に企画終盤（シーン１と合わせて行うことも多い）
主な確認事項：ペルソナと課題感の認識ギャップがないか、プロトタイプなど考えている内容は課題の解消につながりそうか
設計プロセス
対象の課題とそれに対するうち手（プロトタイプ）を用意する
現状課題になっている内容と、プロトタイプでどう変わるのかの説明を用意する
どのくらい課題が解消されるのか、残っている課題や新たに生まれる課題は何かを仮説を立てる
説明に合わせて仮説が回答になるような質問を用意する
上記の質問を誘導尋問にならないように微調整する（特に新たに生じる課題がないか発見するためにも懸念点が出しやすいオープンクエスチョンを意識する）
シーン３：運用しているシステムを評価したい
目的：開発したプロダクトの評価と次回改修点の洗い出し
実施段階：リリースして一定期間運用した後
主な確認事項：使用していて課題になっていること全般
設計プロセス
可能な限り運用のデータを収集し、課題となっていそうな部分を精査する
課題の優先度をある程度決めておく（大なり小なり意見は出てくるので、業務プロセス上の影響度やKPIを考慮して対応すべきかどうか考える軸は事前に用意し共有しておく）
優先度の高いと考えている課題を具体的なアクションレベルで言語化して仮説とする
使用シーンをイメージしながら仮説が回答になるような質問を用意する
上記の質問を誘導尋問にならないように微調整する（ユーザーの感じていることを聞き出すためにも使用シーンなどは限定しつつ直接的に聞かないようにする）
この記事が気に入ったらサポートをしてみませんか？