なかよし駆動開発 - 3.自分で判断するな

私は限界自社UIデザイナー。8月〜9月はユーザーリサーチで大忙し。UX専任の人がいないので、自分たちや事業部のメンバーと協力してやっている。通常業務に加え、＋αでやっていることなので、正直言って全体的に疲弊してきている。UX開発には多大な時間・労力が掛かる。当然だ。他人のことを理解するのは難しい。しかもその他人が膨大にいるWebサービスでは、オーダーメイドで製品を作れない。人様の体験をデザインしようなんて、そもそも無理ゲーである。それでもこりずに、こうして挑んでいるのは、健気なのか近現代人の驕り昂りなのか…

…とまあ、今日のポエムはこのくらいにして、
壮大なUX開発とは別で、現在進んでいる通常プロジェクトの精度を上げることも重要だと思う。今回はたまたま成功した、所要時間：1時間のUX改善を記録したい。

---

部署間の合意形成

社内合意形成の課題

全体の流れをは次の通り。

事業部が要求をつぶやく
→デザイナーが落書き程度のワイヤーを引く
→事業部が要件を固める
→デザイナーが要件通りにデザインを引く
→他の事業部に合意形成をしに行く
→実装〜リリース
→デザイナーもなぜ効果が出たのか、出なかったのかを振り返る
→次のプロジェクトへ。

この中で、苦戦するのは太字部分。合意形成だ。互いの事業部の立場というものがある。追っている数字は違うし、時には相反することもある。ファーストビューに自部署のバナーを置きたいと言って、どっちも譲らず、骨肉の争いになった時代もあったそうな。

その戦いを収めるには、同じ企業内の共通の価値、シンボルを共有することが重要だろう。それは「企業理念」という、抽象的なことになるのかもしれないが、私はデザイナーとして「ユーザー」という、彼らの共通の価値を設定した。

話す前にユーザーになろう

画面の仕様を変更するとなると、それまでのオペレーションを変える必要に迫られることもある。つまり、施策を主導する部署の話は、たいてい他の部署にとって、日々の業務の負荷が増える話であることが多い。チョベリバである。

チョベリバな状態で話をしても、議論は捗らない。結局、最終的に互いの部署のマネージャーの権力の背比べになってしまう。（そして冒頭の政治争いに戻る）

ユーザーにとって、そんな政治争いなんてどうでも良い。デザイナーとしては、ユーザーの期待に応え、自社の期待に応じて、ユーザーに動いてもらいたいだけだ。そこで、今回、合意形成会議の前に「社内テスト」を実施した。

施策の内容を説明せずに、特に指示も出さずに、プロトタイプを触ってもらう。説明しない・指示しないオープンな状態という部分が肝で、自分でユーザーになりきらないと、このテストを終えて仕事に戻ることができない状況を作る。

ユーザーになってみた結果

数字の話をする前に、それぞれの事業部が持っている数字が、結局はユーザーの心理や行動に左右されている事実を思い出してもらう。それを言葉で聞くのではなく、自分自身の体で体験することで、その後の議論をユーザーを中心に進めることができる。

ユーザー体験以外の観点とのバランスを取る必要はあるが、事業部の政治力が強い会社であれば、この方法は有用だと実感している。

誰だって「お説教」は聞きたくない。デザインを進めようとすると、他の職域に対して「ユーザーのことを考えていないですよね？」という説教になりがちだ。言葉で説明するより、体験してもらうことで、デザイナーがなぜその点についてこだわって考えているのか理解してもらえやすい。

---

デザイナーの限界

もう一つの狙い

上記のテストにはもう一つ狙いがある。ユーザーは仕様書を見ながらUIを使う訳ではない。だから、何の説明もなしに、初見でUIを理解してもらえるかを、社内でテストすることが必要だ。

実際のユーザーでテストできるのが理想だが、毎回コストを掛けていられない。社内の人間を被験者にしても、「この色は目に付かない。」「この文章だと伝わらない。」という発見は十分にある。やらないより、やった方が良い。5〜10分触ってもらうテストを、3〜5人するだけでも、0人よりはマシ。ベストエフォートで施策の精度をあげよう。

自分で判断するな

自分で責任を持つことは大事だが、自分の思想だけで判断しても、成功率は上がらないだろう。

UIデザインをする時、デザイナーの最大の弱みは、その仕様を把握してしまっていることだ。仕様を知っている状態で、仕様を知らない人のためのデザインを引いても、それは限界がある。

だから、「こうしたい、ああしたい。」と主張するのではなく、何も説明しない状態で、他部署の人間が取った行動をもとに、議論を交わした方が有意義だと思う。相手も自分の行動をもとに話をした方が、「ユーザビリティ」だの「ユーザーエクスペリエンス」だの、カタカナを並べられるよりも理解しやすいだろう。

シリーズまとめ

最終的に以下のようなフローになる。

事業部が要求をつぶやく
→デザイナーが落書き程度のワイヤーを引く
→事業部が要件を固める
→デザイナーが要件通りにデザインを引く
→他の事業部を相手に社内テストを実施（5分*3〜5名）
→テストの結果をもとに合意形成
→実装〜リリース
→デザイナーもなぜ効果が出たのか、出なかったのかを振り返る
→次のプロジェクトへ。

運もあるが、このように進めた施策は目に見える形で成果が出た。そうやって仕事が上手くいくと、メンバーは余計になかよしになる。こうして好循環に乗れると、人間関係に気を使わなくても、勝手に良い施策ができるようになると思った。

以上で「なかよし駆動開発」の備忘録を終了する。2024年9月