一貫したデザインのためにデザインシステムを運用する方法

Ben Gremillion

BenはUXPinのコンテンツ戦略担当者です。 Webウェブデザイナーとバックエンド開発者の両方として働いています。

この記事はUXPinからの翻訳転載です。配信元または著者の許可を得て配信しています。

Sticky Design Consistency Isn’t as Awful as It Sounds

人は馴染みがあるものを信頼します。そのことを知っている多くのデザイナーは、作品をできるだけシンプルにするよう努めています。また、シンプルなデザインは実用的でもあります。たとえば、一度ナビゲーションバーをデザインすれば、すべてのページで使うことができます。

しかし、デザインコンセプトはどんどん変化します。新しいアイデアを持つデザイナーが古いプロジェクトを引き継いだり、新しいコーディング手法が昨年の最先端に取って代わったりすることもあるでしょう。その結果、一貫性のないビジュアルとコードの寄せ集めになってしまいやがて問題となります。

デザインの一貫性とは

デザインの一貫性がある製品は、変更を加えても見た目や動作が全体としてまとまりがあるように見えます。これは、特に大規模なサイトで、ユーザーが操作に迷わないようにするためのものです。

デザインに一貫性があると機能追加や改善が簡単になります。既存の外観に合わないかもしれない新しい要素を開発することがないからです。開発の観点では、既存のコンポーネントのライブラリからコードを書くと、コピー&ペーストでコードを書くことができ、バグの可能性が減ります。十分にテストされたコードを再利用することは悪い考えではありません。

基準を作り出すことは比較的簡単です。しかし、それらを運用するのは簡単なことではありません。

デザインシステムがプロジェクトを軌道に乗せる

一貫性を維持する最善の方法は、そのブランドが今の外見で今の機能になっている過程と理由を記録したドキュメントを用いることです。

デザインシステム(またはデザインガイドライン)がこれにあたります。デザインシステムによってガイドラインが提供されるので、プロジェクトで理想とされるトーンや見た目、態度に誰もが従うようになります。優れたドキュメントは、使用例やベストプラクティスについて説明し、コードスニペットを含み、PhotoshopやSketchなどのソースファイルで実際のビジュアルの例を示します。

1つのドキュメントに大きな責任が与えられることになりますが、これを機能させる方法があります。

強い承認を得る

日々ピクセル単位で作品を実装しているデザイナーは、デザインシステムについて、プロダクトマネージャーの承認を得て、公認をもらいましょう。多くの場合、デザインシステムが将来のコスト超過を防ぐのに役立つと説明すると、世間話よりもはるかに早く注目を集めるはずです。

契約の一部にする

社外か社内のプロジェクトなのかを問わず、デザイナーの成果物と責任について正式な合意を得ることで、プロジェクトを定義し、要件が肥大化するスコープクリープを防ぎ、誰が何を担当するかを明確にすることができます。多くの場合、一般的に完成品が成果物になることが多いですが、製品がリリースしたあとも長く持続するものにするためには、デザインシステムのドキュメントも同じく重要視する必要があります。

全員の承認をとる

プロダクトマネージャーから開発のインターンまで、デザインに影響を与えるすべての人がデザインシステムのドキュメントを知っておくべきです。これは、開発中において特に当てはまります。関係者全員に情報を提供し、アートディレクター、開発リーダー、プロジェクトマネージャーなどのステークホルダーを巻き込みましょう。最終的なドキュメントに正式な承認をもらうことが何より重要です。彼らに自分の承認に責任を持ってもらいましょう。承認が必要であることがわかっていると、人はドキュメントをより真剣に受け止めるようになります。

いつでも利用できるようにする

ドキュメントを仕舞い込まないでください。 Dropboxのファイルでも、社内のWebサイトでも、Google Documentでも構いませんが、デザインや開発に問題が発生したときに何を参照するべきか、全員に知らせるようにしましょう。

実用的にする

究極的なデザインシステムのドキュメントは単なるドキュメントではありません。すぐに使えるリソースを手に入れるための、リソースのコレクションやパターンライブラリに当たるものです。特に、テンプレートとコードスニペットは、デザインチームが新しい作品を素早く作るのに役立ちます。

更新し続ける

組織の目標とユーザーのニーズに合致し続けるように、約6か月ごとにドキュメントを見直してください。たとえば、ユーザーはまだ既存のアイコンを理解しているでしょうか。カスタマーサービスやユーザーテストで、ユーザーは親しみやすい口調で話しかけられる程、うまく反応することが明らかになっているかもしれません。ビジネスとして、まだ特定のコールトゥアクション(CTA)を強調し続けるべきでしょうか。ビジュアルのトレンドは変わっていないでしょうか。

変更する必要があれば、ステークホルダーとデザインシステムの変更について相談する時間をとりましょう。デザイナーのBrad Frost氏は次のように語りました。

「パターンライブラリが提供している製品の現状を反映しなくなると、時代遅れになります。」

上記では、デザインシステムのドキュメントには、タイポグラフィ、色、スタイル、使用するときのメモが含まれています。

何の一貫性を保つ必要があるのか

プロジェクトによって、多くの一貫性を保つ必要があります。ビジュアルの面では、ユーザーがその意味を理解しやすくするために、色、タイポグラフィー、アイコン、サイト全体における要素の配置が重要です。

しかし、機能を無視しないようにしましょう。モーダルボックスからプルダウンリスト、リンクの色に至るまで、サイトの仕組みは見た目と同じくらいに重要です。たとえば、アイコンはある種のお約束だととらえましょう。特定のシンボルが表示されている場所で、ユーザーは何を期待するべきかを知っている必要があります。何を期待すればよいのかわかれば、ユーザーはブランドを快適に感じる可能性が高くなります。

トーンと言葉も重要です。特に大きなプロジェクトにおいて、プロジェクトが多くのことをユーザーに伝える必要がある場合、一貫したメッセージがあることで、同じブランドとインタラクションしていると、ユーザーを安心させることができます。 MailChimpは自社の言葉遣いを上手く定めているだけでなく、デザインシステムを誰でも読むことができるように公開しています。トーンや言葉は、フォームラベルから送信ボタンまで、どんな小さなコピーでも統一する必要があります。

最後に、コードです。セミコロンが1つないことを知るために6ヶ月前のコードを見直さなければいけないように、ちょっとしたものが開発者をイライラさせます。コードが一貫しているほど、簡単に適用やトラブルシューティングをすることができます。好きかどうかは人に寄りますが、BootstrapFoundationのようなフレームワークは、共通のコードベースによって、特に異なる開発者間におけるデバッグコードが簡単になっている優れた例です。

一貫性をテストする方法

あなたのプロジェクトは一貫性が保たれていますか? それを調べるにはいくつかの方法があります。

  • インターフェイスを検査しましょう。手に入れることができるすべての要素のスクリーンショットを撮り、タイプ別に分類しましょう。要素はすべて同じである、どんな見た目なのかは既に知っていると決めつけないでください。比較しやすいように、すべて1画面で見えるように撮りましょう。
  • コードを検査しましょう。ほとんどのデジタル製品は、核となるコードのセットに基づいています。ルールに対する例外をリストしましょう。
  • ユーザーに次善策を求めましょう。ユーザーはあなたの検索ツールをナビゲーションバーよりも使用するでしょうか。ユーザーに使用してほしい方法ではなく、ユーザーが実際に製品をどのように使用するかを見つけましょう。
  • 調査結果を共有しましょう。チームやプロジェクトマネージャーに結果を見せましょう。驚くべきことに、一貫性がないことを説明しなければならないことで、その場しのぎの解決策や不適切な仮説が明らかになることが多いです。

まとめ

デザインの一貫性は、紙やプロトタイプだけでなく、ユーザー体験のあらゆる段階で、製品の見た目や機能をまるで最初から計画されていたかのように維持することです。人々は、理解しやすくUIについて何度も学ぶ必要がないブランドを信頼する傾向にあります。

初期投資のあと、一貫性を持たせることで、将来のデザインと開発をより迅速かつ簡単にし、憶測を取り除いてより費用対効果の高くすることができます。そして、一貫性は、デザインシステムのドキュメントという単一の情報源によって生まれます。パターンライブラリにしろ単一のPDFにしろ、デザインシステムは、ベストプラクティスのガイドラインといつでも利用可能なソースファイルを提供します。

デザインの不一致は、新しいチームメンバーが古いメンバーと替わったとき、または現在のデザイナーと開発者が古い仕事を改善しようとしたときに発生することを覚えておきましょう。どちらも避けられないものですが、共通のテンプレートからデザインしたり開発したりすることこそが、一貫性を保つ鍵です。

基準を作り上げることは、それを運用することに比べてかんたんです。しかし、どちらもプロジェクトを形作る上で重要です。ドキュメントが製品を語るようにしましょう。その逆はありません。


イベント

2017/12/05(火)
Design Thinking Square