見出し画像

【良いUIUX≠いい施策】渾身のUIUXが却下になった話【デザイナー×PdM視点】

こんにちは、サービスデザイナーのひるかんです!


今回は持論の研究発表です。

ちょっと最近、「AI時代においてデザイナーはどうすべきか?」というテーマのLT会に参加しました。

そこで私は「デザイナーもPdM視点を持とう!持つにはどうしたらいいか?」という内容を話しまして、それに向けてした「デザイナーとPdMの持つ視点の違いの分解と整理」をここでも発信しようと思います。

ぜひ「もっとこうしたら?」「こうなんじゃない?」って感じのコメントがいただけると嬉しいです。

そもそもなぜデザイナーがPdM視点を持つと良いのか

デザイナーとしていろんなUIや施策を提案していると、PMやエンジニア、あとはクライアントのPOやPdMなんかと「同じ企画を見ているはずなのになぜか微妙にすれ違う」「お互い悪気はないのに、話が噛み合わない」…みたいなこと、よくありませんか?

今はUX施策の体験の良し悪しを話したいのに「それどうやって実装するつもりですか?」って聞かれるとか。
デザインのコンセプトの話をしたいのに「ここにこういう文言を入れて欲しい」ってフィードバックされるとか。

こういう不和をデザイナーの目線ではなくもっとフカンした目線から解釈できないか、解釈できるならスマートに対応したり未然に防いだりできるのではないか?

というのがこの研究の発端でした。

【実体験】渾身の提案が没になった1年目

この「他職種との微妙なすれ違い」に初めて直面したのは私が新卒1年目の後半の時でした。

クライアントワークのUIUXデザイナーとしてキャリアを始めていた私は、
上司から「このメーカーの自社ECをリニューアルするから、追加で改善すべき施策・コンテンツ・UIを提案してみろ」というミッションを拝命しました。

大学4年間デザインをやってきて、インターンもしてきた身としては、とうとうきたか俺の時代、ばりに思ってました。裁量って興奮しますよね。

競合サイトや類似サイト、別業界のサイトまで山ほど見て、いくつか施策を提案しました。中でも自信があったのが、商品スペック比較ページです。

メーカーECってスペック違いで細かく商品が分かれててわかりにくかったりするので、スペックを一つの画面へ並べれば、ページを行き来せずに違いを確認できる。違いが分かれば、自分に合う商品も選びやすくなるはずです。

実際ゲーミングPCのECではなかったですが、こんな感じのUIです
こんなん絶対実装したほうがええやん!

しかしスペック比較ページ案は社内レビューで実装に至りませんでした。

他職種にされた「画面の外側へのフィードバック」

社内でレビューをお願いした上司やPM、先輩デザイナー、エンジニアから返ってきたのは、UIデザインへの否定ではなく、「それをやると何が良くなるんですか」「それ、誰がどう運用するんですか」という、画面の外側についての質問でした。

新進気鋭のデザイナーはうまく答えられず、「たしかに!!!!!!ダメじゃん!!!!!」と崩れ落ちるしかありませんでした。

施策提案に必要な三つの観点

当時された指摘を今整理すると、大まかに三つの観点でした。

  1. 比較ページによって商品理解が深まっても、購入率や客単価の向上につながるとは限らない。むしろ違いが小さいと分かれば、安い商品へ流れてしまう

  2. 利用者が知りたいのはスペックの違いではなく、自分にはどの商品が合うのかという答えではないか。比較ページは判断材料が増える一方、意思決定のコストも上がる。

  3. 商品ごとに異なるスペックを共通項目へ整理し、登録する労力が莫大。データベースとECの接続をして自動更新にするには今回の予算内では対応できない

私の提案はどう見せれば比較しやすいかを考えたものでしたが、
そもそもなぜ比較するのか?このECでどんな購入体験を作りたいのか?画面の裏側の仕組みをどう動かすのか?までの検討が漏れていました。

漏れたというより、そもそも考えないといけないことを知らなかった=観点が足りていなかったのです。

そうか、そこまで考えないとダメだわと蒙を啓かれました。

無知蒙昧を啓かれたイメージ図

このときの指摘を一過性の失敗談で終わらせず、次に同じ墓穴を掘らないための体系にできないか。
それが今回の研究の出発点です。

プロジェクトをフカンするBTC解釈

noteや書籍、色々な方の発信から最初「これかも」と思ったのが、Takramの田川欣哉さんが紹介しているBTC型人材の考え方でした。

BTC型人材とは単に1つの専門性を深めるだけではなく、Business、Technology、Creativeの三領域を横断・統合して新しい価値やイノベーションを生み出す人材を指します。

「こういう越境人材になろう!」って提唱がされるということは翻って「通常、意識していないと飛び越えにくい溝が領域間にある」と解釈できると思いました。

それぞれの領域の人は大事にしたいものが違う

実際、この考え方を頭に置いておくと、他職種からのフィードバックや調整に一定の理解ができるようになりました。

当時スペック比較UIにもらったフィードバックの観点もこの3つに集約されました。

こう見ると新進気鋭のデザイナーさん、
クリエイティブ領域もマトモにできてない(反省)

それまで「要求イメージを探るワイヤーフレームなのに今データベースの仕様の話で横槍入れないでよ、、、」と思ってましたが、
「ああこの人はT寄りの考えの人なんだな」と理解でき、それをもとに「確かにそのデータベースでは難しいかもですが、同じ提供価値をもたらすこの案なら運用でカバーできる範囲じゃないですか?」みたいな話ができるようになりました。

「ここでデータベースの話するこの人は何もわかってないな、、、」って思って言動に現れてしまうだけでプロジェクトは円滑さを一気に失います。

AI時代でも人同士がコミュニケーションして仕事をする限りは誰かの大事なことを理解して思い遣って働くことの重要さはあり続けると思います。

そんな思いやりをBTCを知ると持ちやすくなる。
他職種の指摘を自分の専門外から飛んできた横槍ではなく、企画を成立させる別の判断として受け取りやすくなります。

対応と予防のための五つの情報階層

BTCだけでは理解できても行動に移しづらい

ただ、BTCにも限界がありました。
それはフィードバック受け取る前に予防したり事前交渉したりができないことです。

そこで情報階層

そこで、自分のこれから行う活動に対して、
「前提として考慮しておくべき項目」
「成果物が影響を及ぼし、制約や発見を返してくる項目」
に整理のフォーカスを当ててみました。

それが「背景と環境」「顧客と事業」「体験と接点」「提供と実行」「学習と改善」の5階層です。

これから体験設計を考える人は、「顧客と事業」を理解し、作った体験設計が「提供と実行」に影響する。みたいなイメージです。

こんなイメージ

この階層を意識すると、
「これを依頼されたということはあれが先に決まっているはずだから、作業する前に確認しよう」とか、
「これを決めると誰かが見ているこの階層に影響するから、先に無理がないか確認しておこう」という動きができるようになります。

元ネタ

コンセントの大﨑優さんがnoteで紹介していた、「デザイナーが営業をするときに事前リサーチすべきレイヤー別項目」から着想を得ました。
激面白いのでおすすめです。

そこへさらにHCDの循環プロセスと組み合わせ、自分の実務に合う五階層へ再構成してみました。

BTC×情報階層、15マスのマトリクス

プロジェクトをBTCでフカンし、情報階層で過去と未来を見通す。

この二つを重ねると、五階層×BTCの15マスのマトリクスになります。


このマトリクスは、15マスを埋めるためのチェックリストでも、一人でカバーするためのものでもありません。

自分の案の現在地から、前提、影響範囲、相談相手を探すための見取り図です。

前提、影響範囲、相談相手の探索をする

使い方

自分の作業を起点に置く
まず、自分がいま考えている案や作業がどのマスにあるかを置きます。

前提をたどる
起点に対して上位の階層へ戻って自分の作業は何の情報を前提として進めるべきか?を確認する。

影響と制約をたどる
起点に対して横と下の階層へ広げて自分の作業がどこへ影響するかを確認する。

不明点と相談相手を決める
「前提情報が足りない」「どんな影響があるかわからない」といった困ったことが起きたら情報を持つ人を探して聞きにいく。

次の行動を決める
調査、相談、試作、見積もりなど、意思決定に必要な活動を見つけて行う。

マトリクスは、施策を作るとか作業をするのではなく、今自分の作業において何がわかっていて何がわからないのか/何が分からないから今自分の判断できないのか、といった「次に誰と何を確かめるか」を考えるための地図です。

例えばC3 体験設計の「カスタマージャーニー」を考えるとき

上のレイヤーのB2、T2、C2を前提にする

前提が違うと見当違いの体験設計が出来上がってしまいます。

B2 事業設計
→対象顧客や事業モデルを無視したカスタマージャーニーを作っても通りません。

T2情報基盤
→ユーザーからデータを取る・取ったデータを使う前提でカスタマージャーニーを描かないと良い体験に繋がりません。

C2顧客価値
→カスタマージャーニーは顧客価値へ到達をするまでを描かないと書けません。

左右のレイヤーのB3、T3

同じ3行目はお互いに影響を及ぼし合うため調整が必須です。

B3成果への筋道
→道筋をカスタマージャーニーで設計するとも言えますし、成果指標度外視のカスタマージャーニーは良いものとは言えません。

T3接点の成立条件
→T3の現実的な制約がカスタマージャーニーに影響しますし、カスタマージャーニー次第で接点が変わります。

影響を受ける下のレイヤーB4、T4、C4

どんな影響を受けるか、現実問題無理な場合どう調整するか、判断が必要になります。

B4マーケティング活動
→体験設計によって決まる集客/送客/顧客等の接点施策が決まるものもあります。体験設計を無視したマーケティング活動はたいていうまくいきません。

T4 技術的な提供/C4 制作と実行
→体験設計が終わらないと何を制作・実装するかが決まりません、たとえ良い体験設計だったとしても途方も無い時間がかかる制作・実装だった場合、実現されません。

商品比較ページに欠けていた接続

当時の商品比較ページは、C3 体験/接点設計の中でも、スペックを一覧で見せるUIから検討を始めていました。

そこから前提へ戻ると、

  • C2 顧客価値にある、利用者は何に迷い、何を基準に選んでいるのかが未確認

  • B2 事業設計とB3 事業の成果への筋道にある、このECでどんな買い方を作り、比較体験をどの成果につなげるのかが曖昧

といった問題がありました。

また、影響範囲をたどると、
T3 接点の成立条件にある比較機能の要件、T4 技術的な提供にある更新方法がつながっていませんでした

さらにB5 成果評価と投資判断、T5 計測と品質改善、C5 顧客/体験からの学習まで見ると、
当時フィードバックはもらいませんでしたが、何をもって成功とし、結果から次の判断をどう変えるかも提案の中に含むべきでした。

こんな感じで前提情報の不足と後工程の影響の検討不足が悪かったんだよな、と整理がつきます。

前提情報があるのか?影響検討した結果どう動くか?

これらの前提情報と影響検討について考えられると、次のアクションの想定ができます。

  • 顧客が本当に比較で困っているかまだ分からなければ、先にC5で調査やプロトタイプ検証

  • 必要性は確かでも全商品のデータ整備が重ければ、一カテゴリに絞って手作業で試す。

  • 比較しても選びやすくならないなら、用途から候補を絞るページ等の別の体験設計を検討する。

  • 成果に対して費用が見合わなければ、作らない判断をする。

このような感じでこの15マスはBTCそれぞれの影響範囲を明らかにし、B人材T人材C人材が適切な連携コミュニケーションと意思決定ができる状態を目指すためのものです。

このコミュニケーション全体のバランスを見られる視点こそが、PdM視点なのではないかと思います。

AI時代、C領域から意思決定根拠を作る能力の重要性は上がる

マトリクスを紹介した時に「この15マスを一人で埋めるものではない」と言いましたが、C領域の特定の作業のみ行う人間はAI時代かなりしんどくなってくる人が多いはずです。

AIによって、プロダクト運営に必要な役割のうち何役か兼任できるようになってきているためです。

そこで私は特に力を発揮できるのは、まだ想像で語られている顧客と体験について判断根拠を作る場面なのではないかと考えています。

利用者は本当にスペックを見比べているのか。どの場面で迷い、何を基準に商品を選んでいるのか。比較画面を見せたとき、違いを理解できるのか。理解した結果、選べるのか。それとも余計に迷うのか。

インタビュー、行動観察、プロトタイプ検証などを通じて、C5 顧客/体験からのインサイトを集められます。
そのインサイトをC2 顧客価値やC3 体験/接点設計へ渡すことで、体験案を選ぶ判断根拠を作成できます
たとえ結果が作らない判断もプロダクトの前進です。

もちろんC領域だけで意思決定ができるものでも無いのでB領域やT領域のマスの検討事項とつなぎ、複合的にPO/PdMたちと判断する必要があります。

「何を作るか・作る意義があるか?を確かめることができる」
デザイナーがPdM視点を持つことで広げられる役割だと思います。

この「PdMや意思決定の支援をするデザイナー」についてはさらにどんな能力を発揮すべきだろう?なぜデザイナーがやるんだろう?という話について別のnoteでまとめてます。

このnoteで語ってる「別分野への染み出し・いっちょ噛み」もこの15マスを地図にすればやりやすくなるかも。

まとめ:15マスを地図に、自分の認知の範囲を広げる

自分の案が依存する情報を見つけ、詳しい人へ相談する。
相談するときも、何となく意見をもらうのではなく、どの前提を確かめたいのか、どこへの影響を知りたいのかを伝える。

そのやり取りを重ねると、次からは他職種が気にする条件を先回りして考えられます
自分で仮説を置ける範囲が広がり、専門家にはゼロから考えてもらうのではなく、自分の判断仮説を確認してもらえるようになります(提案型質問、というヤツ)。

目指したいのは、「一人で判断できる/できない領域を見極めた上で自分が取りたい責任の範囲が広い人」です。

協働は「わからないことを誰かへ任せる」ためのものではなく、
他職種の判断を学び、自分で見渡せる範囲を広げる機会」として糧にしていきたいですね。

デザイナーがPdM視点を持つとは
正解のUIを検討するところだけでなく、提案の前提・影響範囲・相談相手を見つけ、作る/作らないを判断できる広い視野を作ること」なんじゃないか?
というお話でした。

おまけ:15マスのマトリクスはあくまで研究途上

このマトリクスは使うたびに境界の曖昧さや、別の見方が必要な場面、検討の順序がキモになるケース、など例外がちょいちょい見つかります。

更新があったらまたnoteにしたりどこかのLTで登壇したりします!


いいなと思ったら応援しよう!