CocodaやCocoda Boardを運営するalmaのkenjiです。エンジニアやデザイナーを経て、現在はプロダクトマネジメントやマーケティングに関わっています (所属はMarket Research)。
今回は、先日リリースしたCocoda Boardというユーザー体験管理ツールについて、その検証プロセスをまとめたいと思います。
▼ 前提：Cocoda Boardについて
▼ 読む時の注意点
- 当時の仮説や進め方を、なるべくそのままに記載しています。最新状況とは違うポイントもあると思うのですが、あえて当時のままリアルに残しています (最新状態は直接お話します)。
- 特定の誰かや、プロダクトを否定・批判する意図は一切ありません。全て実験とそれを通じた発見として記載しています。
ハイライト
実は、このCocoda Board、構想から検証、仕様を固めて1stリリースまで、全部含めて3ヶ月以内で行いました。
早かったことに加えて、リリース後はかなりのペースで導入が進んでいます。これまでのプロダクトづくりと意識的に変えたポイントは以下です。
1. 超具体のユーザー行動を集めて、可視化する
2. 既存のやり方や、アプローチ、風潮に対して、アンチテーゼをつくる
3. 出てきた仮説は、段階的なプロトタイプを通して、細かい仮説に落としていく
ここからは、超具体的にCocoda Boardというプロダクトの検証過程を、そのままに記載しながら一貫して活躍したプロトタイプの存在に触れていきます。
きっかけは採用事業の伸び悩み
もともとは (特に事業会社において) 「デザイナー採用がうまくいかない」との声を多く聞いていたことから、デザイナー採用に関わるプロダクトをつくっていました。
👆 当時の検証用LPの1パターン
一方で、検証を進めていく中でインハウスデザイナーが働く環境には以下のような課題があることに気づきます。
- (特に採用の場面で) インハウスデザイナーの役割を十分に定義できてないことが多く、「UIもできて」「グラフィックもできて」「チームもつくれて」みたいなスーパーハイレベルデザイナーを求めてしまう傾向にある
- 各社によってデザイナーの役割・活動範囲はかなり異なる。制作に近いデザイナーもいればプロダクトマネジメントまで行う場合もあり、 (採用基準が高い上に) フィットするかどうかは非常に判断しづらい
また、「インハウスデザイナーがそもそも少ない」という問題もあり、採用プロダクトというアプローチだけでは、デザイナーの働きやすさも採用したい企業が求めていることも満たしにくいなと感じました。
※ 簡潔な文章にするのが非常に難しく、「なぜ採用事業をやめたのか」についてはまた詳しく触れたいと思います。
構想中期：課題の構造を突き止める
「チームに人を入れていく」(=採用) だけでは、解決しなかった「そもそもデザイナーの要件が高くなりすぎ問題」を解決するために、主にインハウスで、プロダクトに関わるデザイナーが絡む周辺のワークフローを調査しました。
要件定義などいわゆる上流部分をリサーチしていた時の整理
すると、徐々に「デザイナーの要件高すぎ問題」の根本原因が分かってきました。つまり、プロダクトマネージャー・ディレクターがやろうとしていることや仕様を翻訳して画面やグラフィックに落としていくような、翻訳/コミュニケーションが (特にインハウスの) デザイナーに求められていたのです。
プロダクトの立ち上げに多く関わったようなベテランデザイナーがやっていることもリサーチすると、やはりPMや企画の意図を汲み取り「ユーザーはどう感じるか？動くか？」に変換できていることを観測。
雑な整理ではありますが、上記のようにfigmaや付箋、紙をつかって、とにかく課題の根本を可視化していきました。
構想後期：資料を通した検証をしてみる
構造がわかってきたら、プロダクトのプロトタイプではなく、まずは営業資料をつくってみて「価値のプロトタイプ」を作成してみました。
資料は何パターンかつくってみた中の一例ですが、まずは「課題・シーン」「価値」「ざっくりプロダクト像」がフィットするのかを検証するために、営業資料での検証を進めました。
この時につくるUIプロトタイプも、あくまで「資料を通して価値を想像できるか」を重視して作成していました (なので、実際よりもオーバーにつくってみていました)。
また、この時期には、共通した綺麗な (綺麗に言語化された) 課題も見つからなかったので、企業ごとに個別に提案資料を作っていました。
(資料はfigmaで作っていました)
結果新しく分かったのは「ユーザーの声をUIやグラフィックなど具体物に落とす役割 (翻訳係) が社内にいないことが多い」ということでした。それもあり「デザイナー要件高すぎ問題」につながっていくのだと考えました。
「人がいないなら、なんとかプロダクトで解決できないか？」と考えて、プロダクトに落とす闘いが始まります。
UIプロトタイピング期：課題⇄解決策を行き来
資料レベルで、「ここが悩みだったんです」「使ってみたいので費用とか教えていただけますか？」と、前のめりな姿勢が観測できたら、徐々にプロダクトのプロトタイプへ。
ステップに沿って情報を入力すると良い感じにペルソナやジャーニーマップにまとめてくれるサービスをつくってみたり
KPIごとに、検証項目を可視化できるようなものをつくってみたり
ユーザーインサイトと施策を並列で出せるものをつくってみたり。
取り組む問題も見えてきていたので、この段階ではとにかく具体物を見せてみて、初めて浮かび上がる課題もあるので、とにかくつくって当ててみる、ことを繰り返していきました。
UIレベルのプロトタイプをつくるときでも、もちろんデザイナー以外も参加し、(紙に書くような) ラフプロトタイプから、figmaでつくるようなプロトタイプまで、幅広くつくっていました。
デザイナー含む4人でfigmaでつくったプロトタイプは見返すと、約20パターンありました (懐かしい...)。
余談ですが、ある程度方向性が見えてきて、プロダクトを模索している時期に、プロトタイプを作りまくる時間を取りたくて、メンバーで合宿もしました笑
(何も分からなくなって、マスクしてiPad持ったまま鎌倉の海で黄昏れる @yokinist の図)
UIプロトタイプレベルでフィットしたら、コンセプト (アンチテーゼ) を固める
資料での検証、UIプロトタイプでの検証と、徐々に解像度を上げていきながら、検証を進めていき、はまるプロダクト像が見えてきたら、再度コンセプトを固めました。
実際の提案資料の一部ですが、コンセプトは、時代感やユーザーの課題 (願い) を踏まえて、「なぜこのサービスが必要か」を語れるものにしました。
コンセプトが決まると、プロダクトの仕様面においても、「何を捨てるか」「どこまで磨き込むか」が明確になります。
また、僕らは、コンセプトがふわっとしないように「時代やこれまでの風潮に対しての主張」という意味をこめて、コンセプトのことをアンチテーゼと呼んでいたりします。
仕様に落とす期：「MVP」を定義
徐々にプロダクト像・コンセプトが明確になってきたら、細かな情報設計や実装準備へと入っていきます。
新機能や新サービスの開発を始めるとき、往々にして仕様はモリモリになりがちです。
これまでも僕らも同じようにモリモリになり、都度話し合いをしていましたが、今回はアプローチを変えてみました。
MVPは、Minimum Viable Product の略ですが、「何に対してのミニマムか？」をチームで揃えることで、仕様モリモリになる問題を回避しようと言う試みです。
解決したい課題を分解して、細かな課題ごとにレベルわけをして、段階的に課題の全貌を解決していこうとしました。
実際に当時、MVPを定義するために、解決すべき課題に順番をつけ、順番が進むほどプロダクトのレベルが上がっていくように、ロードマップらしきものをつくってみました。
(alma社では、光明が見えた、的な意味で :mieta: スタンプが使われています)
チームも好反応で、今でも、このレベル分けロードマップが使われています (内容は大きくアップデートされています)。
開発期：UI制作と開発と追加検証の3ラインを走らせる
課題が明確で、プロトタイプ (解決策) も明確なものから開発を始め、課題が不確実なものや、解決策が不明瞭なものは追加で検証を行い、ロードマップへの反映を行っていきました。
開発もかなりスムーズに進んでいたのですが、詳しい話はエンジニアリングをリードした @yokinist に譲ります。
こうして、プロダクトは3ヶ月でリリース、β版の登録も順調に伸びており、正式リリースに走っています。
さいごに：全員プロトタイプつくるの、超大事
デザイナーの強みが可視化であり、具体物に落とせることであるというのはよく言われますが、紙芝居や、資料に落とす、ラフなスケッチをつくる、というのは、練習をすれば比較的誰もができることかなと思っています (巧拙はもちろんありますが)。
むしろ (目線が揃っている場合) デザイナー以外もプロトタイプをつくった方が、改善速度やアイデアの幅が圧倒的に増えると、今回のリリースを経て感じています。
そして、個人的な感想ではありますが、「頭ではうまくいってるけど、つくってみたら、なんか違う」こともよくあったので、企画担当やPMなどは、アイデアがあったり声を聞いたりしたら、 (少し粘って) 形にまで落としてみると「うまくいきそうか」がより鮮明に判断できると感じました。
目に見える形に落としてみて、自分たちもしくはお客さんに「課題が解決された場面」を想像してもらえるようにすることがプロトタイプの本質だとしたら、デザイナー以外もプロトタイプつくれることは、事業にもチームにもすごく価値あることなのかもしれません。
ビジネス職・技術職ともにプロトタイプの具体的な進め方や壁打ちなど、いつでも相談に乗るのでいつでもご連絡ください！お茶しながらゆるりと話しましょう🍵
シェアする
