企画とチームプレーでUIデザインする方法 2/4

前回に引き続き、従来型の開発体制下でデザイナー以外の利害関係者とうまくやる方法を考えていきます。

前回例に挙げたような困った状況になると、デザイナーが能力を発揮しづらくなると指摘しました。では、どんな状態なら責務を全うできるでしょう。理想の状況はどんな姿でしょうか？
前回の困ったポイントを元に条件を反転したり言い換ええてみました。

デザイナーが責務を全うできそうな条件：
🙂 ユーザーや利害関係者のやりたい事をどうやって実現するか追求できる
🙂 周りの感想は聞きつつ、デザインの一貫性はプロの技術で守られている
🙂 利害関係者に他人事だと思われず、生産的な反応がもらえる

目に見えるから誰でもフィードバックできる

UIは誰でも見て触って確かめることができます。そのため、表層のスタイルについて良し悪しの感想が言いやすいでしょう。

これはソースコードを成果物とするソフトウェアエンジニアと決定的に異なる特性です。たとえばAとBのそっくりな処理を、共通化するか意図して別々にしておくかの判断はエンジニアしかできません。そういった設計面での利害関係者は、エンジニア内のメンバーで閉じられているでしょう。
ソースコードの良し悪しは、表向きにはたいていメンテ性やパフォーマンスとして現れます。別の視点から見れば、エンジニア以外の利害関係者は、そういった部分のみ意見できます。

UIにも設計はありますが、最終的にはビジュアルデザインとなって現れるため、背景の理屈を正論のように振りかざして周囲を説得することは現実的に難しいでしょう。

UIの利害関係者レビューは実質的に1対多の承認制

図のように、5人の利害関係者がいる場合、円満に仕様を確定させるには、全員の意見を汲み取りデザインを調整していくしかありません。これは、いたって普通の合議制だと思います。

誰が本当の利害関係者？
しかし、ここで「目に見えるから誰でもフィードバックできる」を思い出してください。レビュー対象がUIのない実装だった場合、エンジニアが他5人の利害関係者に、パフォーマンスや拡張性、変更のしやすさを説明します。このとき、5人の利害関係者は本当に全員が利害を持っているのでしょうか？「よくわかんないけど他の人がOKそうだから良いか」と思う人もいるかもしれません。

次に、UIデザインの場合のレビューを考えます。UIの場合は、レビュー対象が視界に入るもの全てです。また、ユーザビリティ評価等がされていない場合、定性・定量的な指標がありません。パフォーマンスならば多くの場合明確な定量的指標となります。そういったものさしや基準無しに、画面をレビューするとき何が起きるか想像してみてください。

いくら周りがフレンドリーだったり遠慮していても、それは相手の善意による協力的な姿勢の表明でしかありません。UIに対しては誰もが感想を述べられます。これは事実上、5人全員の承認がレビューの受け入れ条件であることと完全に同じと言えます。

このような背景から、実はUIのレビューは案外タフで難しい作業といえます。どうやったら、こういったレビューのプロセスをそのままに、上記の「デザイナーが責務を全うできる条件」を実現できるでしょうか。

新しい案件でやった挑戦

こういった課題をクリアするため、新しいプロジェクトでは下記に挑戦しました。

1. 企画と当事者意識を共有する
2. デザインの一貫性を守る
3. 実現方法の追求

ここで「企画」という職域が出てきましたが、今回は企画のメンバーだったに過ぎません。一番の重要なのは、プロダクトとその課題に対する「自分ごと感」の強さです。「開発」や「役員」でも、相手の状況によっては全く同じ取り組みに挑戦することができるはずです。

次回より、上記の1から3を詳しく紹介します。