UIUX デザイナーと仕事をする際にプロダクトマネージャーとして持っておきたい 8 つのマインドセット

2020 年に入り、メルカリ US ではプロジェクトの担当 PDM を検討する際に「UIUX に大きな変更が入るならこの人」「関係者マネジメントが重要ならあの人」「テクニカルな知識が要求されるならこの人」といった具合に、プロダクトマネージャーそれぞれの特性・得意分野を考慮したうえで決定する傾向が以前にも増して強くなりました。

その結果、自分（フリッツ と申します、こんにちは）の場合は UIUX 改善を中心としたプロジェクトが相当に増え、並行して 3-4 名の UIUX デザイナーとそれぞれのプロジェクトについて議論することが毎日の風景となりました（めっちゃくちゃ楽しい）。

こうした状況下にあって、あらためて デザイナーと UIUX について議論・もしくはフィードバックをする際に気をつけている・気をつけたいことについて前後編にわけて振り返りをしたので共有してみたいと思います：

・前編（この記事）：全般を通して意識したいマインドセット 8 個
・後編：現場で意識したいヒント（ハック？） 20 個
後編は執筆中、近日公開予定。

00# なぜこれが大事なのか

他の多くの職種同様、UIUX デザインにも 明確な「正解」はありません。決断の材料となる分かりやすい数字は存在せず、ユーザーインタビューやユーザビリティテストはあくまで n=x であり、これらを覆してでも異なる UX を採用することが結果的に正となる場合もあります。A/B テストの結果に有意差が見られず、最後は責任者の「鶴の一声」で採用案を決定しなければならない場合も多々あるでしょう。

UX を定量的・客観的に決定しようとする試み・方法論 (例) も多く出てきていますが、依然として意思決定者の主観的な意見が簡単に入り込みやすいのが この UIUX デザインという領域。Twitter ではいまでも『なんか違うんだよねぇ。もっとパンチのくるデザインない？』『A 案より B 案が好きだなぁ！でも A 案のここを B 案に取り込んで！』といった江戸時代？のようなフィードバックに対するデザイナーの怒りの声をちょくちょく見かけます。

こうした プロダクトマネージャー（もしくは意思決定者）とデザイナーとのコミュニケーションの質がそのまま UIUX の質に大きな影響を及ぼす この領域では、より良い議論の形・フィードバックの形について試行錯誤することが非常に重要になります。ので、長い間このエリアに集中してきた自分なりの考えを共有することで、どこかの誰かさんと、どこかのチームさんのより良い協動にちょっとでも貢献できれば幸い。

ということで、UIUX デザイナーとより良い議論をするために・より良いフィードバックを提供するために、8 つほど自分が大事にしていること：

01# 信頼関係を作る

PDM と UIUX デザイナーの経験値のそれぞれの関係性は、コミュニケーションの質に大きく影響します。熟練PDM x 新米デザイナーの場合は前者が必要以上に大きな影響力を持ってしまい、また、新米PDM x 熟練デザイナーの場合は、PDM の未熟なフィードバックはほぼ無風に近いものとなり、何の役にも立ちません。

いずれの場合においても、どちらかの独りよがりの UIUX が世に出ることを防ぐためには、率直な議論・フィードバックを双方で行えるような信頼関係の構築が必要不可欠になります。

PDMならではの武器を以て（頻繁なユーザーインタビューからのインサイト提供・BIとの連携によるデータ提供・問題の明確化など）デザインプロセスに寄与することで信頼関係を形作ることもできますし、またはデザイナー以上に泥臭く UX 調査を行い、近い目線で議論できる壁打ち相手となることで信頼を勝ち取る方法もあります。ここは多分方法は千差万別…

ただ、どの場合にも共通して言えるのが「簡単に主観でモノを言いやすい」UIUX の領域において、「あくまでもデザインのオーナーシップはデザイナーが持っている」ということを PDM として強く認識・実践しておくことが最も重要だと言えます。

逆説的ですが、基本的には後述していく # 02 - # 08 を何度も何度も繰り返して実践することで「デザイナーにとって有益な議論・フィードバック」の量を増やし、逆に、「やってはいけないフィードバック」の量を極限まで少なくするのが信頼関係構築の一番の近道じゃないかな、と思っています。

02# PDM にも宿題があることを認識する

プロダクトマネージャーとして少しでも建設的な議論をデザイナーとできるように、問題定義・プロジェクトブリーフィング等の基本的な職責以外にも「済ませておける宿題」があるよね、と自分は考えています：

1. 短期特化で一気に競合の同じような画面をインプットする
2. 自分なりのぼんやりした UX 案を 3 つほど持っておく
3. その他の関連資料にあたる

というアプローチが主。②③を毎度やるのは中々大変ですし、あと、「済ませておける」なので、必ず毎回「やらなきゃ！」と気張るようなものではない、というのがポイントかと思います。

1. 短期特化で一気に競合の同じような画面をインプットする

例えば、検索結果画面の改善プロジェクトを UIUX デザイナーに依頼した場合は、デザインの初回レビュー前までに自社の画面・競合の画面を 7-10 個程度ガッと見ておき、共通要素・それぞれの短所と長所を把握します。細かくメモを取ったり比較する時間はないので、ぼんやりで大丈夫。

多くの場合、デザイナーは同等かそれ以上のリサーチを行った上で UIUX デザインを創り、初回レビューに臨んでいます。が、PDM がこの宿題を事前に済ませておけるかどうかで議論の質が圧倒的に異なってきます。

2. 自分だったらどうするか？ UX 案を 3 つぼんやり考えておく

① を済ませておくことで、意外にすんなりと「こんな UX ありえそうだよな～」というものが 2-3 つ程考えることができるはず。可能であれば、まったく違う方向に振り切った・極端に異なる UX 案をイメージできればベスト。

ワイヤーフレームまで作る必要はありませんが、ざっくり、例えば：「２カラムでこっちにこの要素、あっちにあの要素ってアリだよな」「各要素に情報をたっぷり乗せたバージョンのメリットはこれ、削ったバージョンのメリットはこれ」「むしろここの UX は切り出して別画面でも良いかも」といったいくつかのアィデアを持っておくと、議論のタネになります。

デザイナー自身も様々な方向性に振った 2-3 案を提示してくるのが弊社の常ですが、自身の宿題を済ませておくと、多くの場合それらとは異なる「もうひとつの可能性」をデザイナーに提示できるチャンスを作り出すことができるようになります。繰り返しますがここもざっくりで大丈夫。

3. その他の関連資料にあたる
なかなか自分もできていないので自戒を込めて…

3-1. データ分析
プロジェクトに関連したページの機能のそれぞれがどうユーザーに使われており、どこがあまり使われていないかといった「機能の優先度」の解像度をあげておくことで、UIUX 案に対して客観的なフィードバックを行う事ができます。ブリーフィング時点でそれらの情報がすべてデザイナーに伝わっているのが理想ですが、現実の場合は後追いで情報を提供することが多い。

3-2. インタビュー分析
プロジェクトに関連するユーザビリティテストを事前・デザイン中に行えればベストですが、毎度毎度はできないのも現実。せめて、余裕があれば過去の関連したユーザーインタビューを読み込んでおき、議論のタネを持って行くということも「済ませておける宿題」のひとつのはず。

3-3. オンライン記事の読み込み
検索画面・ホーム画面といった要素ひとつひとつを取ってもインターネット上には沢山のリサーチ・論文・記事が散らばっています。机上の空論でしかなく、実戦には使えないものも沢山ありますが、塵積山。僕は ニールセン博士の Alertbox (日本語) の記事をよく読んでいます。めっちゃ面白い。

03＃　デザイナーの思考プロセスをトレースする

実際に UIUX 案をデザイナーと議論する際、アウトプットとして提示された UIUX 案に反応するのは後回しにして、まずは、そこに至った過程・デザイナーの思考プロセスを理解することに注力するべきです。

多くの場合、PDM がデザイナーから提案される仮案・最終案の背後にはボツとなった廃案が大小山をなすほどに転がっており、その多くはなんらかの理由によって意味があって却下されたものがほとんど：

なので、「この案よりこっちの方が良くないですか？」ではなく、「なぜ A 案ではなくB 案がオススメなんですか？」「なぜ、ここではこの UI ではなくその UI を採用したんですか？」といった、「なぜ？」を質問の中心に置き、デザイナーにその思考プロセスを説明してもらえるような質問を繰り返すことに集中します。

こうすることで、① プロダクトマネージャーとしては UX の表層ではなくその骨格を次第に理解することができるようになり、デザイナーと近い目線に立って議論することができるようになる ② ボツ案をいちいち再度ほじくり返すような時間の無駄が逓減する ③ デザイナーとしては自らの思考を再度トレースすることで、漏れていた方向性やアィデアをよりストレートに自身の視野のうちに捉えることができるようになるはず、です。

04# フィードバックではなく、「議論」を意識する★

数十秒眺めるだけで誰でも簡単に「好き・嫌い・こうしたい・ああしたい」という主観に寄った意見をインスタントに持ててしまう・言えてしまうところに、デザインフィードバックというものの難しさがあります。

誰しも自分なりに「好き・嫌い」を判断することはでき、それも n=1 で正解です。しかし、今まさにあなた・僕が数十秒眺めただけで「フィードバック」をできてしまえそうなその UIUX は、実際には「プロ」が何日間・何週間にもわたって集中してリサーチを行い、考え、試行錯誤し、創り上げた「問題に対する解決案」であることを忘れてはいけません。

なので、ド素人の僕らは「フィードバック」という的外れな考え方を持つのではなく、「ここについて議論したいのですが」というマインドをもってデザイナーと対峙することが重要なのかな、と思っています。8 つのマインドセットの中でたぶん一番大事。なのでタイトルに ★ をつけました。

① 自分なりに変えたいものリストを乱暴にぶつけるのではなく、質問する。　② なぜそこに至ったのか？その思考プロセスに漏れは無かったか？を一緒に確認する。　③ より良い選択肢としてどのような UX がありえるか？を競合を例に議論する。　④ これで本当に問題を解決できるのか？について「悪魔の代弁者」アプローチで一緒に見直す。

などなど、方法は様々ですが、こういった姿勢で UIUX デザイナーに対峙することで、より良い協働を行うことができるようになるはず。

（「フィードバック」ではなく「議論」：を繰り返し意識し続けると、ある時点を超えたところで、逆に「ここについてどう思いますか？」の質問回数が急増する＝デザイナーの信頼を勝ち取れている、はずです。たぶん。）

05# こうしてほしい・こっちが好きです、は最悪

プロダクトマネージャーもいちユーザーなので、感覚論で UIUX の細部について何かを思う・言いたくなることは当然あります。

「個人的にこっちが好き」「なんかこっちは気に入らない」「しっくりこない…」「この要素、こっちの場所に置いたほうが良いと思うんだよなぁ」「なんかダサくない？」「古くない、このデザイン？」

しかし、その感覚自体は正だとしても、それをその感情のままに伝えることはデザイナーとのコミュニケーションの中で最もやってはいけないことのひとつ。頻繁に繰り返してしまうと、せっかく長い時間かけて作り上げた信頼関係を壊してしまうことにもつながります。

①「しっくりこない」ことをそのまま伝えても、デザイナーは何を修正するべきかがわからず、混乱させ、いたずらに作業工程を浪費させてしまう
② 長時間かけて練り上げた UIUX を「なんか違う」の『感覚』で否定されるのは最もモチベーションをさげるフィードバックのひとつ

なので、UIUX を眺めながら湧きでてきた「感情」に対しての「理由」をうまく言語化できない場合は、それをぐっと飲みこんでその場で伝えるのは諦める。のちのちの検討を経て、しっかりと自分の「感情・なぜそう思うのか・なぜそうして欲しいのか」を言語化できるようになった段階で、改めて議論に持ち込むことで、より正確に自身の意図を伝えることができるようになるはずです。急がば回れというやつ。

06# 解決策ではなく問題にフォーカスする

UIUX についてデザイナーと議論するのは楽しいですし、良い議論ができれば最終的なプロダクトの品質も向上します。が、あくまで PDM は「解決策である UIUX それぞれ」ではなく、「これは解決したい問題を解決できているか？」という視点にこだわって思考・議論を進めるべきです。

解決策に飛びつくようなクローズド型のコミュニケーションを避ける
提案された UIUX 案に違和感がある場合、気をつけていても解決策そのものに飛びつきがちではあります：「ここで使うのはボタンじゃダメだと思うんです」「モーダルが正しいと思います！」「A 案よりも B 案が良いと思います」といった具合。しかしそうした「A or B」「Yes or No」といったクローズド型のコミュニケーションはデザイナーのオーナシップを奪うことを意味してしまいます。

ただ、多くの場合、危機感そのものは正しいかもなので…？
PDM が UIUX 案に違和感を持った場合、その多くは本来は「うまく説明できないけれど、これだと恐らくここの問題が解決できない気がする…」というぼんやりとした危機感に根差している場合が多いはず。その違和感自体は議論に値するもののはずなので、焦燥感からの解決策の乱れ打ち、ではなく「問題を解決できているか」の視点で議論を進めていくべきです。

追記：たまたま今日読んだ この記事 からの引用。言い得てる。
"When someone tells you something is wrong, they’re almost always right. When someone tells you how to fix it, they’re almost always wrong."
「誰かがあなたに『ここが問題だ』と伝えてきた場合、それはほとんどの場合において正しい。しかし、誰かがあなたにそれを『こう治すべきだ』と伝えてきた場合、ほとんどの場合において間違っている。」

問題にフォーカスしたオープンコミュニケーション
「問題を解決するためには、このボタン以外にはどんな方法が考えられますか？」「A 案も良いのですが、B 案なら今回の解決したい問題を ▲▲ という理由から解決の強度があがると思うのですがどう思いますか？」といった、オープン型・質問型のコミュニケーションに集中し、デザイナーのオーナーシップを奪うのではなく、より「これで問題が解決できるか」を議論の中心に置くことで、個人的な解決策の好き嫌いによらない、より建設的なレビュープロセスが持てるようになるはず。

07# 別の視点を提供しつづける

UIUX 案を検討する際、カウンターパートの PDM として以下の 3 つのような方法を場合によって使いわけつつ、「全く別の視点を提供し、発想を広げる手助けとなる」ことを意識するようにしています。

1. 悪魔の代弁者になる
「今からあえてこの UX を全く別の視点で考えてみますけど…」と前置きして「悪魔の代弁者」となり、デザイナーの思考プロセスやアウトプットに挑戦します：見えていなかった視点やデメリットが議論の中心になり、「ん～…じゃぁ、こうしてみたらどうですかね？」という形でデザイナーからカウンターのアィデアが出てくれば成功。「悪魔の代弁者」アプローチについては以下ツイートで解説しました：

議論の中で、良さそうなアィデアが出て、白熱してどんどん面白いものになり「いける！これはでかい！やろう！」と盛り上がる時。

こうした時に、一歩さがって、あえてそのアィデアを否定するような発言を繰り返す人のことを「Devil's Advocate （悪魔の代弁者）」というのだけど（続く）

— Fritz.M.K (@fmkpro1984) April 26, 2020

2. 無意識のうちに持っている制約を取り払う
社内で経験したプロジェクトが増えれば増えるほど、UIUX デザイナーも次第に開発工数・今までの機能・デザインシステムなどなど、様々な制約を意識的・無意識的に自らに課してデザインを行うようになっていきます。その多くは必要に迫られてのものです。が、時にはそれを指摘して取り払ってしまい、別の視点から考えることも重要なはず。

多くの場合、例えば開発工数を考慮したデザインは非常にありがたいものですが、デザイナーののほとんどが持っていない PDM の特権のひとつに「開発工数の長短を把握している・コントロールできる」というものがあり。

「ここの部分、開発工数を 1.5 倍にしても良いとしたらどうしますかね？」と過激に挑戦してもらうのも、場合によっては想像をはるかに超えた UX 体験案につながり、結果的に採用につながることもあるはずです。

3. 宿題を済ませておき、まったく別のアィデアをぶつけてみる
02# で取り上げた通り、デザイナーに任せきりにせず、自分でも競合画面の調査を行ったり、自分なりのぼんやりとした「問題に対する解決案」を持っておくことで、最初のデザインレビューの際に「例えばこんな方向性もあると思うんですが…」と議論に持ち込むことができます。

07# のまとめ
経験上、今まで一緒に仕事をしてきた UIUX デザイナーのほとんどは自身の提案内容を「ベター」だと捉えることはあっても「ベスト」と思っていることは少なく、デザイン変更には驚くほど柔軟だったりします。なので、ほとんどの場合こうした「別の視点を提供できる」ことは感謝はされても嫌われることにはつながらないはずで、大きなメリットになります。

08# ユーザーがどう思うか？にこだわり続ける

01#~07# までは基本的に「デザインのプロに対してどう貢献するか」というアプローチで、「主導権は UIUX デザイナーにあり、またそうあるべき」ということを前提にしています。

しかし、ユーザー目線に立った場合の UIUX に違和感があった場合には、PDMとデザイナーがあくまでユーザーとしては n=1/n=1 の対等な関係であることを前提に、時に意見が対立してでも執拗に拘ることも重要なはず。

UIUX デザイナーは前述の通り、その職責上、多くの制約・ルールを気にしながら UIUX デザインを行っています。サービスのトンマナ・既に採用している UI との整合性・デザインシステム・開発工数などなど、数えるとキリがありません。

そうした制約・ルールを無視して「ユーザーとしてどうしても違和感がある」と議論に持ち込むのも、プロダクトマネージャーの職責のひとつ。

時に自分が折れ、時にデザイナーに折れてもらったりしていますが、UIUX デザイナーと同じくプロダクトマネージャーも「ユーザーの体験を向上させるため」に働いているのは同じ。必要だと思った際にはしっかりとこだわるようにしています。

09# まとめ

以上、UIUX デザイナーと仕事をする際にプロダクトマネージャーとして持っておきたい 8 つのマインドセットについて振り返ってみました。

個人的には「#02 PDM にも宿題があることを認識する」はまだまだできていない部分が多いし、「05# こうしてほしい・こっちが好きです、は最悪」は今でもたまにやりがちだし、「06# 解決方法ではなく問題にフォーカスする」も、なまじ UIUX 議論が楽しくなってしまうがゆえに解決策の議論に偏りがちだよなぁ、と色々振り返ることができました。日々勉強。

ここまでお読みいただきありがとうございました。

Twitter @fmkpro1984 もやっています（UIUX について・シリコンバレー事情について不定期に呟いています）ので、是非あわせてフォローしていただければとても光栄です。

それではまた。

10# 後編は近日公開予定

本記事と 1:1 の相互補完関係にあるので現場実践編もあわせて書いています。半分程度書きあがっているので、近日公開予定。

お断りとお願い

本稿および note の全記事は個人的な解釈に基づいたもので、所属していた/している会社の意向・見解とは一切関係ありませんので、その旨ご理解いただけますと幸いです。