プロダクトデザイナーはエンジニアとのバトルをどう乗り越えるか
こんにちは名無しのプロダクトデザイナーです。普段は外資のテックで働いてます。
最近、テックの会社でエンジニアとバトったときにどうするか、という悩みを知り合いのプロダクトデザイナーから聞くことがあります。バトル！？戦っちゃうの？？なんてこった。と衝撃を受けたので、今日も思いの丈を書いてみようと思います。
結論から言えば、問題が起こるずっと前の段階にアプローチすることで、バトルからチームワーク・コラボレーションに変換できるといいよね。と思ってます。
デザイナーは大なり小なり、デザインを意図した通りに実装して世の中にリリースして欲しいという願いがあるかと思います。
しかし、現実には中々難しくて実装されるデザインが別モノの様に感じられるケースは多いです。その理想とのギャップからバトルに発展してしまう、というのはよくある話。
きっかけの例を挙げるなら
・エンジニアから「それは無理」だとか「優先度が低い」と突きつけられた
・実装してもらったモノを見てみたら、全く違うレイアウト、マージンがない、色が違うなどビジュアルのクオリティが担保できていない
・時間をかけて磨き込んだモーションが無視された
・重要な動線が実装されていなかった
・デザインをボロクソに言われた
などなど。
どう解決すればいいのか。頭の痛い問題ですね。僕がこれまで蓄積した乗り越え方、またチームワークへの変換とはどういうことなのか書いてみます。
視点を切り替える
視点を変えて周囲の声に怯えない
美しいヴィジュアルや魔法の様なUXが掲載されてるポートフォリオサイトに憧れるのが僕たちデザイナーのサガなのかもしれません。みんなステキなデザインをやったと誇らしく思いたい。一方でSNSでは有名な会社のデザイナーが、いかに世にあるアプリのデザインが酷いのか語っている。
こうした環境で、自分のデザインが変に実装されたら他のデザイナーにどんな風に言われるのか。全く気にならない人がいるでしょうか。気になりますよね。でも思い出してほしいことがあります。
デザインはアートではありません。制限の中で行うモノ。問題解決なのです。問題を知らないで解決を批判するのは、ルールを知らないでスポーツ選手を批評するくらいには意味がない。
会社のカルチャー、リソース、デザイン組織の成熟度、業界、組織構造、経済状況、ユーザー層、プロダクトのフェーズなど様々な環境要素がデザインと成功の意味を大きく左右します。
環境を含めた元の状態から、どれだけ前進したかの方が、結果だけの比較よりも重要です。つまりBefore/Afterに価値がある。こうした問題解決量に対する視点を持っている場合、社外の声に怯える必要がなくなる。まずはこれがスタートだと思います。
視点を変えて相手を理解する
あなたは自分のデザインは細部まで重要だと考える。そんな中でエンジニアはデザインの変更を迫ってきた。時間をかけて磨き上げたデザインが台無しになる。さて、どうするべきか。どう説得すべきか。
デザインを言語化し伝えるのは必要なのだけど、もし議論をしても合意に至れないとしたら、ここも視点を変えるときかもしれません。
なぜなら、デザインを説明する、説得するというのは解決手段の一つでしかないからです。
そして、解決すべき問題を「エンジニアがあなたのデザインを理解しないこと」から一歩拡げて「あなたとエンジニアとの間に考えのギャップがあること。」と捉えるたらどうでしょう。きっとどの様にギャップを埋めるべきかと考え始めるはず。
まず観察から始めるのがデザイナー。なぜエンジニアとの間にギャップがあるのか。技術スタックは？技術負債は？そのエンジニアのスキルセットは？グレード感は？理解しやすいこと、理解しにくいことは？モチベーションの上下のトリガーは何？さらにはOKRや個人的に成し遂げたいことは？
全てを知る必要はないかもしれませんが、情報を集めてから、それに合わせた解決策をデザインできないでしょうか。例えば以下のようなこと。
エンジニアが成し遂げたいことも同時に可能な案に変更する
エンジニアが知っている言葉や例えを使って話す
1点目の典型的な例を考えてみましょう。
工数を下げたい。またはコストを下げたい。はやくデリバリーしたいなど。これは往々にしてプロダクトが失敗したときのリスクを気にしていたり、工期全体の遅れを心配していたりすることが多いでしょう。
だとするならば、次の様な解決アイディアがありそうです。
既存のデザイン・コンポーネントを使い回すデザインに変更する
他のプロジェクトでも再利用可能なコンポーネントとして提案する
こうした対処方法の引き出しは経験と共に徐々に増えていきます。しかし、その土台は観察・理解だと思うのです。UXデザインと同じですね。
視点をWHATからWHENへ。コミュニケーションのタイミングと頻度
仕上がったデザインをエンジニアに見せる様なワークフローはなくなりませんが、タイミングと頻度の調整により着地をソフトにできます。
相手を知って信頼を得て何を言うかというWhatの部分から、Whenにも着目しましょう。もし今エンジニアとデザイナーには距離がある場合、明日からいきなり深い理解や急な説得は難しい。しかし、お互いを知る機会は今日からでも作れるはずです。
よく一緒に働くエンジニアと1on1を設定するのはおすすめ。何を大事にしているのか、何に困っているのか、まずは聴き手に周る。
じっくり聞いた後、最後にデザインに関して早めに相談しても良いか聞いてみる。そうすると、ダメと言う人はあまりいません。(たまにいますが)
こうした予告をした上で、まだ荒い段階から「荒いよ」と前提を伝えた上でエンジニア視点からリスキーそうなところを聞き出す。また繰り返しその人が何を目指しているのかを確認しておく。
頻度はケースバイケースですが、デザインに興味があったり、逆に不安感を強く持っている場合は多めに。逆にあまり興味がなく効率重視の場合は少し減らす様な形がいいでしょう。一回限り、毎週、2週に1回、月に1回、クォーターに1回などの頻度を状況に応じて調整するのが大事です。
こうして早めのフィードバックを求めてデザインを一緒に固めていくカタチを取ります。デザイナーがデザインし終えてエンジニアが渡すという流れ作業から、チームワーク・コラボレーションによるデザインに変えてく。柔軟な対応と相手に寄り添う姿勢を続けると、確実に信頼関係を強くします。その信頼はいざという時に強力な助けになります。
超長期視点を持ってチャンスを狙う
ここまでの視点転換やコミュニケーション周りの努力で、あなたのデザインはかなり実装しやすい状態になるはずです。
しかし、一方では実装しやすいだけが重要なわけではありません。例えばアジャイル環境で短期的な優先順位付のせいでビジュアルデザインの質が担保できないとしたら長期的にビジネスの首を締めて行きます。UXライティングの質が低く一貫性のないワーディングはユーザーの混乱を招いてしまいます。
あなたの不断の努力をもってしても、こうした品質向上が実装における高い優先順位になることは珍しいでしょう。ではどうするか。２つポイントがあります。
あなたはプロダクトを何年もかけてゆっくりとデザインしているという視点を持つ
バックログにチケットを切ったり、スプレッドシートを作って事あるごとにエンジニアにリマインド
一つ目に関して、インハウスデザイナーはエージェンシーと違い数年単位でゆっくりと公開された場でデザインを進めていると考えると心が少し平穏になります。
二つ目は細かなテクニックですが、エンジニアが暇で困っている瞬間を狙ってリマインドすると高確率で実装してもらえます。問題はエンジニアが暇なときはデザイナーが忙しいことが多いので、あらかじめデザインも準備しておく必要があります。ちなみに暇になる瞬間はクォーターに一回とか、年に一回とか、二年に一回のこともあるので気長に待ちます。
プロアクティブに動く
プロアクティブとは物事が起こる前に動くこと。先手を打つということです。問題解決量の重視、チームメンバーへの深い理解、コミュニケーションタイミングの最適化、長期目線といった視点を手に入れたら次はプロアクティブに動くのが重要です。
骨太な提案にする
かつてデザイン雑誌に掲載されていた有名デザイナーのインタビューで「骨太な提案」という言葉が書かれていました。それはアートディレクションの話で、クライアントからの修正依頼などでデザインが壊されてしまうと感じていたところ、上司のデザイナーから「もっと骨太にしろ」と言われ目から鱗が落ちたという内容。言い換えると、細かなところがいくら変更されてもしっかりと大事な点が伝わり、良さが変わらないデザインという意味です。
これはプロダクトにおいても同じことが言えると思っています。優先順位が下げられたりしても、根幹部分のUXが効果を出せるのでユーザーのペインが解決されビジネスの成功につながる。そのような「UXの背骨」を意識する。言い方を変えればPMもエンジニアも優先順位を絶対上げたいコアUXに1番力を注ぐ。それ以外のマイクロインタラクションなども重要ですが、たとえそれらが無くても成り立つか考えておく。
逆に提案が通らなかったり、優先順位が下げられてしまうのに悩んでいるときは、自分の提案が骨太か考えてみるのも大切です。
これをやろうと思うと、実はデザインのことだけを考えていられなくなります。ビジネスと技術、そしてユーザーに対して、より深い理解が必要になってきます。
ビジネス、技術、ユーザーへの理解を深め、骨太な提案をさらに考えていくと、次第に目の前のプロジェクト単位の視点では足りないことが見えてくるはずです。シニアレベルが上がってくるに従い、それはより顕著になり、デザイナーは戦略に対してどう影響を及ぼすのか、戦略レベルでのUX提案を考える必要が出てくるはず。
戦略はこの記事のポイントではないため、深く突っ込みません。しかし、戦略はUXを決定づける大きなファクターで、デザイナーは誰もがいずれ学ぶ必要が出てくると思います。
ユーザー中心視点に巻き込みアイディアを思い付かせる
さて、プロダクトの戦略までいかずとも実はやれることがあります。それはチームカルチャーを変えること。そしてエンジニアにもアイディアを考えてもらうこと。
人は押し付けられた案よりも自分が出したアイディアであれば、モチベーションが上がるものです。とは言っても、エンジニアは技術的なアイディアに偏るのは仕方ありません。そこで重要になるのはユーザー視点の埋め込みとインクルーシブなワークショップ。いわゆるデザイン思考のプロセスに巻き込んでいく形です。
あなたがユーザーリサーチでインタビューを行うとき、ユーザーテストを行うとき、エンジニアを誘ってみるのはどうでしょう。目の前に本当に使ってくれてる人がいたとき、どんな理論も思想も関係なく、反応や言葉を受け止める他ありません。リサーチ後のディブリーフィングにも参加してもらって感じたことをシェアすれば、さらに理解が深まって行きます。ディブリーフィングではペルソナなどをうまく参照してユーザーの傾向を伝えるのも効果的です。
壁にユーザージャーニーを張り出してフラッと立ち寄ったエンジニアに声をかけてみるのもいいでしょう。
そうしたユーザー視点のインストールの後で、ブレインストーミングセッションを一緒に行うことで、主体的な意識を促せます。この時は手書きのスケッチがおすすめです。出てきたアイディアをうまくデザイナーがまとめてブラッシュアップすることで、一緒に出したアイディアを実装する感覚に変わっていくイメージです。
こうした活動やワークショップの実施はプロダクトマネージャーやエンジニアマネージャー、スクラムマスターなどと相談しながら行う必要があるのですが、公式なワークショップでなくても話しながら目の前でデザインするライブデザインを活用する手もあります。録画したユーザーテストのダイジェストを作ることもできます。
最後に
エンジニアもコードを書いてるのはコードのためではなく最終的にはユーザーのためです。しかし責任範囲や立ち位置が異なることから対立してしまう。
それをチームワーク・コラボレーションに変換するのは問題解決量の重視、エンジニアへの深い理解、早め&繰り返し相談、長期目線、プロアクティブな骨太提案、そしてユーザー視点への巻き込み。少なくとも僕は、そんな風に考えてやってきました。
今回は触れませんでしたが、ビジョンの共有のためにブランドコンセプト、マーケットにおける立ち位置のマッピングなどをワークショップの題材にしたこともあります。ワーキングアグリーメントを一緒に書いたり、席をエンジニアの隣にしたり。
結果的に私の過去のチームでは、この記事で書いた様な地道な活動で、トータルでのベロシティは確実にあがりました。対立で擦り減るエネルギーを誰もがプロジェクトのクリエイティブなところに注げたからです。またワークショップではエンジニアのクリエイティビティに驚くときもしばしばありました。
とはいえ、変化は少しずつしか起こりませんし、もちろん苦労がなくなるわけじゃありません。クロスファンクションはいつだって難しい。
でも、だから面白い。そう思ってます。
では。