本記事は『Figma for デザインシステム デザインを中心としたプロダクト開発の仕組み作り』の「Chapter 1 デザインシステムを知る」から抜粋したものです。掲載にあたって編集しています。
デザインシステムの目的
デザインシステムの目的は、サービスのあらゆるタッチポイントにおいてエンドユーザーに一貫した体験を効率的に提供することです。また、デザイナー、エンジニア、マーケター、マネージャーなどにとって「信頼できる唯一の情報源」となりプロダクト開発を支えます。最初からすべてを網羅することは不可能ですし、プロダクトの数、チームの規模、事業フェーズなどによって変化していくため完成がありません。トライ＆エラーを繰り返しながら、目的を達成するために改善を繰り返す挑戦こそがデザインシステムの本質と言えます。
デザインシステムの構成要素
どこまでをデザインシステムと呼ぶかは組織によって異なりますが、本書では以下のような構成を想定しています。
デザイン原則
ユーザーとの接点において何を重視すべきかを判断できるよう、考え方や思想を簡潔に記述したものです。デザインに限らず、マーケティングやコンテンツなどのあらゆる制作物に影響を与えます。
スタイルガイド
色、タイポグラフィ、エフェクト、アイコンなど、UIデザインを構成する要素をまとめた資料です。スタイルガイドで定義されたスタイルやプロパティを使って画面やコンポーネントを作成します。スタイルガイドの内容はそのまま実装コードに連携される状態が理想的です。
ライティングガイド
言葉や文章に関するガイドラインであり、スタイルガイドに含まれる場合もあります。ボイス＆トーン、表記ルール、用字用語などを含み、プロダクトに個性と抑揚を与えるための指針となります。
パターンライブラリ
コンポーネント、レイアウト、テンプレート、デザインパターンなど、再利用可能な要素をまとめたコレクションです。パターンライブラリから必要な部品を呼び出し、積み木のようにUIを構築していきます。エンジニアは、パターンライブラリから実装に必要な情報を抽出できます。
実装コード
コンポーネントをプロダクトに組み込めるよう記述したコードです。エンドユーザーが最終的に目にするのは実装コードによって表示されるスクリーンであり、デザイナーがFigmaで作ったUIではありません。そのため、デザイナーはUIが意図通りに実装されているかを確認する必要があります。
このほかにも、ブランドガイドライン、イラストレーション、アニメーション、インタラクションなども必要な場合があり、デザインシステムの範囲はどこまでも広がります。
デザインシステムのメリット
変更容易性と保守性
ひとつのプロダクトだけでも複数の画面が存在し、管理すべきUI要素やプロパティは無数にあります。ある要素を変更した際にプロダクトに散らばる同じ要素を確実に更新できるでしょうか。スタイルガイドやパターンライブラリであらゆる要素を一元管理しておけば、このような問題は解決します。例えばボタンの背景色を変更したい場合、スタイルガイドで定義された色の値を変更するだけで、すべての画面、すべてのコンポーネントにその変更が伝播します。
コラボレーションの強化
デザインシステムの構築はデザイナー1人でも始められますが、機能させるには各所の協力が必要です。エンジニアやマーケターをデザインプロセスに巻き込むことで、強固なコラボレーションが生まれるきっかけになります。プロダクト開発の認識がチームで一致していれば、迷うことなく前に進めます。
デザインの拡張性と一貫性
UIデザインを小さな部品に分解して管理するため、状況に応じた柔軟なカスタマイズが可能になるだけでなく、デザインの一貫性が向上します。複数のプロダクトで使用する共通ライブラリとして展開すれば、そのメリットはさらに大きくなるでしょう。
スムーズなオンボーディング
既存のスタイルやコンポーネントは新メンバーが開発プロセスに参加できるまでの期間を短縮します。デザイン原則はプロダクトの背景や組織文化の理解を助けるでしょう。同じことは外部組織に協力を仰ぐ場合にも言えます。デザインシステムはデザインの方向性やルールを理解してもらう最適なリファレンスとなります。
バリエーションへの対応
異なるモード（例：ダークモード、ライトモード）や異なるプラットフォーム（例：Web、iOS、Android）向けのデザインが必要になることがありますが、デザイナーのリソースが十分ではない場合は手が回りません。すべての要件に手作業で対応するのではなく、あらかじめルールを決めて適切な設計をしておけば、このようなバリエーションの作成を自動化できます。
デザインシステムをいつ始めるか
プロダクトや関係者が増え、誰が何をやっているのか把握できない状況は間違いなくデザインシステムが必要なタイミングです。デザインシステムに取り組むことで一貫性のあるブランディング、プロダクトの品質向上、リリースサイクルの高速化などが期待できます。
一方、小さな組織、小さなプロダクトにデザインシステムは不要かというと、そうでもありません。たった一人で作るプロダクトだとしても、デザインの変更容易性、保守性、一貫性は重要です。むしろリソースが少ないからこそ「作業」ではなく「考える時間」を確保したいはずであり、「いま作業しておけば未来の自分が助かる」と感じられるならデザインシステムの構築を検討するときです。また、多くのプロジェクトではデザイナーよりもエンジニアの人数が多いため、早めに構築しておけばチーム全体の生産性が向上します。
筆者の場合、プロトタイプフェーズを終えて正式リリースに向けたデザインを制作するタイミングで、組織の規模に関わらず構築を考え始めます。
デザインシステムを始めるには
小さく始める
シンプルな機能であっても、デザイン、実装、コードレビュー、リリースを経てエンドユーザーの元にプロダクトが届きます。このような一連のプロセスにデザインシステムを一斉に適用しようとすると、途方もない作業量や複雑さに直面します。実施できたとしても短期的にはエンドユーザーへの価値提供は限定的で、むしろ変更作業によるバグが発生する可能性が高まります。デザインシステムの構築と適用を小さなスコープで始めることでリスクを最小限に抑えられるだけでなく、その効果を実感しやすくなります。段階的なアプローチで少しずつ基盤を築き上げ、組織全体にデザインシステムをゆっくりと浸透させましょう。
デザインを洗い出す
ヘッダー、フッター、リスト、ボタンなど、既存のプロダクトからUI要素を洗い出し、スクリーンショットを集めてグルーピングします。画面サイズ別のデザインがある場合はサブグループとして細分化し、マーケティング用のバナーデザインや配信メールなども対象とします。エッジケースのみで使用されるUI要素や組織外での制作物など、デザイナーが把握していない内容もあるため、マーケター、エンジニア、マネージャーなど、関係者を巻き込んで実施できると理想的です。異なる視点からの洞察を得られるだけでなく、デザインシステムの考え方をチームで共有するきっかけにもなります。
現状把握する
既存のデザインを整理できれば、考慮が不足しているパターンや改善すべきUXが明確になります。プロダクトの歴史が長いほど集められたデザインに一貫性がないことに驚くでしょう。まずは現在位置を確認することで、次のステップに進みやすくなります。
組織の協力を得る
デザインシステムの構築はプロダクトチームが主導するべきですが、その運用には組織全体の協力が不可欠です。既存デザインの抽出と現状把握は、デザインシステムの重要性を説明する資料として役立ちます。デザインシステムが組織に与える価値やメリットを示すことで、ステークホルダーや経営層に具体的なイメージを持ってもらえます。
スタート地点を見つける
ユーザーインタラクションが発生する「ボタン」は基本的なUI要素であり、共通コンポーネントとしてデザインシステムに組み込むべきですが、必ずしもボタンから始めるのが最適とは限りません。ボタンはその種類や利用箇所が多いため、コンポーネントの設計や実装には時間と労力がかかる場合があります。組織やプロダクトの規模によって状況は異なるため、リリースまでのプロセスを無理なく完了できるバランスのよいスタート地点を見出してください。
著名な企業のデザインシステムを見てみると、コンポーネントやドキュメントの網羅性に圧倒されます。素晴らしい事例は数多くありますが、最初から大きな成果物を意識する必要はなく、何から着手するのかプロダクトチームで議論することが重要です。例えば、次のような観点で既存のデザインを検証します。
- 複数の同じような色が使われていないか
- 繰り返し使用するのに共通化されていない要素はないか
- アクセシビリティの基準を満たしているか
- コンポーネントのプロパティが実装と近いか
それでも何から始めたらよいか判断できない場合は、機能開発をベースにアプローチすることもできます。例えば「並べ替え機能」の開発が直近のタスクとしてある場合、並べ替えを変更するためのボタン、並べ替えの選択肢、現在の並べ替え方法を示すアイコンなどが必要になるはずです。それぞれのUI要素には色やタイポグラフィの設定が必要ですし、既存の要素を流用できるかもしれません。小さな機能であっても多くの要素が組み合わさっており、デザインシステムのスタート地点になりえます。
Figmaを使う理由
デザインには創造的な側面と機能的な側面があり、Webサイトやモバイルアプリも例外ではありません。実装方法を考慮せず「何を作るか」にフォーカスして探究的にオリジナリティを追求する創造的プロセスがある一方で、「どうやって作るか」を検討し、規約や制限の範囲内でUIを機能させる思考も必要です。
創造的プロセスだけであれば一貫性や保守性が損なわれますが、規約や制限ばかりにとらわれたデザインは魅力を欠いてしまいます。Figmaは創造性と機能性の両面にうまく適応したソフトウェアであり、デザイナーのクリエイティビティを妨げることなく、プロダクト品質の維持を可能にしてくれます。
コンポーネント、スタイル、バリアブルなどの機能は品質向上のためのルール設定と言えますが、そのルールから外れる方法も常に用意されています。デザイナーはFigmaを通じて規約と自由の両方を享受し、デザインを中心としたプロダクト開発の仕組みを構築できます。
世界中のプロフェッショナルに愛されるFigmaですが、デザイナー以外の誰もが簡単に扱えるのもよい点です。Webブラウザさえあれば始められるため、プロダクトチーム全員がデザインファイルにアクセスし、確認や編集を行えます。拙著『Figma for UIデザイン』では、その基本的な使い方からプロトタイピング、エンジニアへのハンドオフまでを解説しました。
本書では応用的な機能をデザインシステムの文脈でさらに深掘りします。コンポーネントやオートレイアウトを使わなくてもUIデザインを作成できますが、デザインシステムは構築できません。再利用可能な要素を誰もが使えるようにライブラリとして公開した上で、使用時のルールを明確にするにはFigmaのようなツールが必要です。
新しいツールの習得には時間を要しますが、Figmaは直感的かつ論理的であり、費やした時間を遥かに超えるような生産性を手に入れられるはずです。
