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