「デザインは1週間で作ろう」
そんな声を、そう珍しくない頻度で耳にします。(先月だけで2度耳にしました。)
これはデザイナーにとって明らかに醜悪な話ですが、実はビジネスにとっても最悪な計画です。
言いたいことは分かります。
賢明な彼らには「デザインに凝るよりも、仮説検証が先だ」という意図があるのです。
しかしそんな彼らに伝えたいことがあります。
それは、
「ソリューションやコンセプトが正しく伝わらないと、仮説検証に致命的なノイズが生まれる」
ということです。
「最低限のデザイン」とは?
先に言っておくと、UIデザインを1週間で形にすることは可能です。それどころか、1日2日で作ることも可能かもしれません。
また、初期フェーズ等においてはデザインが最低限のもので構わないことには大いに同意できます。
最低限というのは、ソリューション検証に耐えられるだけのデザインを指します。
検証のためにはまずきちんとソリューションとコンセプトが伝わらないといけないので、
「最低限のUI=きちんとソリューションとコンセプトを伝えきれるUI」
と定義できます。
「最低限」は1週間で作れるか?
最低限のUIを「きちんとソリューションとコンセプトを伝えきれるUI」と定義しましたが、これはより具体的にはどういうUIでしょうか?
それは、ユーザーのインサイトに刺さり、解決する課題が明確で、価値を訴求してくれるUIと言えます。
何故なら、ソリューションおよびその仮説も、同じくインサイト、課題、価値に紐付くものだからです。
よってUIを作るまでに行われるデザイナーの作業は、
「ユーザーのインサイトを把握する」
「そのインサイトを阻害している課題を拾い上げる」
「課題を裏返した仮説を価値として定義する」
「価値を反映させたUIを作る」
となります。
さて、上記の作業は1週間で完遂することは出来るでしょうか?
多くの場合、これは不可能です。
例えばインサイトを見出すには、少なくとも3〜5人にはヒアリングを重ねる必要があります。
人を集めるだけで1週間が経過することも少なくありません。業界や体制にもよってはさらにかかるでしょう。
そして毎日1人聞けたとして、5人なら5日かかります。
もちろん、ヒアリング時に使うスクリプトと、それを支える仮説も作らなければならないので、3時間ほどのワークショップないしミーティングと、4時間のデスクワークが発生します。
そしてヒアリングが終わった後にはインサイトと課題と価値の定義を行いますが、この個人ワークにも4〜5時間ほどかかるでしょう。
個人ワークだけではヒアリングした人しかインサイトを得られないので、それをチームにインストールする必要もあります。
これには2時間ほどのワークショップないしミーティングを行う必要があります。
そしてその後ようやく、プロトタイピングが始まり、社内外でユーザビリティテストを行います。
ある程度方針が固まってきた時点からハイファイなUIデザインに入り、最後にグラフィックやアセット、タイポグラフィなどを整えます。
3回メジャーなブラッシュアップをするとして、プロトタイピングの合計が6,7日、ユーザビリティテストの合計が12日ほどでしょうか。
そして、UIデザインは1週間ほどです。
意外かもしれませんが、デザインワークにおいてデスクの上で行う作業の比率はさほど多くはありません。
より多くの時間を、デザインの骨子もしくはモノサシとなる、ユーザーへの理解・共感を生む作業に費やします。
では、ここまでに上げた時間を足してみてください。
…。
お分かりのように、きちんとソリューションとコンセプトが伝わるUIを作るのは、1週間で出来ることではありません。
どんなに頑張っても、フルスペックのデザインはもとより、MVPレベルでもほぼ間に合いません。
例外があるとすれば、インサイト等のユーザーに関する情報がすべて揃っているケースです。
プロダクトオーナーやデザイナーがペルソナの属性に近い場合や、既に充分なヒアリングが行われていて、チームに共通認識として浸透している場合など。
この場合は、最後の「UIデザインに1週間」だけで済みます。
もしこういった環境を整えられているなら、あなたには「デザインは1週間でいこう」と言う権利があり、デザイナーにはそれを果たす義務があります。
本当に「最低限のデザイン」は必要なの?
さて、「最低限のデザインは1週間では作れない」というのは上記の通りですが、もう一つ説明すべき点がありますね。
それは、最低限のデザインが無いとどうなるのか?という点です。
この問いへの答えは、下記のような言い分への反論でもあります。
「デザインがテキトーでも使う人こそが真のユーザー、アーリーアダプターだ!!」
残念ながらこれは明らかな勘違いであり、傲慢です。
結論から言うと、最低限のデザインが無いプロジェクトでは、不充分なデザインによって検証が妨げられます。
どういうことでしょうか?
これは、最低限に達していないUIが次の2つのどちらか、あるいは両方が起こることにより、ソリューションやコンセプトを表しきれないことに起因します。
未熟なデザイラビリティとクレディビリティによって起こる不快感や疑念がソリューションやコンセプトを覆い隠す
劣悪なユーザビリティやアクセシビリティがソリューションやコンセプトを覆い隠す
すなわち、ソリューションやコンセプトのことにユーザーが考えを巡らす前に、インターフェースから起こる問題に思考が囚われてしまうのです。
その結果、ユーザーはよく理解しないまま離脱していきます。
つまりこの時起こっているのは
「ソリューションは理解したけどデザインが良くないから離脱した」
という現象ではなく、
「デザインがよくないことに気を取られてソリューションのことを理解する余裕が無かった」
という現象です。
ソリューションを理解すれば使ってくれるはずだった真のアーリーアダプターは、この壁を突破できません。
これでは何も検証できていないのと同じですよね。
致命的な勘違いを引き起こす可能性
あるいは、もしこの不充分なデザインの壁を突破してくる人がいるとすれば、それはどういう人でしょうか?
恐らくそれは、新しいサービスはとりあえず何でも触ってみる習慣がある人や、サービスの内容よりもあなたの制作物が気になる友人などです。
彼らはアーリーアダプターではなく一過性のユーザーでしかありませんが、一時的にでも残った彼らを、アーリーアダプターと誤認する可能性があります。
つまり、適切でない人々にフォーカスしてしまい、誤った意思決定を引き起こす可能性があるということです。
これはプロジェクトの進行にとって致命的と言えます。
何故なら、一度確信したことや決定したことが間違いだったと気づけるのは、2日後や1週間後ではなく、3ヶ月後や1年後になるからです。
最悪の場合、気づかずに終わったり、一度決定したことを覆せずズルズルとフェードアウトしてしまうこともあります。
まとめ
ソリューションがインサイトや課題、価値仮説に紐づく以上、ソリューション検証に必要なUIの「最低限」とは、きちんとソリューションとコンセプトを伝えきれること と定義できます。
そして最低限のUIがデスクワークだけで作られることはなく、デスクワーク以外を削って1週間で作られたUIが最低限に達するまでの時間は、削って得た時間の何倍も大きなものとなります。
そしてその間に訪れたユーザーに起こるUI上の問題は、ソリューションやコンセプトを覆い隠し、仮説検証を妨げてしまいます。
また、不充分なデザインによりアーリーアダプターを誤認してしまうと、ときに意思決定をも狂わされてしまう可能性があります。
「デザインは1週間で作ろう」という考えはそうしたリスクを生むことを忘れないで下さい。
最後に、IBMの名経営者 トーマス・J・ワトソン・ジュニアの至言を添えてこのエントリーを終わりにしたいと思います。
“Good Design is Good Business.”
Thomas John Watson, Jr. IBM