どのデザイナーがUIを設計しても、充分なクオリティと統一感を出すために。
UIデザインは他のデザインと同じく、誰がデザインするかは重要なファクターだと思われています。しかし組織としては、誰がデザインしたかによってその良し悪しが変わるのはなかなか困るもの。この解決をデザインレビューに頼るチームもありますが、私たちは、オブジェクトについて語る時間を運用することで、より優れた形で解決しています。このシンプルな方法を、経緯・効能とともにシェアします。
戦略
自分が所属するデザインチームでは現在、誰がUIデザインを担当してもよい状態を目指すことを方針としています。
これは単なるお題目ではなく、必ずしも専任のデザイナーが設計しなくても一定の方向性と思考フローを辿って開発が行えるように既になっています。
もう少し進展すれば、UIデザインはただの役割になり、UIデザイナーという”役職”は不要にすることも可能そうです(そうしたい)。
この一助になっているのが、定期的に設けている「オブジェクトを見つめる時間」という会です。
それがどういう会で、なぜ行うべきなのか、そしてどのようにして誰がデザインしてもよい状態を一定達成しているのかシェアします。
経緯
現象
現在お手伝いしているSTANDS社には、よくUIデザインを担当するメンバーが自分を含め3名います。
ある時同社で、複数人によるデザインレビューをした方が様々な点で良いのではないか?という声が上がりました。
課題感
“様々な点”というのは、要約して言えば次の2点でした。
デザイナーの能力差によるクオリティ差を埋めたいというニーズ
設計思想のバラツキによる体験の統一性の欠落を無くしたいというニーズ
1については、主にPOからの意見でした。デザイナーによる差があるように見えたのかもしません。これ自体は様々な企業でありえることです。
「あのデザイナーに任せるといい感じなんだけど、別のデザイナーに任せると微妙」「新しくやってきたデザイナーが諸々の情報を踏まえて良いUIを設計するまでに時間がかかる」
こんな声を聞くことは多いですよね。
2については、自分を含むデザインチームの意見でした。エピックごとに──というか担当者ごとに異なる設計思想でUIデザインを行っていたため、いくつかの箇所で既に設計思想がバラついており、体験の一貫性が損なわれ始めていました。
どちらも、UIデザインの必要がある会社の多くで一度は起こる課題感だと思います。
デザインレビューの欠陥
さて、多くの会社・チームでよくあると同時に、それらはデザインレビューで解消できるのではないか、という意見もまたよくあります。私自身「必ずデザインレビューを挟もう!」というチームに所属していたこともありますし、実際ある程度効果もあります。
しかしながらデザインレビューがそれだけやっておけばいいような”最適な”ソリューションかというと、そうとも限りません。
デザインレビューは各レビューが単発的で、再生産に寄与する活動ではないからです。
より具体的には、1,2の課題それぞれに対するソリューションとしての不足と、さらにもう1つの欠陥があります。
1. デザインレビューは再生産に寄与しない
デザイナーごとの能力差は、必ず存在します。これは受け入れなければなりません。ただしその受け入れ方は様々です。
大別としては、戦略的, 戦術的, あるいは即応的のいずれかです。デザインレビューは即応的な手段に該当します。
デザインレビューは、レビュー対象について担当者ごとのクオリティ差をたしかに緩和してくれます。
しかしデザインレビューの効果範囲は非常に限定的で、そのエピック&&そのレビュー部分&&その担当デザイナー
にのみ影響を与えます。
また、レビューはレビュー対象にのみ行われます。多くの場合、対象はコンポーネントや画面, 画面遷移, インタラクションといった小さな粒度です。
これらは非常に具体的で、かつ個別のケースへの指摘となるため、他の機能や他のエピックでは活かせません。
つまりデザインレビューによるデザイナーの成長速度は遅く、一度に成長する人数も少ないと考えられます。
よって、場当たり的で細かすぎる事柄への指摘にとどまるデザインレビューへの依存度が高いほどデザイナーごとのクオリティ差は埋まらないのです。
2. デザインレビューには設計思想の共有が無い
デザインレビューは具体的に指摘・議論しなければ機能しないため、その指摘や論点は自然と細かい話になります。
すると、時間的・工数的に話せないものは話せません。このデザインレビューでは話せないことの1つが、設計思想です。
設計思想に当たるものはチームによって異なりますが、私たちはオブジェクト指向を基礎としているため、下記のような論点や議論がこれに当たります。
ユーザーの認知上どんなオブジェクトが存在するのか?
自分たちはいま何をメインオブジェクトとして捉えているのか?
今から作るものはどのオブジェクトやサブジェクトを使うのが適しているのか?
各オブジェクトのビューはどのようなものが蓋然性あるのか?
ある画面はどのようにビューを組み合わせるのか?
こういった思想は、誰がデザインを行う際にも参照できる(されるべき)グラウンドデザインです。デザインを考える際の思考要件や設計出来る範囲・制約という形で、UIデザインの大枠を規定できます。規律と言い換えることも出来るでしょう。
こういった部分は、デザインレビューに求められる詳細度に比べ粒度が大きすぎます。よって、どれだけ頻度高くデザインレビューを行っても思想の範囲までカバーできません。
もちろん、努めればデザインレビューでもその場その場で設計思想のブレをある程度修正できますが、その能力は属人的で、戦略的に優秀とは言いづらい解決能力です。
例えばレビュー依頼が細部に集中していたら?レビュー依頼した相手が設計思想を理解していなかったら?偶然高い能力を持つレビュワーが多忙・病欠で、別の人がレビューすることになったら?何らかの要因でレビュワーにやる気が無かったら?
ほかにも色々なケースがあるでしょう。属人的であるためにこういった統制しづらい要因でデザインレビューの修正能力は安定しません。
担当者ごとにUIデザインの方針が異なる可能性を減らすためには、たとえデザインレビューを実施する場合であっても、デザインレビュー以外の何かが別途必要です。
3. デザインレビューはボトルネックを量産する
デザインレビューには、必ずある工程があります。レビュー待ちです。
この待ち時間を何と見るかは、人によって意見の分かれるところでしょう。特に歩留まりと見るか、リーンに物事を進めるためのバッチサイズの区切りであると見るかによって、その評価は正反対のものになります。
歩留まりなのであれば、極力無くすべきです。一方バッチサイズの区切りならば、それはモノづくりの進め方としてあって然るべきです。
私のスタンスは前者です。歩留まりだと評価している理由は、1回のレビュー依頼は最低2箇所でボトルネックを生むことにあります。
レビューを出すと、2人に待ち時間が生まれます。1人目は当然レビュー依頼者(レビュイー)です。レビューが返ってくるまで、その対象について作業を進めることは出来ません。もう1人は、レビュワーです。レビューをしている間、他の仕事を進めることは出来ません。
さらに悪いことは、ここにはレビュイーとレビュワーの間で相反する利害関係が生じてしまうことです。
つまりレビュイーは早くレビューを返してほしいと考え、レビュワーはレビューで時間を取られたくないと考えます。
前者に応えればレビューは早く返りますが別の仕事(その仕事はさらに別のレビューかもしれない)は後回しになり、後者に応えればレビュイーは長くブロックされます。
レビュワーが人間である限りレビューのリソースは絶対値ですから、二者択一です。よって、レビューを出した瞬間、2つの箇所にボトルネックの蓋然性があるのです。
もちろんレビューしている間なにもしていないわけではないので、単純に2倍の数のボトルネックがあるわけではありません。しかし、デザインレビューを奨励し5つも6つもレビューを抱える状態になったならどうでしょうか?
レビュワーにとっては無限とも言える時間、自身の作業は止まってしまいます。また、レビューを依頼した側にとっても無駄な時間が生じる可能性が高まります。1
あちこちでボトルネックが生じ、デザイナーが何人いても歩留まりが止まりません。むしろデザイナーが増えるほどボトルネックも増えることになります。2
デザインレビューによるレビュー待ちは、積極的に生み出して良いものではないのです。
一旦まとめ
少し長くなったので、一旦整理しておきましょう。ここまでデザインレビューの欠陥を3つ上げてきました。
デザインレビューの効果範囲はとても限定的で、組織的成長にあまり貢献しない
デザインレビューでは粒度が小さい話に終始し、グラウンドデザインが共有されない(問題が根本的に解決されない)
レビューのボトルネックが起き、野放しにすれば無限のリソースが必要になる
これらのことから、デザインレビューという手段に飛びつくのは安易な選択です。
よりよいソリューション
STANDS社では、デザインレビューは最小限に抑えています。
その代わりに行っていることが、設計者間でより根本的なことを先んじて共有しておくこと。設計思想を共有しておくことです。
具体的には、プロダクトとして何を主要オブジェクトだと認識しているのかを共有・確認し続けています。
設計の認知を保守する
やることは単純で、毎週30分「オブジェクトを見つめる時間」という会を設け、現在のメインオブジェクトについて議論するだけ。
同チームでは設計についてオブジェクト指向を基礎としているため、設計の根本にあるのはオブジェクトです。よって、何がオブジェクトなのかを共有しておくことで、デザインレビューよりも根本的に・広く問題を解決できます。
「オブジェクトを見つめる時間」の中でこれまでに話された内容は例えば次のようなものです。
メインオブジェクトについての説明・共有
オブジェクトを使ってある機能を設計したいがどうすればよいのか
UXリサーチを根拠としたメインオブジェクトの更新
新しいオブジェクトの設計フローの相談
ある画面の、オブジェクトを使った新設計案共有
新機能の画面の、オブジェクトを使った設計案共有
あるオブジェクトのプロパティの過不足について
あるオブジェクトのCRUDの過不足について
オブジェクトのプロパティに独自のデータ型を設けよう
いずれもデザインレビューでは話せない粒度のことばかりです。
この会で達成していることは、いわば設計の認知の保守です。私たちが作っているプロダクトはどんな姿であるかを大きすぎない抽象度で定義し、その定義を日々確認したり更新したりしています。
この認知が保守されていること、またこの会を更新の場とすることで、設計者には勝手なオブジェクトを生成できない制約と、オブジェクトを使って設計すればいいんだという安定的なフローを与えることができます。
同チームで少し独特なのは、今のところUXリサーチも私がメインで行っているため、オブジェクトを更新する場としても機能していることでしょうか。
効能
この会を行う前には、エピックの要件のみが参照された結果、設計していたオブジェクトを超えて機能が設計・提供されたことがありました(それがこの会を開くきっかけでもあった)。
また、実際に設計を行う際オブジェクトの提案者(私)にどのように設計を進めるべきか尋ねられることもありました。
それぞれは別々に起こった事柄ですが、両件は通底したものです。
つまり、オブジェクトとそれを使った設計の存在は知っていてもその使い方はよく分からず、また自分がオブジェクトにコミットしているわけでもないので、縁遠いものとなっていました。
この結果がまさに、デザイナーごとの差や設計思想のバラツキとなって表れていたのです。
オブジェクトを見つめる会を運用するようになってからは、オブジェクトについての疑問や共有不足は会の中で解決されるようになりました。そればかりか、オブジェクトやそのプロパティについて各メンバーがコミットできるようにもなっています。
現在では、機能や画面に更新を施すべき時には全員がスクリーン設計案を作り、提案するようになっており、デザインレビューの必要数をぐんと減らしています。3
こうして私たちは、根本的に誰がUIデザインを担当しても良いように体制取っています。
【無駄な時間が生じる可能性】人数が増えると、全員に充分にタスクが割り振られていないことが出てきます。その結果「なかなかレビューが返ってきません。何をすればいいですか?」という状態が生まれます(大企業でよくある)。