arrow一覧に戻る

2021.02.03

デザインガイドラインが活用されない理由、そしてデザインシステムを作るべき理由

数年前からUX/UIデザインの重要性が広く認知され、多くの企業の中にデザイン全般を統括するデザインチームが立ち上がるようになりました。
そのようなデザインチームは、UI/UXデザインを企業で有効に活用できるようにするために、様々な施策の推進を行っています。
しかし、弊社にご相談いただく内容のほとんどは「時間を掛けて作成したデザインガイドラインが現場で活用されていない」というものであり、ほとんどの企業のデザインチームが同じような問題を抱えていることがわかっています。

そこで、デザインガイドラインが活用されない理由と対応策を述べてみます。

デザインガイドラインが現場に浸透しない理由とは?

このような問題を抱えている企業の内情を聞いてみると、本来デザインガイドラインを活用すべき人達が多忙であるという問題が浮かび上がります。
デザインガイドラインを活用すべき人達=プロジェクトマネージャーやエンジニア、デザインチーム外のデザイナーではありますが、手持ちのプロジェクトで抱えているタスクを進めるだけでも手一杯であることがほとんどです。
彼らにはデザインガイドラインをじっくりと読むことができる時間がないほどに忙しい状態になってしまっているのです。
またデザインガイドラインを読むことができたとしても、それに沿ったデザインを実装していく時間もリソースも十分に与えられていないことが多いです。

さらに、もっと根本的な問題も存在していると考えられます。
ほとんどの方は長い文章を含むデザインガイドラインをじっくり読むことを好みません。
デザインチームのメンバーであれば、まずは自問してみてください。自分は他の人から提供されたデザインガイドラインをじっくりと読み込み、理解してから使ったことがあったかと。
例えば、Appleの「ヒューマンインターフェースガイドライン」は熟読できていますか?Googleの「マテリアルデザイン」を全て覚えていますか?

Material-DesignHuman-Interface-Guidelines

ほとんどの方は他の人から提供されたデザインガイドラインをじっくりと読むことはしておらず、他の人が作成したUIを参考にしてみたりデザインガイドラインから必要な部分だけを摘み食いしながら、与えられた業務を遂行していることでしょう。
デザイナーであってもこのような状態であるなら、プロジェクトマネージャーやエンジニアがデザインガイドラインを読み、それに沿った正しいデザインを実装することを期待するということがいかに難しいことであるかを容易に想像できるのではないでしょうか。

問題はデザインガイドラインそのもの。

それでは、この問題を解決するにはどうすればよいのでしょうか。
その回答をする前に、少しだけ考えてみてください。実はここが面白いところでもあります。

デザイナーはユーザーの抱えている課題を改善・解決することを専門としたプロフェッショナルであるはずです(理想的には)。
もしそうであれば、プロジェクトマネージャーやエンジニアなど、デザインガイドラインを読んで、活用する方をユーザーと考えてみてはいかがでしょうか。

ユーザーである彼らは、なぜデザインガイドラインを読んで、活用してくれないでしょうか。
きちんとしたリサーチをするまでもなく、答えは簡単です。

  • デザインガイドラインを読むためにはそれなりの時間が掛かりますが、プロジェクトに参加している人達に時間はもっとも貴重な資源の一つです。
  • デザインガイドラインを読んだとしても、そのプロダクトの優れたUXに繋がるまでには実装への追加投資とデザイナーの最終確認などの追加タスクが必要になります。
  • 結果的に優れたUXのプロダクトが出来上がったとしても、その成果とデザインガイドラインとの関連性は明確に見えるものではありません。
  • 明確な成果がすぐ見えて来ないなら、誰もそれに貴重な時間を使おうとしません。結果的にデザインガイドラインの熟知と実行は、タスクとしての優先順位が低くなります。
  • もっとも根本的な問題として、プロジェクトマネージャーやエンジニアの多くの方はデザインに興味がありません。

デザイナーとして、上記の問題に対するあなたの対応策はどうあるべきなのでしょうか。
例えば、多くの企業内のデザインチームでは、以下のような対応をしているのではないでしょうか。

  1. デザインの価値を組織内で力説する。
  2. プロジェクトにもっと予算と時間を配分してデザインへの対応がきちんとできるようにする。
  3. プロジェクトの標準的なプロセスにデザインのタスクと評価項目をきちんと挿入する。
  4. デザインの評価方法を明確に定義し、測るようにする。
  5. (できることであれば)デザインガイドラインをもっと面白い読み物として仕上げる。

しかし、残念ながら上記のような対応策でデザインガイドラインが活用されるようになっていれば、誰も悩んではいないでしょう。
このような問題を解決するためには、もっと「デザイナーらしい」視点で「ユーザーのニーズを分析し、ユーザーに価値があるものを与える」ということが必要です。

もう一度、ユーザーについて考えてみるようにしましょう。

  • プロジェクトマネージャーは工数の削減とスケジュールの短縮に関心が強いです。 もちろん、その上でデザイン的にも素晴らしいものができるのであれば最高でしょう。
  • エンジニアは自分の作業を効率化することへの関心が強く、そのためにより有用な道具の検討や再利用可能なコードの確保には常に興味があります。 新しい機能を作るためにアルゴリズムを考えるのは好きですが、画面上のボタンなどをピクセル単位まできっちり整列させることには興味がありません。

あまりにもステレオタイプ化している気は少ししますが、上記の記述が概ね正しいとしたら、デザインガイドラインが読まれないのはごく自然なことです。
あなたが作成したデザインガイドラインは彼らの仕事を助けるのではなく、追加のタスクを増やしているだけなのです。

デザインを「追加タスク」から「有用な道具」に変える

前述の通り「デザインガイドラインを読み、それに従って実装する」ことは、彼らにとっては追加タスクになってしまいます。しかも、有効性と緊急性が明確ではないタスクになっているのです。

それでは、「デザイナーらしく」発想を変えてみましょう。

まず目指すべきは、彼らが抱えている問題の解決を助ける、新しい道具を提供することです。
そして、彼らがその道具を使ってくれたら、デザインガイドラインの提供で得たかった効果が自然に得られるようになったら最高ではないでしょうか?
「そんな夢のようなことがあるのか?」と思うかもしれませんが、海外では既に広まってきています。それが「デザインシステム」です。

デザインシステムは大きな規模のデザイン組織でデザイナー間の協業、そしてデザイナーとエンジニア間のコラボレーションのために考案されたものです。
デザインシステムは、概ね以下のような要素で構成されています。

  • デザインプリンシプル
  • デザインガイドライン
  • スタイルガイド
  • 再利用可能なUIコンポーネント

「ここにもデザインガイドラインがあるじゃないか?」と思った方もいるのではないでしょうか。
デザインシステムでは、デザインガイドラインを「それ以外の要素」と一緒に提供することこそが重要なのです。

再度ユーザーの立場になって考えてみましょう。
プロジェクトマネージャーやエンジニアの観点からは、上記のデザインシステムの構成要素の一覧からもっとも気になるのは「再利用可能なUIコンポーネント」です。
彼らは「再利用」という言葉に敏感です。「再利用=生産性向上」だからです。実はこれがミソです。

彼らがデザインシステムを「再利用できるコード集」として認識してくれれば、問題はほぼ解決されたと思ってもいいでしょう。
デザインチームから言われなくても、彼らは自分らの仕事の生産性向上のために「再利用可能なコード」を使い始めます。
そして彼らが意識してなくても、あなたがデザインガイドラインで伝えたかったことはUIコンポーネントとして知らず知らずのうちに伝わり、最終的なプロダクトでも生かされます。

デザインガイドラインなど、他の文書はデザインシステムが提供するUIコンポーネントが足りない、または拡張が必要な場合にのみ参照されます。それだけで十分です。

エンジニアにデザインガイドラインを読んでもらうことは期待しない。
その代わりにそのデザインガイドラインに沿って作成された再利用可能なフロントのコードを提供する。

つまり、デザインの正しい実装を「追加タスク」から「有用な道具を使った結果得られた副産物」にしてしまうのです。

デザインシステムによって、デザインを追加のタスクから、生産性向上のために有効な道具に変えることができます。

デザインシステムが変える「ITプロジェクトにおけるデザインの使い方」

既にお気付きかもしれませんが、ここで発想の転換が起きています。
デザインガイドラインを読んで、それに従って実装する「トップダウン方式」ではなく、提供されたUIコンポーネントを使って、必要な時だけデザインガイドラインを参照する「ボトムアップ方式」にユーザーの行動が変わります。
これによって、ユーザーに直接的なメリットを先に感じてもらうことができる上、デザインガイドラインを読むきっかけを自然に作ることができます。
また、プロジェクトメンバー全員がデザインガイドラインを読む必要もなくなります。
新しいUIコンポーネントを追加する一部の人だけがデザインガイドラインを読めば十分です。

更に、UIコンポーネントを再利用することでフロントエンドの実装の品質向上はもちろん、工数も低減できます。初期開発だけではなく、長期的なシステムの運用・拡張のフェーズでもデザインシステムはより高い効果を発揮します。

既存のやり方では良いデザインをプロダクトに行かせるには全ての工程でデザインを意識する必要がありました。
それは現場のエンジニアには多大な負担になります。デザインシステムを活用することで、現場のエンジニアはデザインを直接意識して実装する必要がなくなり、UIコンポーネントを再利用することで生産性をあげることができます。
デザイナーとエンジニアのより明確な役割分担が可能になり、システムの成長速度、プロジェクト規模の拡大にも耐えられるプロセスを作り出すことができるようになります。
デザインシステムはプロダクトに関わる全ての人々が使うことができる生産性を高めることができる道具に変わります。

salesforceのLightning Design Systemの事例は興味深いです。彼らはサードパーティのサービスプロバイダーのアプリにおけるUXの一貫性を確保するためにデザインガイドラインを作成して配布したんですが求める結果が得られていませんでした。そこでデザインシステムを作成して提供することでやがてその目的が達成できています。詳細は以下の動画から確認できます。

これからのデザインガイドライン作成

この内容は、「UXデザインのUXが悪い問題」のもう一つの例とも言えるでしょう。そしてこの問題も「ユーザーに必要とされているものを提供する」というもっとも基本的な手法で対応できます。
その対応方法として適切なのが現時点では「デザインシステム」です。もちろん「一つの解決策は別の問題を作る」という基本原則はここでも健在します。つまり、「デザインシステムを提供することでデザインガイドラインを読まなくても目的としたデザインが容易に実現できるようにする」ことは「デザインシステムを作って、配布し、常に最新の状態に更新する」という新しい課題を生み出します。
この新しい課題に対する解決策については別のコンテンツで議論しましょう。

残念ながら…デザインシステムを作るにしても、デザインガイドラインは必要です。
しかしデザインガイドラインだけでは有効ではないことは明らかです。

従ってデザインガイドラインを作成する際には、最終的な形は「デザインシステム」と想定し、その第一歩として「デザインガイドライン」を作成していると認識した方がいいと思います。

また、デザインガイドラインの完成度を上げることよりは、ユーザーにより直接的価値を提供できるものをなるべく早く形にして提供することに心がけた方がいいでしょう。

結論:デザインガイドラインの必要性は変わりませんが、プロジェクトの現場で使ってもらうには読み物ではなく、彼らに有用な道具として提供する必要があります。それはデザインガイドラインに従って作成された「再利用可能なUIコンポーネント」です。そして、これらのパーツはやがて「デザインシステム」になるでしょう。その全体像を視野に入れつつ、作業を進めることが大事です。

次回は、デザインシステムを作る方法について書かせていただきます。

この記事を書いた人

Roy Kim / 金 成哲 代表取締役 CEO

商社マンから始めて、エンジニア、外資系ITコンサルタント、プロダクトマネージャーを経て、現在はUXデザインを中心に活動中。 エンジニアやコンサルタントとして多数の大手企業のシステム構築経験を持つ一方、MacやiOSのアプリなど、コンシューマー向けのプロダクト開発でも実績を持つ。 テクノロジーとデザインの融合によるシナジー効果を最大化することをミッションとして捉えている。

Contact

どのようなお悩みでも
まずはお気軽に
ご相談ください

arrow

Careers

柔軟で先進的な思考を持った
デザイナーやエンジニア、
コンサルタントを募集しています

arrow

Copyright© Fixel Inc. All rights reserved.