プロダクトデザインと言っても、デザインを考えたり、KPIを考えたり、ワイヤーを書いたり、グラフを作ったり、戦略を考えたり、スキルマップを作ったり、コンテンツを企画したり…と、色々な領域、色々な粒度の業務を行います。
デザイン/マーケティング、特にグロースの分野の掛け合わせが割合として増えています。
デザインとデータ分析を一緒にやると、それぞれが両方に効いてくる。
そして両方とも面白さが増す。
そんなデザインとデータ分析を融合する、主に戦略とデータとデザインとのお話です。
※プロジェクトマネージャー、UXUIデザイナーマーケターの方におすすめの記事です。事業会社の方々からすると、「そんなこと当たり前じゃない？何をいまさら。」と感じられるかもしれないですが、改めて読んで頂けると嬉しいです。
目次
プロダクトデザインでは「デザインとデータ分析は束ねて一本にすること」が必要
「プロダクト価値を向上させたいのだが、課題はなんだろう？」
この一見、ごく当たり前な問い。
この問いの解を出すのに必要な、ながいながい計算式が今回扱う話題です。
（※ちなみに省略する方法でもハックする方法でもなく、式の長さを書いただけ。）
デザインとデータを融合する意味はなに？っていう話ですが、これが当たり前に聞こえてとても難しいことです。
デザインとデータを融合するといいこと
・デザインとデータを融合すると考えるべき論点が明確になる。
・考えるべき論点が明確になると、実行することが明確になる。
・実行することが明確になると、検証する点が明確になる。
・検証する点が明確になると、次に考えるべき論点が明確になる。
・この繰り返しが、地道に成長へと導く
と考えています。
当たり前のように思えますが、膨大な情報量の中で、必死にプロダクトを成長させようと思うほど、気付けばPDCAのDoを繰り返したり、盲目的に目標を追い続けて気付けばどこに向かっているかわからなくなることがあります。しかも無意識のうちに。
例えば、着手していなかったが課題感としては認識しているタスクは多々存在すると思います。その中の1つが実はもっとも今サービスの成長を阻害している要因だとしたら？データで立証すれば、もっとも最初にやるべきこととして、明確に取り組むことができます。しかし、多くの場合「山ほどあるやらなければいけないこと」の難易度、そして報酬がゲームのクエスト一覧みたいに自動で見える化されてはいません。
高い山に登ることが前提になっている場合、力を無駄なく注いだ分だけ成長させること（効率的に早く）が求められ、そのためにはできるだけ、“正しく、速く、信じて”課題提起/解決をする必要があります。
デザインとデータを融合しても確実に正しくすることができる、とは思いませんが、「おおよそ正しいだろう。正しいと自分たちは思うことができる」ようにはなるのと、融合しないよりは打率は上がりやすいと考えています。
デザインとデータを融合するのに必要なメンバーとは
デザインとデータ分析を束ねて 1本のプロセスにするには
・仮説と追求をし、デザインに繋げるデータ分析ができる人
・データの検証、取得方法、理論構造に理解を示すデザイナー
・データ分析とデザインのブリッジができる人
この3つのロールが必要です。可能であれば兼務でもいいです。
これは実際行う人は別の人でもいいのだけど、チームとしてもしくは同じベクトルで向いていないと結構厳しくて、チームが分断されてたりして目標が違うものだと厳しい。
形式は何でもいいですが、同じ方向に向いていること、かつそれぞれが理解し合い、チームとして機能する状態であること。が必要です。
プロダクトデザインの進め方一覧
ここからが本題に移りたいと思います。
まず、プロダクトのデザインに日常的に携わる上で自分が認識しているプロセスを書き出してみました。
「サービス価値を向上させたい。課題はなんだろう？」というスタートから、最後インターフェースを設計するまでのフローは以下の通りになります。
これで抽出した課題の1つ、その初手が完了です。
あくまで初手であって、完了しないというのが世知辛いところ。完了し、課題が解決してくれればとてつもなくハッピーですが、このあともデータを追いかけ、検証し、確認した後に、必要あれば改善をしなければいけません。（そしてほぼほぼ必要である）
プロダクトデザインの進め方詳細｜17のプロセスの具体的方法
では、プロダクトデザインの進め方17個それぞれについて、紹介していきたいと思います。
長期的に支援するときに、当社が提供しているのは次の体制です。
ディレクター：データとデザインをブリッジする人（僕はこの位置にいます。）
データ分析：論理構築、トラッキング、データ判読を扱う人
デザイナー：ディレクターと一緒に判読結果から調査・定義・デザイン
クライアントと作戦を考える、進行する、のもディレクターの役割です。
1つずつ、フローに触れていくにあたり、登場人物がイメージできるように
ディレクター/データ分析/デザイナー
と記していきます。
※時系列が下記の通りではないこともその時のシーンによって多々あるのですが、整理のためにひとつの時系列にしています。
課題提起・抽出
：ディレクター/データ分析/デザイナー｜主にディレクター
まずは課題の抽出から。“悪い点が課題である”、のではなく字の如く“課すべきお題”として扱い、成長のために課すべきお題の論点を洗うもの。そこには悪い点もあれば、新しく課すべきお題もあるはずです。
「価値を高めて、サービスを成長させる」にあたって、課すべきお題はなんだろう？」という問いをチームメンバーと話し合っていきます。
事業戦略の予定、サービス体験、技術的な課題や負債、短期的と長期的、も含めて意見をとにかく集め、大き過ぎるものは砕いていきます。
MVV、事業戦略、外部環境、ユーザーレビュー、KPI、アナリティクスデータ、あとは個人の主観をソースとして、課題提起を行っていくと良いと思います。
課題着手の優先度決定
：ディレクター/データ分析/デザイナー｜主にディレクター
「価値を高めて、サービスを成長させる」ことにおいて挙がった課題の中で優先度を決めていきます。
重要なのは投資対効果。レバレッジがかかりやすい課題に取り組まないといけません。無駄を省く的な意味を強く捉えられてしまいそうですが、効率的に最速でサービスを成長させることに前提を置く。
期待利益／想定コスト＝ROI
と言えますが、それだけで決められるものではなく事業戦略やスケジュール、資源、期待利益の大きさなど総合的な判断となるでしょう。
その上で最も取り組むべき課題は何か？またそれ以降の順番は？を決定していきます。
マイルストーン/スケジューリング
：ディレクター/データ分析/デザイナー｜主にディレクター
課題の着手の順番を決めたら、目標的なスケジュールを決めていきます。
僕はこのタイミングではマイルストーンの粒度で決めるようにしていて、それぞれのタスクごとの細かいガントチャートは作成していません。（みなさんはどうしていますか？）
「スケジュールを立てた次の日にでも、新しい子が仲間入りする。」があるので、組み替えにガッカリしないように旗だけ立てるようにします。
「おおよそどのタイミングでどの課題を完了していて、その時にはこんな状態になっていると良いのではないか」を事業戦略と照らし合わせながら、決定していきます。
課題分解
：ディレクター/データ分析
「価値を高めて、サービスを成長させる」ことにおいて挙がった課題を分解していきます。
この分解作業はプロダクトによって性質が異なり、たとえタイトルは同じ課題であっても、内容はサービスの特徴、状況によって異なります。
分解を行うためにはプロダクトの仕様理解、外部環境も含めサービスが置かれている状況の解像度を高めて、次の原因仮説構築に繋げます。
原因仮説構築
：ディレクター/データ分析
解像度をあげたら分解作業の初手、仮説構築をします。
「サービスの成長にとって課題となっていることがなぜ起きているのか？」
を仮説構築していきます。
例えば課題として、「離脱率が高く、ユーザー数が伸びない」だとして、
この離脱の原因を明らかにしていく必要があります。もしかしたら、離脱はある一定の属性に発生しているかもしれないし、実は競合サービスなど外部環境の変化によって起きた可能性も拭えない。変数が多い中で、一撃で原因を突き止めることはほぼほぼ不可能。
この仮説構築が分解・解明のフェーズだともっとも重要かもしれません。
最初に間違った方向を向くと、間違っていることに気づずらくなります。
この時に必要なのは「漏れダブりのないMECEな状態で分解を行うこと。」
※仮説構築については以下記事で詳しくご紹介しています！
データで立証するためには、仮説を構築して立証に必要なデータを設計する必要があります。原因を仮説構築することで、立証すべきことが明確になり分解を進めていくことができます。
立証方法検討
：ディレクター/データ分析｜主にデータ分析
原因仮説を構築することができたら、仮説が正しそうかどうかを判断するためのエビデンス、つまりデータを収集する必要があります。
どのデータが必要なのか？を考えるには日本語で構成された文章を数式に翻訳する力が必要になります。「〇〇ができていないのではないか？ということを立証するにはこのデータのこの動きの相関性がこのような動きであれば、同じことが言える」といった論理構築力が求められます。
多くのパターンは一つのデータでは判断することができず、AのデータとBのデータを掛け合わせたものと、CのデータとDのデータを掛け合わせたものの相関関係を見る、トレンド値を見る、など複数のデータを必要とします。
立証材料の収集方法検討
：ディレクター/データ分析｜主にデータ分析
立証方法検討の時に出る懸念点、それは仮説を立証するために欲しい情報がトラッキングできていない、ということがあります。
最初から予期してトラッキングできていれば、それに越したことはないのですが、それはとても難しいこと。アーリーステージではPMFするためにプチピボットを繰り返したりしますし、余裕がないという精神的理由も大きく、そのため難易度は高いです。
なのでこのフェーズでも立証するためにデータを集めるところから始めなければいけないことも。その時はトラッキングを設計する必要が出てきます。
エンジニアにトラッキングをお願いしたりしますが、データの取得条件を考えておけるといいと思います。「●●がどうなっているか知りたい。だから〇〇日以降の〇〇の条件をクリアしたユーザーを〇〇の属性で分けたデータを取りたい」と言えるとエンジニアもスムーズにできると思います。
収集データの読解/原因解明
：ディレクター/データ分析｜主にデータ分析
データが集計できたら、それを基に原因仮説を立証していきます。
集めたデータをそのまま読み取るのはオーバーフローしてしまうので、グラフを作成したり、平均値をとったりとデータの加工作業を行います。
加工作業は発生してしまいますが、ここまでのプロセスが正確に取れていれば準備が整っているので工数を多くかけることなく、解を導き出すまでスムーズにいきます。データが集まって1つの解を導き出す、待ち望んだ瞬間。
課題を引き起こす原因を追求することができれば、分解・解明のフェーズは終了です。
この時点で、「サービスの成長にとって課題となっていること」という粒度から「課題を解決するためにはここを改善すれば良い」という粒度に変化しており、改善をするべき場所の特定ができています。
もし、導き出した原因を更に追求する必要があれば、ここまでのプロセスと同じフローを繰り返し、分解していきます。
解決策の定義、検討
：ディレクター/デザイナー
改善するべき場所の特定ができれば、いよいよ解決策の検討。
データ分析の結果をデザイナーとすり合わせ、解像度を高めます。
もちろんここまでのフローをSlackなどで共有しておくと、コミュニケーションコストを抑え、スムーズに移れます。
「現状のプロダクトはこの課題を抱えているが、現状からどんな状態になればこの課題を解決できるのだろう？このプロダクトにとって理想の状態はどんなカタチだろう？」ということを検討していきます。
調査方法検討/実施(Di/De)
：ディレクター/デザイナー
理想の状態を定義するにはどのような情報が必要か、またその情報はどんな方法で収集できるか？（ユーザーテスト、市場調査、他プロダクト調査etc）を検討し、プロセスの実現性と進行を精査していきます。
ここでは事前に確認したいこと、を明確にしておくことをお勧めします。
「〇〇を確かめたいからこの手段をとる。なのでここでこういった論点でこの項目を調べていこう」と目的を明文化しておくと良いと思います。
特にユーザーインタビューは要注意。ヒアリングを誤ると、思っていたことが確認できず、またそれをユーザーの声だと信じミスリードすると一定期間は気づくことが出来ません。
「あらかじめ確認したいこと、そのためにどんな視点でどんな質問を聞きたいか」を明らかにし、質問設計には注意を払いましょう。
調査結果読解
：ディレクター/デザイナー
調査して集めた情報を整理し、一つの解を出していきます。
データ分析と少し異なるのは判読に個人のバイアスがかかりやすいこと
データ分析は数字という絶対的な指標があるので、そこまでの道のりに差分は出ても判読の結果には差分が生まれづらいかもしれません
このデザインの調査結果の判読はくしくも、知識と経験をソースとした“センス”が光るポイントになっているのではないかと。
あくまで知識と経験がソースなので、後天的に努力で磨けるもの。
見抜く目を鍛えるつもりで、経験と知識を資産にするしかなさそう。
状態定義
：ディレクター/デザイナー
調査結果からわかったことをUIに落とし込むための情報に加工していきます。UI検討時にアイデアに花を咲かせる種子となる、「あるべき姿、達成すべき状態、達成された時の体験」を定義していきます。
この時、ニュアンスまで含めた言語化スキルが高いとより解像度を高く持つことができ、UI制作の時のテンションもそれに伴ってパフォーマンスが変わってきます。
逆に解像度、納得度が低いと、UI制作のパフォーマンスは下がりやすい。
モチベーションが上がらない、という安易な理由ではなく、点と点がつながらない、線にならない、といった理由でアイデアを開発しづらくなります。
なので文章、コンテキスト、ストーリーテリング、など抽象的なものを言語化する力は強い武器となります。
UI検討
：ディレクター/デザイナー｜主にデザイナー
理想の状態、体験を提供するためのインターフェースを制作します。
分析・解明から導き出された「課題の原因は何か？なぜ起きてしまったか。」と「どんな体験を理想とするか？」の情報を踏まえ、目的を持つことでUI制作時に「何を実現できていればいいか？」がわかりやすくなります。
UIの制作については、多くが語られるのでここでは割愛します。
開発工数見積、スケジューリング
：ディレクター/デザイナー｜主にディレクター
機能を実装するまでのスケジュールを立てていきます。フロントエンド/バックエンドの工数はどれぐらいかかるのか。実装するにあたり、本当に検討が漏れている点はないか。QAの工数はどれぐらいか。リリーススケジュールに間に合いそうか。
この時に開発工数と重ねた結果、引き算することはあります。
なのでここでもROIの話が発生。無茶な開発工数の圧迫は全体の品質の低下に繋がりかねないので、実現可能な方法を検討した結果、溢れるものは引き算する。引き算する判断を行う尺度はこの時も課題に対しての影響です。
毎度、ここをゆったり余裕を持った状態で望みたいと思っているのですが、なぜか最終的にはいつもパツパツになっている。
QA
：ディレクター/デザイナー
デザインの時にプロトタイプを見て確認していても、実際に触ってみると思ったものと差分があるかもしれません。その少しの差分がユーザー体験に大きく心象を変える場合もあります。
また、どれだけ深く考えても想定出来なかったことが起きることも。
スケジュールに組み込んでおきましょう。
検証方法検討
：ディレクター/データ分析/デザイナー｜主にデータ分析
リリースして完了、ではないのがサービスの宿命。どのプロジェクトも課題を解決するため、新しい価値をなすため、何らかの理由があったはず。
その理由を実現することができたのかどうかを確認する必要があります。
どうすれば検証することができるのか。検証するにはどんなデータをどんな視点で読めば解を出すことができるか。そのソースとなるデータは取得できているか。取れていなければどのようにトラッキングするか。を考えておかなければなりません。
データの蓄積には時間がかかるので、気づいた時にすぐ検証できることはなかなかありません。なるべく早く、設計しておくことが望ましいです。
また、検証時の解を予測し、ネクストアクションのイメージまで持っておけると良いでしょう。「この解であればこうする、あっちの解であればああする。」まで考えておけると、より準備が充実します。
次の課題へ
長い旅をようやく終えるとリリース。そしてまた新しいクエストを始めます。次の始まりの地へ向かい、課題分解から長い道のりを歩み始めます。
新しい課題を進めている間に、終えたはずの旅が復活します。
検証の結果、狙った結果が十分に得られていないケースです。
これもまた新しい始まり。
サービスを成長させるドライバーになる課題を優先的に、力の持てる限り任務遂行にあたります。
押し寄せてくるサプライズクエスト
「一つの課題に集中して取り組みたい、けど並行して課題を進めなければユーザーに満足のいく体験をサービスを提供出来ない。。うおおお！やったるー！」と息巻いている状況に拍車をかけるように、サプライズクエストが発生します。
それはごく当たり前の日常かのように、誰かが昨日見た夢を話すかぐらいのテンションで発する一言だったりもします。
誰か「○○をすることになったので〜( ´ ▽ ` )」
わたし「！？！？！？！？！？！？！_:(´ཀ`」 ∠):」
ぐらいの温度差。
・こういうことができるかもしれない！この波に乗るためにこういったクリエイティブを作って展開しよう！これはチャンスだ！
・まずい、ここの機能がこれぐらいのユーザーにすごく不評だ。すぐに改善した方がいいのではないか？
・外部でこういう動きが出てしまった。すぐに対処しないと。
あの時立てた計画が、、、もう母群が別物。。。
もう一回スケジュール立て直す？そんなことやってたらスケジュールを365回作って一年が終わってしまう。
最初に計画を立てた時には想定されていなかった話。差込がなければベストですが、なかなかそうもうまくいかず、元ある計画から常に計画をアップデートする必要があります。
プロダクトのグロースに携わる偉大な方々のnote
この記事を書いていてちょくちょく思ったこと。 「どこかで見たことある内容だ。」
自分自身で経験して学んだから紡げた言葉もあれば、誰かの知に触れて言語化できたり、自分が学べていなかった思考や意識、行動をインストールすることができたり。
「あー、あの人の記事のあの内容が頭に浮かんでるなー、すごいなー」と思いながら、書いていました。
既知の方も多くいらっしゃると思いますが、確実にためになる知の資産なので、残しておきたいです。
フリッツさん：プロダクトの成功に必要な 3 つのステージと 20 のタスクについて：現場の動き方をまとめました
日常的にどれだけ考えていればこんなに言語化できるんだろうと思う記事でした。テキストみるだけで普段の思考量がきっと膨大なんだ、と感じます。
樫田光さん：UIデザインとデータ分析の近接点
デザインを考えることとデータを読み解くことの思考方が類似していることが文才によってとってもわかりやすく書かれている。この方の文章がとっても面白いです。硬く書くと、とてつもない密度に面食らいそうな内容がスルーっと入ってくる感じ。それも経験と知識量から得たセンスなんですねきっと。
デザイン/データ/エンジニアリングだけでも勝つことが難しい現在に求められるスキル
「いいものを作るか、いい売り方をするか」みたいな話は、いろいろな見方があって成功体験によっても違うので、ひとつの正解はないと思うのです。
僕としては「手を取り合って、みんなで束になって取り組まないとなかなか勝てない。1人で完遂するにはさすがに人間の脳のキャパシティを超えてるんじゃないかと思う量だし、1つの専門性だと限界がある」と考えています。
デザインとエンジニアリングは横断する話が先行して進んでいると思うのですが、デザインとデータはまだ横断されることが少ないかもしれない。
デザインに携わる方にとって、データを横断して一本の束になって考えることで、よりサービスの成長とユーザー体験を考えらえるのではないかなと思います。
さいごに
サービスを成長させるプロセスの成功体験、アプローチ方法は星の数ほど存在すると思うので、そういった意見の交換ができると嬉しいです。
当社はまだまだ成長過程どころか産声をあげたのもつい先日の話、のような若い会社なので、もっともっといろんな知に触れていきたいです。
意見交換や当社とのお仕事、もしかしたら働く環境として興味を持ってくださる方、新しい発見を見出してくださった方が誰か1人でもいらっしゃれば、ぜひお声がけあるとうれしいです。
UXUIデザイン支援資料
セブンデックスのUXUIデザインプロセスと実績詳細が解説されている資料を無料でダウンロードできます。
