デザインは、完成したら終わりではありません。
特にWebサイトやWebサービスには、私は「完成形」というものはほとんどないと思っています。
公開したあとも、新しいページが増え、新しい機能が追加され、利用するユーザーも変わります。
サービスそのものが成長すれば、求められることも変わります。
最初はきれいに整っていたものでも、少しずつルールが曖昧になることもあります。
このページでは青いボタンなのに、別のページでは緑色。
同じ「保存」という機能なのに、片方は右側、もう片方は左側。
見出しの大きさも、余白も、アイコンの使い方も少しずつ違う。
一つひとつは小さな違いです。
しかし、その小さな違いが積み重なると、ユーザーはそのたびに「これは何だろう」「さっきと同じものだろうか」と考えなくてはならなくなります。
だから必要になるのが、デザインシステムやガイドラインです。
そして、もう一つ大切なのが改善を続けることです。
今回の「第8の足」では、デザインを一度つくって終わらせるのではなく、品質を保ち、使われ方を見ながら育て続けるための仕組みについて考えてみます。
ガイドラインは、デザイナーを縛るためのものではない
「ガイドライン」と聞くと、細かい規則がたくさん並んだ堅苦しいものを想像するかもしれません。
- この色を使うこと。
- このサイズにすること。
- 余白は何ピクセル。
- ボタンはこの形。
もちろん、そうしたルールも必要です。
でも、本来の目的はデザイナーを縛ることではありません。
毎回ゼロから判断しなくても、同じ目的なら同じ判断ができるようにすること。
それがガイドラインの役割です。
同じものは、同じように見えたほうがいい
たとえば、あるサービスで青いボタンが「次へ進む」という意味だったとします。
ユーザーは何度か使ううちに、
「青いボタンを押せば次に進める」
と学習します。
ところが次の画面では、同じ役割のボタンが突然オレンジ色になっていたらどうでしょう。
ほんの一瞬かもしれませんが、
「これは同じ意味なのか？」
と考える必要が生まれます。
デザインの一貫性は、単に見た目をきれいに揃えるためにあるのではありません。
一度覚えたことを、次の画面でも使えるようにするためにあります。
つまり、一貫性はブランドのためだけではありません。
まず、ユーザーを迷わせないためにあります。
デザインシステムは「共通言語」をつくる
私は実際のWebサイト制作でも、カラー、文字サイズ、ボタン、入力フォーム、カードなどを共通化し、デザインシステムとして整理することがあります。
たとえば、
- 「メインの操作にはこのボタンを使う」
- 「注意を伝えるときにはこの色を使う」
- 「この情報階層なら、この文字サイズにする」
というように、判断基準をあらかじめ決めておきます。
【カラーシステム／タイポグラフィ／ボタン／コンポーネントなど】
こうしておくと、新しいページをつくるたびに、
- 「何色にしようか」
- 「このボタンはどんな形にしようか」
- 「文字は何pxにしようか」
と毎回考える必要がありません。
効率化だけが目的ではない
もちろん、デザインする側にとっても効率的です。
さらに、エンジニアも既存のコンポーネントを利用できるため、毎回新しいものを実装する必要がありません。
同じ部品を共通化しておけば、修正や機能追加もしやすくなります。
つまり、
- ユーザーには一貫した体験を。
- デザイナーには判断の基準を。
- エンジニアには再利用できる仕組みを。
デザインシステムは、この三つをつなぐ共通言語でもあります。
しかし、ここでも一番大事なのはユーザーです。
作り手が変わっても、ページが増えても、機能が追加されても、ユーザーから見れば同じサービスとして使える。
その状態を保つための仕組みが、デザインシステムです。
ブランドとは「同じ体験が積み重なること」でもある
企業のブランディングというと、ロゴやコーポレートカラーを思い浮かべることが多いと思います。
もちろん、それらも大切です。
でも私は、ブランドは見た目だけでつくられるものではないと思っています。
- いつ来ても迷わない。
- 必要な情報が見つけやすい。
- ボタンを押したら想像した通りに動く。
文章の雰囲気も、写真も、操作方法も、その企業らしい。
そうした小さな体験が何度も積み重なることで、
「このサービスなら安心して使える」
という印象がつくられていきます。
つまり、ガイドラインやデザインシステムは、ブランドを守るためのものでもあります。
ロゴを毎回正しく表示することだけがブランド管理ではありません。
ユーザーが毎回同じように安心して使えることも、立派なブランド体験です。
では、ユーザーの意見は全部聞いたほうがいいのか
ここで、少し難しい話をします。
この連載では何度も、
- 「自分の好みだけで決めない」
- 「ユーザーを見る」
- 「目的と根拠で考える」
ということを書いてきました。
では、ユーザーや関係者の意見をできるだけたくさん取り入れれば、よいデザインになるのでしょうか。
私は、そうは思いません。
10人の意見を全部入れても、10人に届くとは限らない
たとえば、10人にデザインを見せたとします。
ある人は、
「もっと文字を大きくしてほしい」
と言います。
別の人は、
「もっと情報を増やしてほしい」
と言う。
また別の人は、
「もっとシンプルにしてほしい」
と言います。
さらに、
「赤のほうが目立つ」
「青のほうが安心感がある」
「写真を増やしたい」
「写真はいらない」
という意見も出てくるかもしれません。
これらをすべて反映したらどうなるでしょう。
誰からも強く否定されないものにはなるかもしれません。
しかし同時に、
誰に、何を、一番伝えたいのか分からないもの
になってしまうことがあります。
足し算を続けた結果、目的が見えなくなってしまうのです。
ユーザー中心と、ユーザーの言いなりは違う
こは、とても重要なところです。
ユーザーの声を聞くことと、ユーザーが提案した解決策をそのまま採用することは同じではありません。
たとえばユーザーが、
「もっと大きなボタンにしてください」
と言ったとします。
その言葉をそのまま受け取るのではなく、
「なぜ大きくしてほしいのだろう？」
と考えます。
押しづらいのかもしれない。
見つけられないのかもしれない。
他の要素に埋もれているのかもしれない。
本当に解決しなければならないのは、「ボタンを大きくすること」ではなく、必要な操作に気づけないことかもしれません。
ユーザーは、自分が困っていることを教えてくれます。
しかし、その問題をどう解決するかまで、必ずしもユーザーが答えを持っているわけではありません。
だからデザイナーは、
「言われた通りにつくる人」
ではなく、
話を聞き、問題を整理し、解決方法を考える人
である必要があります。
一貫した仮説を出すから、改善できる
もう一つ、一貫性には重要な意味があります。
それは、何が良かったのか、何が間違っていたのかを判断しやすくなることです。
10人の違う意見を少しずつ取り入れ、あれもこれも混ぜたデザインを公開したとします。
結果が悪かったとき、
- 何が原因だったのでしょう。
- 色でしょうか。
- 文章でしょうか。
- 情報量でしょうか。
- 導線でしょうか。
そもそも誰に向けたページだったのでしょう。
すべてが混ざっていると、原因も分からなくなります。
「正しいデザイン」をつくるのではなく「検証できるデザイン」をつくる
最初から正解をつくれる人はいません。
だからこそ、
「今回は、このユーザーに対して、この考え方で、この情報を、この順番で伝える」
という一貫した仮説をつくります。
- そして世に出す。
- 実際に使ってもらう。
- 反応を見る。
- うまくいかなければ直す。
このほうが、はるかに学ぶことができます。
私はデザインにおいて、
一貫性とは頑固になることではなく、検証可能な状態をつくること
だと思っています。
Webデザインには「完成」がない
ここからが、今回もう一つの大事なテーマです。
Webデザインは、紙のポスターや冊子とは少し性質が違います。
印刷物であれば、印刷して世に出した時点で、大きく内容を変えることは簡単ではありません。
しかしWebは違います。
公開したあとでも変えられます。
というより、変え続けることを前提にできる媒体です。
私は、この特徴をもっと積極的に使ってよいと思っています。
公開はゴールではなく、最初の検証
Webサイトを制作していると、公開日が大きなゴールのように扱われることがあります。
もちろん、公開は重要な節目です。
しかし、デザインという視点では、
公開は完成ではなく、最初の本格的な検証の始まりです。
制作中には、たくさん考えます。
- ユーザーはここを見るだろう。
- この順番なら理解しやすいだろう。
- このボタンなら気づくだろう。
- この文章なら伝わるだろう。
- でも、それらはすべて仮説です。
実際に世に出してみなければ、本当にその通りに使われるかは分かりません。
だからWebデザインでは、
「完成したから公開する」
というより、
「仮説を検証するために公開する」
くらいに考えてもいいのではないかと思います。
改善は、失敗したからするものではない
「改善」という言葉には、
「何かが悪かったから直す」
という印象があるかもしれません。
しかし、そうではありません。
どんなに考えてつくったデザインでも、実際に使われれば新しいことが分かります。
- 想定していたより多く使われる機能。
- ほとんど使われない導線。
- 説明しなくても理解される部分。
- 逆に、思った以上に迷われる部分。
制作時には見えなかったことが、実際のユーザーの行動から見えてきます。
これは失敗ではありません。
デザインについて新しい情報が手に入ったということです。
その情報を使って、次の仮説をつくる。
そしてまた直す。
Webデザインは、その繰り返しです。
改善、改善、また改善
私はWebデザインには、最終的な「完成形」はないと考えています。
100点のWebサイトをつくり、それを永遠に使い続けることはできません。
- ユーザーが変わります。
- サービスが変わります。
- ビジネスが変わります。
技術が変わります。
使われるデバイスも変わります。
社会の価値観も変わります。
アクセシビリティに求められる水準も変わっていきます。
だから、
昨日の最適解が、今日も最適とは限りません。
1回の大改修より、小さな改善を続ける
何年かに一度、大規模なリニューアルをする。
それも一つの方法です。
しかし私は、それだけではなく、
- 「ここで離脱している人が多い」
- 「この説明は読まれていない」
- 「このボタンが分かりにくい」
- 「問い合わせで同じ質問が増えている」
といった小さな変化を見つけ、少しずつ改善していくことも非常に重要だと思っています。
一度にすべてを変えなくてもいい。
一つ直す。
結果を見る。
また直す。
その積み重ねによって、サービス全体の品質を少しずつ上げていく。
改善とは、大きなリニューアルのことではありません。
日々の小さな判断を積み重ねていくことでもあります。
何を見て改善するのか
改善は、デザイナーの気分で行うものでもありません。
「なんとなく古く感じるから変えよう」
ではなく、
ユーザーの行動や声から考えます。
たとえば、
- アクセス解析。
- クリック率。
- 離脱率。
- コンバージョン。
- 検索キーワード。
- 問い合わせ内容。
- ユーザーテスト。
- カスタマーサポートに届いた声。
- 営業担当者が現場で聞いた声。
こうした情報は、すべてデザインを改善するための材料になります。
数字だけを見る必要もありません。
ユーザーが実際にどこで迷ったのか。
どんな言葉で質問したのか。
何を期待していたのか。
定量的なデータと、定性的な声。
その両方を見ることで、次に直すべき場所が見えてきます。
ガイドラインも改善していい
ここまでガイドラインや一貫性の大切さを書いてきました。
しかし、ガイドラインそのものを守り続ければよいわけでもありません。
サービスは変わります。
ユーザーも変わります。
デバイスも技術も変わります。
以前は問題なかった表現が、アクセシビリティの観点から見直されることもあります。
使ってみた結果、分かりにくいと判明することもあります。
そのとき、
「ガイドラインに書いてあるから変えません」
では、本末転倒です。
ルールは目的ではない
ルールは、よりよい体験をつくるための手段です。
実際の利用状況を見て、
- 「このルールは本当に必要なのか」
- 「例外が増えていないか」
- 「もっと分かりやすい方法はないか」
と見直していく必要があります。
改善した結果、新しい方法のほうがよいと分かったのであれば、今度はその考え方をガイドラインに戻します。
つまり、
- ガイドラインを使ってデザインする。
- デザインを使って改善する。
- 改善した内容をガイドラインへ戻す。
この循環が大切です。
作る → 使う → 観察する → 直す → 共有する
デザインには「完成」という言葉があります。
でもWebの場合、公開した瞬間から次のデザインが始まっています。
- ユーザーが迷っていないか。
- 想定した場所を押しているか。
- 必要な情報までたどり着けているか。
- 問い合わせが増えていないか。
- 途中で離脱していないか。
実際の反応を見ることで、制作中には分からなかったことが見えてきます。
だから、
作る
↓
使ってもらう
↓
観察する
↓
改善する
↓
学んだことを共有する
↓
また作る
この循環を続けます。
そして、改善によって得られた学びをデザインシステムやガイドラインへ反映する。
そうすれば、一つのページで得た知見を、サービス全体へ広げることができます。
改善が個人の経験で終わらず、組織の知識になります。
ここまでできて初めて、デザインシステムは「部品集」ではなく、サービスを成長させる仕組みになるのだと思います。
Appleから考える「デザインを守る」ということ
この話を考えるとき、Appleとスティーブ・ジョブズ、ジョナサン・アイブの関係は興味深い例です。
ジョブズとアイブは、表面的な見た目だけではなく、製品がどう機能し、どうつくられ、ユーザーがどう触れるのかまで含めてデザインを考えていました。
ここで大事なのは、
「偉い人の意見を聞くな」
ということではありません。
また、一人の天才だけにデザインを任せればよいという話でもありません。
大切なのは、
デザインの判断基準を、立場の強い人それぞれの好みによって毎回変えないこと
だと思います。
- 「私は赤が好き」
- 「私はもっと大きいほうが好き」
- 「私は写真が多いほうが好き」
という意見をすべて足していけば、デザインの目的は簡単にぼやけてしまいます。
必要なのは、誰の好みを採用するかではありません。
「何のために、このデザインにしているのか」
という基準を守ることです。
そして、その基準でつくったものを実際に使ってもらい、結果が違えば変える。
意見によって毎回ぶれるのではなく、ユーザーの反応によって改善する。
ここには大きな違いがあります。
8本の足を、バラバラにしないために
ここまで「虹色のタコになれ！」では、
- 色彩
- 構成
- 視覚生理
- タイポグラフィ
- 情報設計
- インタラクション
- アクセシビリティ
と、さまざまな角度からデザインについて考えてきました。
どれも大切です。
しかし、一人のデザイナーが理解しているだけでは、サービスの品質は保てません。
- 人が増えても
- 担当者が変わっても
- ページが増えても
- 数年経っても
同じ考え方を使えるようにしておく。
そのために必要なのが、第8の足である「ガイドライン／改善」です。
ガイドラインは、自由を奪うためのものではありません。
毎回同じことで迷わなくて済むようにして、本当に考えるべき問題に時間を使うためのものです。
そして改善とは、過去のデザインを否定することではありません。
その時点で考えた仮説を、実際のユーザーから学びながら、よりよいものへ更新していくことです。
デザインは、作って終わりではありません。
特にWebデザインには、完成形がありません。
- 作る
- 公開する
- 使ってもらう
- 観察する
- 直す
- また使ってもらう
- そして、また直す
改善、改善、また改善。
その繰り返しによって、少しずつユーザーにとって使いやすいものへ近づいていく。
私は、その終わりのない循環も含めて「デザイン」なのだと思っています。
次回予告：AIに「虹色のタコ」を渡したら、何が起きるのか
8本の足が揃いました。
では、この8つの考え方をAIに渡したらどうなるでしょう。
生成AIを使えば、文章も、画面も、コードも、これまでとは比較にならない速さでつくれるようになりました。
でも、速くつくれることと、よいものをつくれることは同じではありません。
判断基準を持たないままAIを使えば、バラバラなものを、ものすごい速さで量産することにもなりかねません。
では、
- 色彩
- 構成
- 視覚生理
- タイポグラフィ
- 情報設計
- インタラクション
- アクセシビリティ
- ガイドライン／改善
この「虹色のタコ」の8本の足を、AIが判断するための基準として使うことはできないでしょうか。
そしてAIがつくったものを、人が評価し、改善し、その結果をまたAIへ戻していく。
ここでも必要なのは、一度で正解を出すことではなく、改善を繰り返す仕組みです。
次回は、これまで書いてきたデザインの考え方をAIへ渡し、デザインを考え、チェックし、改善するための仕組み
「デザインハーネス」に、虹色のタコをどう組み込むか。
そんな話をしてみたいと思います。
コメント