デザインガイドラインの生存可能モデル

ソシオメディアでは、デザインコンサルティングの一環としてデザインガイドラインを作成することがよくあります。デザインガイドラインの役割は主に以下のようなものです。

• 大規模なシステム開発において、複数の画面設計者がそれを参照し、デザインに統一感を持たせるため
• 将来的に複数のサブシステムが追加開発されるのを見込んで、それらのデザインとメインシステムとに統一感を持たせるため
• サードパーティに対してアドオンやプラグインのAPIを提供する際、デザインガイドラインを合わせて提供するため

特に開発体制の中に専属のデザイナーがいない場合、デザインガイドラインが画面設計者にとっての拠り所となります。アプリケーション全体における概念モデルと画面構成の関係、共通画面要素の役割、各画面種別ごとの基本的なレイアウトやコントロール表現、配色やアイコンの意匠といったものをガイドラインで定めることにより、ユーザビリティ上の重要なポイントである一貫性を確保し、開発者の意思決定を効率化し、システムの利用価値や競争力を高めることに貢献します。

一方で、デザインガイドラインの作成と運用には、どの組織でも同じような課題が生じます。ここではそれらについての基本的な解決方法と、ガイドラインを有効に存続させるためのモデルを紹介します。

ガイドラインが先か、個別デザインが先か

デザインガイドラインは開発者がデザイン作業を行う時に参照するものですから、デザイン作業（外部設計フェーズなど）が開始される時点ではすでにガイドラインが出来上がっている必要があります。しかしデザインガイドラインを作るためには、そのシステムで必要な画面構成要素とそれらの表現パターンが定まっている必要があり、それには実際に画面デザインの作業をしてみる必要があります。

デザインガイドラインを作成する上で、このパラドックスを解決するための基本的な流れは、次のようになります。

1. 上流工程において概念モデル、主要エンティティ、おおよその機能セットが決定された段階で、具体的なデザイン作業を開始する
2. まずコンセプトデザインとして、代表的な画面や典型的な操作フローについて画面デザインを行う（5〜20画面程度）
3. ディスカッションやプロトタイピングを通じてコンセプトデザインをブラッシュアップしながら、その他の検討すべき画面パターン、コントロール類、異常系などの基本的な表現をデザインする
4. ここまでの成果をもとに、デザインガイドラインのドラフト版を作成する
5. ガイドラインのドラフト版を参照して、個別の画面（残りの全画面）を作成する
6. 個別の画面デザイン作業において、ガイドラインに含めるべき事項が見つかればそれらについて追記し、実現可能性などの問題が見つかればそれらについて記述を見直し、ガイドラインを完成させる

この段階で、デザインガイドラインの初版と、システムの初回ローンチ版が完成します。完成したガイドラインの内容は、ユーザビリティ、実現可能性、ビジネスゴールとの整合性が確認されたものであり、また完成したシステムはデザインガイドラインに沿ったものになっています。

ガイドライン運用時の課題

ガイドライン運用における一番の課題は、「どうやってガイドラインを守ってもらうか」ということでしょう。画面設計を行う担当者が多い場合や、担当部署同士の連携が弱い場合には、ガイドラインが適切に守られず、デザインの統一感に欠けるサブシステムが次々と作られてしまうことがあります。そのため、できるだけ次の事項に留意し、実現を試みる必要があります。

• ガイドラインには必要最低限の事項のみを載せる（情報が多すぎると見てもらえない）
• ガイドラインには、デザインの考え方と具体的な表現例を載せる（具体例があればすぐに真似でき、個別性の高い画面については考え方を知ることで意思決定しやすくなる）
• UIコンポーネントやレイアウトテンプレートなどを用意する（開発者ができるだけシステマチックにガイドラインの内容を再現できるようにする）
• ガイドラインの保守と運用はできるだけ特権的な部門や役職者が担当する（組織内で部門横断的にガイドラインを啓蒙および指導できる立場）
• 開発中のデザインがガイドラインに準拠しているかどうかをチェックするフェーズを、プロセス標準などに組み込む（開発プロセスや品質管理プロセスの中で制度化する）
• フィードバック方法と改版プロセスを定義する（要望を随時取り込むことで、ガイドラインを現実的なものに保つ）

この最後のフィードバックプロセスが非常に重要です。なぜなら、デザインや技術のトレンド、運営者の事業内容やシステムに求められる機能要件などは次々と変化するので、それらに合わせてデザインガイドラインも改版していかないと、やがて古びて、業務企画者や開発者からみて守りたくない内容になってしまうからです。

ガイドラインのヴァイアブル・モデル

デザインガイドラインの運用担当者は、設計担当者から、「今作ろうとしている画面では、ガイドラインには載っていない（載っているのと違う）表現をとりたいのだが、許されるか？」という質問を受けたことがあるでしょう。その理由としてはおそらく次のようなものが挙げられます。

• 業務要件を満たすには、ガイドラインにある表現よりも、〇〇の表現の方が良い
• ガイドラインにある表現は古くさくてかっこ悪いから、もっと今風の〇〇の表現にしたい

設計担当者の間でこういったネガティブな意識が広まると、ガイドラインは形骸化し、守られなくなってしまいます。また守ったとしても、そのデザインはユーザビリティやビジネス上の競争力を保持できないものになってしまいます。

そこで必要となるのが、ガイドラインのヴァイアブル・モデルを作ることです。

ヴァイアブル・システム・モデル（生存可能システムのモデル）とは、生物の体や企業などの組織が環境の変化に適応して生存するために自律的に自己調整する内部機構をモデル化したものです。ここでは、ガイドラインを環境の変化に適応させながら有機的に運用していく方法を、ガイドラインのヴァイアブル・モデルと呼ぶことにします。

ソシオメディアが提案するガイドラインのヴァイアブル・モデルでは、「ガイドライン」と「実際の製品開発」がフィードバックループを構成しています。まずガイドラインによって基本のデザインが提示され、それを参照して製品が作られ、その開発過程で検討された新たなデザイン要素がガイドラインに反映され、それを参照して次の製品が作られる、というサイクルを回すのです。

このモデルでは、ガイドラインは守るべき基準であるだけでなく、実際の製品開発の現場で生み出された新しい表現や、運用中に発見されたデザインの問題点を抽出して反映する、組織におけるデザインノウハウのハブとなります。

つまり、ガイドラインは守るために作られますが、絶対に破ってはいけないものではない、という考え方です。ガイドラインは継続的にアップデートされるべきであり、ガイドラインをより良くアップデートしていくためには、現実の開発案件の中で（ガイドラインを少しずつ破りながら）常に新しいデザインを試みて、その有効性を検証する必要があるのです。そして有効なものをガイドラインに反映していくことで、組織が生み出すデザイン全体が進化していくのです。

もちろん、闇雲にガイドラインを破るべきではありませんし、ガイドラインに対してあまりに大きな変更を頻繁に加えるべきではないでしょう。それでは本来の「複数システム間の一貫性」が失われてしまうからです。ですから、ガイドラインを破ることの許可と、ガイドラインの変更方針は、慎重に検討されるべきです。

Apple に見られるガイドラインのヴァイアブル・モデル

ガイドラインのヴァイアブル・モデルとして良い例は、Apple 社の Human Interface Guidelines です。

Apple 社は長年、サードパーティの開発者向けにデザインガイドラインを公開しています。そして Apple 純正のアプリケーションとサードパーティのアプリケーションは一貫性を持ってデザインされてきました。

Apple 社のガイドラインは、同社が提供する開発用のUIフレームワークと連動した内容となっていますが、このUIフレームワークが新しいデザインを伴って頻繁に更新されるため、それに準じてガイドラインも毎年のように更新されています。

Apple 社ではサードパーティに対してガイドラインへの準拠を強く指示しており、iOS や macOS のアプリケーションは、ガイドラインへの違反が顕著であると公式ストアへの掲載審査にパスできません。そのため、サードパーティの開発者やデザイナーはガイドラインを読み込み、また公式のUIフレームワークをできるだけ十分に利用して、ガイドラインに準拠するように努めることになります。

一方、そのデザインガイドラインを真っ先に破るのは、いつも Apple 社自身なのです。iOS や macOS は毎年のようにバージョンアップされますが、それらに含まれる純正アプリ（ウェブブラウザやメーラーなど）は、よく、ガイドラインには載っていない（または載っているのと異なる）表現を含んでいます。将来の標準とすべき新しい表現が Apple 社によって実験的に純正アプリの中に実装されているのです。そしてその表現に問題がないと分かったら、次の年のバージョンアップのタイミングでそれらの新しい表現はガイドラインとフレームワークに組み込まれ、サードパーティも真似できるようになるという仕掛けです。

例えば、昨年リリースされた iOS 10 の「ミュージック」アプリでは、それまでの iOS にはなかった、大きな画面タイトル文字が用いられていました。本来、ガイドラインやフレームワークに従って実装すると、画面タイトルはスクリーン上部のナビゲーションバーの中央に小さな文字で表示されるのですが、iOS 10 のミュージックアプリでは画面タイトルが大きな文字で左寄せに表示されているのです。このような実装をサードパーティが行った場合、もしかすると Apple 社から指摘を受けるかもしれません。しかし Apple 社は特権的に自らそのガイドラインを破ったのです。

そして1年後の今年発表された iOS 11 では、この「大きなタイトル文字」を表示するための API がフレームワーク内で公開され、サードパーティの開発者が利用できるようになりました。同時に、新しいデザインガイドラインの中で、タイトル表示方法のひとつとしてこの大きな文字のスタイルが正式に記載されたのです。これはほんの一例ですが、Apple 社はずっとこの方法でデザインの標準を更新してきたのです。

このように、デザインガイドラインを持続的に機能させるには、製品とガイドラインが互いに影響し合うフィードバックループを形成する必要があります。ガイドラインは、複数の製品に対して一貫性を与えるために存在しますが、ガイドライン自体が有効であり続けるためには、新しく作られていく製品の方から逆に影響を受け、変化していくものでなければならないのです。

そしてこの生存可能モデルを実行するために、組織には、製品横断的なデザイン意思決定を担う責任者や、部門間でのデザイン共有を促す運用チームが必要になります。デザインガイドラインのあり方を考えることは、すなわち、組織をデザイン駆動型に転回していくための重要なきっかけとなるのです。