プロダクト開発をしていくと、大きいものから小さいものまで様々な課題が発見されます。
色々な人たちを巻き込みながらリリースまで右往左往しながら決めていくでしょう。
プロダクトマネージャー→デザイナー→エンジニアのような決まった事を流していく開発方法がだめという事はないのですが、様々な背景を理解しながらチーム間で開発を続けるには不向きなやり方だと思います。
この記事では、私が行ってる、課題への理解を深め小さく合意をとり複数の専門分野の知見を集めながら開発フローを紹介します。
製品設計のプロセス
全体像として以下の流れで進めることが多いです。
デザイナ一人で進めるのではなく、関係者をこの時点で巻き込みながら進めます。
- ゴールを理解する
- ユーザーに共感する
- スコープを明確にする
- 解決策のアイデアを出す
- 解決策のプロトタイプを作成する
- ユーザーテストをする
- 成功を測定する
ゴールを理解する
解決策に飛びつく前に、「課題」を整理して目標を決めます。
まずはじめにユーザーの現状理解するための時間を取ります。
問題の背景を理解し、その意義をメンバーに説明し納得してもらって初めて、開発をスタートできます。
現状整理には以下のようなことを考えます。
- なぜこの製品や機能が重要なのか？
- どんな問題を解決しようとしているのか？
- この製品はユーザーにどのような利益をもたらすのか？
- それは世の中にどんな影響を与えるのか？
- どのようなビジネスチャンスを生み出すのか？
ユーザーに共感する
課題が明確になってきたら、ユーザーのペイン（嫌と思ってるところ）を理解するための調査をどのように行ったかを示します。
- 彼らの目標や動機は何ですか？
- 彼らの苦痛は何ですか？
- この苦痛はどのような人が持っているのか
- 今はどのようにユーザーこのことと向き合っているのか/代替手段は何か
- 彼らのニーズは何か？
スコープを定義する
ユーザー・ジャーニーを描くことで、ユーザーの視点からプロダクトと関わる体験を理解しやすくなります。
問題の説明を作成するために、「HowMightWe（どうすれば私たちは～できそうか？）」というフレーズで始めることがよくあります。
Figjam、Whimsical、Miroのようなフローチャートツールを使用して、ユーザーが製品内の主要なアクションを完了するためにどのようなステップを踏むかを整理します。
以下の点を考慮します。
- シンプルにすること
- 特殊な状況や依存関係を細かく考えず、ユーザー・ジャーニーを複雑にしすぎないようにします
- MVPを定義する
- どの機能セットが最小の構成でユーザーとビジネスに最大の価値をもたらすか？またそれを判断できるか
解決策のアイデアを出す
チームメンバーからアイデアを出してもらったり、理解してもらうために以下のようなものを用意して議論をします。
- ワイヤーフレーム
- 画面遷移
- ユーザー・ジャーニー
- アイデアのリスト
- スケッチ（あらゆる種類のもの
競合他社の分析
競合他社の調査は、他の製品がどのようにこの問題を解決したかを参考にしたり、新しいアイデアのインスピレーションを求めたりするため、アイデア出しの段階で重要です。
- 競合はこの問題を解決するために、この分野で何をしているか？
- 共通しているものはあるか
プロトタイプを作る
最終的な解決策が決まったら、デザイン・プロトタイピングツールでモックアップます。
個人的にはFigmaを使うことを推奨していますが、より複雑なユーザーの行動を見たい場合は、Framer のようなより高度なプロトタイプツールを使う事もあります。
プロトタイプを作るときは以下のような事に注意をします。
- 何を確認するためのプロトタイプなのかを合意してから作る
- 作り込みをしすぎない
- 重要なフローだけをユーザーに見せるようにする
- 見た目の議論をしない
- 既存の製品の新機能をデザインする場合は、その製品のブランド・ガイドラインやデザイン・システムに沿ってデザインする。
成功の測定を考える
プロダクトの機能の使用状況をどのように追跡するか、具体的にどの成功指標をモニターすべきかを検討することで、当初の目標に結びつけた状態になるのか改めて見直します。
モニタリングするのに役立つ指標としては、以下のようなものがあります。
- ユーザー獲得
- 何人のお客様が商品やサービスを購入したりダウンロードしたりしたか。
- エンゲージメント
- ユーザーがプロダクトとどのように望ましい形で相互作用できているか。
- 機能の利用率
- 目的のアクションを起こしたユーザーの割合。
- タスク成功率
- ユーザーが正しくタスクを完了した割合。
- タスク完了時間
- ユーザーがタスクを完了させるのに要した時間。
- 反応回数
- ユーザーがどれだけ頻繁にアクションを起こしたか。週のログインの回数など
- 収益
- プロダクトがどのような方法で収益を上げるか、またどのくらいの収益を上げているか。
ユーザーテストをする
プロトタイプを作ったら、それをユーザーに近しい人に触れてもらいフィードバックをもらいます。
フィードバックはアンケートのような形もあれば、実際に触ってるところを見て受け取るなど様々な方法があります。
以下のようなことに注意してフィードバックをもらいます。
目的は自分たちの勘違いを見つける
- NGなパターンを見つける
- 想定できていなかったニーズを見つける
アンケートでフィードバックをもらう場合
- アンケートの内容は触ってもらったあとに見せる
- バイアスを持った状態でUIを触らないようにするため
- 回答者の属性をきちんと分類する
- 不特定多数の声になるため、フィードバックの数以外でも重み付けをするため
- 選択制の回答を多くする
- 自由入力の場合、開発側が誤解して受け取る可能性が高いため。自由形式の質問をしたい場合はビデオチャットなど直接コミュニケーションを取れるようにするほうが望ましい
ユーザーインタビューでフィードバックをもらう場合
- プロダクトの具体説明はせずに、「あなたは○○の人でこれから□□をしたいと思っています。この画面から初めてください」くらいの説明だけであとは自由に触ってもらう。
- 触ってもらってるときには、ユーザーに質問されたとき以外は話さない
- ビデオチャットの場合は操作中は喋らないことをユーザーに伝えて、ミュートにする
- ユーザーには思ったことは口に出してもらう
- 質問をすることは予め決めておく
- 即興で質問をするとフィードバック後に整理をしづらくなるため
プレゼンテーションをする
施策を実行するか、またはやめるかを意思決定する人が別にいる場合、適切に判断をして貰う必要があります。
ユーザーリサーチの結果、スケッチ、ワイヤーフレーム、ユーザージャーニーマップ、ユーザビリティテストの結果などこれまで調べたものを根拠にして説明します。専用にスライドなどを作ると有効です。
説明をする場合、淡々とドキュメントやスライドを読むのではなく、ストーリーテリングが重要です。
これはデザイナーにとっては腕の見せどころでデザインプロセスが最も価値を発揮する場面です。
問題を理解することにきちんと時間をかけて、解決策が妥当である説明をしましょう。
最後に
私が好む、デザインプロセスを紹介させてもらいました。
優れた物語は、問題から始まり、主人公がどのように困難を克服し、解決策にたどり着くかという旅に連れて行ってくれます。
これはデザインプロセスにも通じるもので、物語の中で同志をみつけ、失敗と成功を共に経験しチームを作って行くことで考えが一致しプロダクト発開の成功率を上げます。
残念ながらすべてのプロジェクトでこのような形で進めれるということはないのですが、合意を取りながら進めるという点でなんらかのインスピレーションにつながれば嬉しいです。