品質と効率の向上に貢献するデザインシステムとは？ 基礎知識から導入プロセスまで解説

近年、WEBサイトやモバイルアプリ、そして業務用のシステムなど、さまざまなデジタルプロダクトで「デザインシステム」が活用されています。

デザインシステムとは、簡単にいえば、あるべきデザインを正しく迅速に実装するための「仕組み」のことであり、スタイルガイドやコード化されたUIコンポーネントの管理ツールなど複数の要素で構成されます。デザイン品質と開発・運用効率の向上に役立ち、デザイナーだけではなく、フロントエンドエンジニアやプロダクトの責任者など多くの方に関係します。

では、デザインシステムは具体的にはどのようなプロダクトで導入され、どういう効果をもたらしているのでしょうか？ また、導入の際にはどのような手順でデザインシステムを設計・構築していけば良いのでしょうか？

このセミナーでは、デザインシステムに興味がある方・今後導入を考えている方に向けて、豊富な経験を持つコンサルタントが利用のメリットや導入前の検討ポイントをわかりやすく解説します。

Transcript

1. 品質と効率の向上に貢献する
   デザインシステムとは？
   基礎知識から導入プロセスまで解説
   2023 / 03 / 24
   NCDC 株式会社
   

   View Slide

2. まずは自己紹介
   2
   NCDCにはITコンサルタントとして入社。入社以来、
   プロジェクトマネージャーとして、デザインシス
   テム構築支援や建設系企業のシステム開発、UXデ
   ザインワークショップのファシリテーションなど
   を務め、幅広い分野に精通する。
   ITコンサルタント
   大沼 翔利
   

   View Slide

3. NCDCの事業領域
   3
   Business
   新規事業⽴ち上げからの伴⾛
   業務改⾰やIT改⾰の⽀援
   Design
   ユーザ視点での設計
   Technology
   技術による課題解決
   • コンサルティング
   • 新規サービス企画
   • PoC⽀援
   • デザイン思考
   • UX/UIデザイン
   • モバイル・Web先端技術
   • IoT / AI / AR
   • クラウドインテグレーション
   

   View Slide

4. 目次
   l デザインシステムの基本
   l そもそもデザインシステムとは
   l 導入によるメリット
   l デザインシステムの基本構成
   l 活用事例の紹介
   l 導入時のプロセス
   l 大まかなプロセスと心構え
   l 導入プロセス
   l 運用時のプロセス
   l 導入した後の運用が難しい
   l 運用プロセス
   l まとめ
   4
   

   View Slide

5. デザインシステムとは
   

   View Slide

6. そもそもデザインシステムとは
   l あるべきデザインを提供するための「ルール」や「実践方法」をま
   とめた『仕組み』です
   6
   デザインシステムとは、デジタルプロダクトの目的を
   達成するために首尾一貫したルールで編成された、お
   互いに関連づけられたパターンとその実践方法です。
   パターンは繰り返される要素で、これらを組み合わせ
   てインターフェースを作成します。（中略）実践方法
   とは、どのようにパターンを作成し、記録、そして共
   有するか。特に、チームで作業する時にどのように使
   用するかの方法です。
   『Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド』
   （著：アラ・コルマトヴァ）より引用
   デザインシステムとは「あるべきデザインを一貫性を
   持ってユーザーに提供するための仕組み」。
   デジタル庁 DesignSystem
   https://www.figma.com/community/file/1172530831489802410 より引用
   Design System
   スタイルガイド
   UIパターンライブラリ
   ルール・禁止事項
   デザイン原則
   

   View Slide

7. 導入によるメリット
   l 一貫したUX/UIを提供できる
   l 見た目やルールが統一されたUIによって、操作や動線に迷うことなく質
   の高いUXをユーザーへ提供することができます
   l デザインと開発の効率化
   l デザイナーはデザインファイル、エンジニアはコード化されたUIコン
   ポーネントをそれぞれ再利用することで工数を削減し、課題解決に注
   力できます
   l コミュニケーションコストの削減
   l デザイナーとエンジニア間のQA、メンバー交代による引き継ぎ、外部
   ベンダーへの説明などでかかるコストを削減できます
   7
   

   View Slide

8. デザインシステムの基本構成
   8
   Design Code
   エンジニア
   デザイナー
   参照
   Document
   デザイン原則、スタイルガイド、
   ソースコードなどUIに関わる
   あらゆる情報。
   コンポーネント、サンプル画面、
   デザイントークンなどビジュア
   ルデザイン作成に必要な情報
   コンポーネントライブラリ、
   HTML、CSSなどUI実装するとき
   に必要な情報
   ex.
   ex.
   ex.
   

   View Slide

9. デザインシステムの基本構成
   9
   引用：Material Design
   Document
   デザイナーもエンジニアもPMも、UI開発時にとりあえず見るところ。
   デザインと実装のルールが全て集約されています。
   

   View Slide

10. デザインシステムの基本構成
    10
    引用：デジタル庁DesignSystem
    Design
    デザイナーが画面イメージを作成するときに見るところ。
    デザインデータを再利用して画面イメージを作成することができます。
    

    View Slide

11. デザインシステムの基本構成
    11
    引用：Material UI
    Code
    エンジニアがUI実装するときに見るところ。
    ソースコードを再利用して正しいデザインでUI実装を進めることができる。
    引用：Carbon Design System
    

    View Slide

12. 活用事例の紹介
    

    View Slide

13. 活用事例その1：SmartHR Design System
    l クラウド人事労務ソフト「SmartHR」
    l コンポーネントからアクセシビリティまで幅広く提供されています
    l サービスビジョンが明確なので企業ブランディングの観点でもお手本のような事例です
    13
    

    View Slide

14. 活用事例その2：Airbnb Design Language System
    l 民泊プラットフォーム「Airbnb」
    l 豊富な実装パターンが提供されています
    l どんな要求に対してもパターンが用意されて
    いるため強いデザインガバナンスが働きます
    l カスタマイズして実装するケースはおそらく
    想定されておらず、ほぼ選ぶだけの状態です
    14
    「1ヶ月分のみ表示」
    「本日ボタンを表示」
    「リセットボタンを表示」など
    

    View Slide

15. 活用事例その3：LINE Design System
    l コミュニケーションアプリ「LINE」
    l 豊富なユースケースが提供されています
    l 詳細なUXパターンが記載されていることで、担当者が各画面のUXを適切に設計することができます
    l NGパターンが具体的に示されているので迷わずレイアウトすることができます
    15
    

    View Slide

16. l 社内システムでのみ利用する例もあり、NCDCでもご支援した実績があります
    l 外部に公開するわけではないため、ブランディングやアクセシビリティのような観点は
    不要なケースもあります
    活用事例その4：その他社内システム
    16
    向いてる 向いてない
    システム規模
    リリース頻度
    デザインの世界観
    開発方法
    大規模 小規模
    多い、継続的 少ない
    複数システム全体で統一したい 複数システムで分けたい
    スクラッチ開発 パッケージ開発
    

    View Slide

17. 導入時のプロセス
    

    View Slide

18. 大まかなプロセスと心構え
    18
    l 導入プロセスとしては大まかに以下の通りです
    l 手戻りは発生するものと割り切るのも大切です
    l プロジェクト中に追加で検討が必要なシーンが多いです
    l できるだけ準備は整えつつ心構えはしておき、まずは最小構成でリリース
    していくことが大事です
    デザイン原則を
    決める
    ガイドラインを
    作る
    コンポーネントを
    作る
    ガイドラインで定義されてない
    この実装パターン、どうする？
    デザインは問題ないけど
    挙動が想定と違うな
    …などなど
    デザインを
    作る
    実装する
    ドキュメント化
    する
    コンポーネント
    を選ぶ
    

    View Slide

19. 導入プロセス1：デザイン原則を決める
    l プロダクトを開発していく上で大事にしてほしいことをドキュメント化します
    l 具体的なデザイン指示ではなく、想いや考え方・あるべき姿などを明記します
    l 省略されがちですが最も重要な工程です
    l この後のガイドライン作成時に方針がブレにくくなります
    l 「なんで？」が明確なので社内でも利用してもらいやすくなります
    19
    

    View Slide

20. 導入プロセス2：ガイドラインを作る
    l 全体のスタイルに関わるガイドラインを作成します
    l 具体的な基準値や「この場合はこれを使う」といったユースケースを定義します
    l 必要に応じてサンプル画面を作成して全体のトンマナを調整します
    l プロダクトの印象を左右する要素なので時間をかけるべき工程です
    20
    

    View Slide

21. 導入プロセス3：コンポーネントを作る(1/4)
    l コンポーネントを選ぶ
    l そのプロダクトに必要なコンポーネントを選定します
    l Material UIやBootsrapなどの既存のUIフレームワークを参考します
    l 既に機能や画面が存在する場合はそこから抽出することもあります
    21
    デザインを
    作る
    実装する
    ドキュメン
    ト化する
    コンポーネ
    ントを選ぶ
    

    View Slide

22. 導入プロセス3：コンポーネントを作る(2/4)
    l デザインを作る
    l Figmaなどで、UIデザインを作成する際に再利用できる形でコンポーネントを作成します
    l PrimaryやSecondaryといった種類別に全て作成します
    l 通常時・ホバー時・disableといった状態別に全て作成します
    l ガイドラインと同様、サンプル画面と一緒に検討・作成していきます
    22
    デザインを
    作る
    実装する
    ドキュメン
    ト化する
    コンポーネ
    ントを選ぶ
    

    View Slide

23. 導入プロセス3：コンポーネントを作る(3/4)
    l 実装する
    l Storybookなどでコンポーネントのソースコードを実装します
    l UI実装の際に再利用できる形で作成します
    l ガイドラインに沿って、デザインと同じ見た目になるように実装します
    l コンポーネントの細かい挙動は参考にしたライブラリに合わせるのがおすすめです
    23
    デザインを
    作る
    実装する
    ドキュメン
    ト化する
    コンポーネ
    ントを選ぶ
    

    View Slide

24. 導入プロセス3：コンポーネントを作る(4/4)
    l ドキュメント化する
    l zeroheightなどのドキュメント管理ツールに全て集約します
    l デザインファイルやソースコードなど全てにアクセスできるようにします
    l サンプル画面やNGパターンを用意することでUI設計のサポートができます
    24
    デザイン
    原則
    デザイン
    ファイル
    ソース
    コード
    ガイド
    ライン
    ドキュメント
    配置例
    Design System
    デザインを
    作る
    実装する
    ドキュメン
    ト化する
    コンポーネ
    ントを選ぶ
    

    View Slide

25. 導入時のポイント
    l 小さく早くを意識する
    l ある程度出来上がってから組織に展開すると使用者の学習コストが高くなり、定着しにくくなります
    l 小さく早く展開して使用者からフィードバックを受けることで、使用者も巻き込んでデザインシステムを構築
    していくことができます
    l 開発言語をひとつに絞る
    l 複数の言語が使用されている場合でも、まずはどれか一つに限定することをオススメします
    l 管理する粒度を粗くする
    l 実装パターンやガイドラインを細分化すると、デザインの統一性が保たれやすくなります
    l 一方で開発チームの自由度が下がり読まれにくくなります
    l 初期段階では粗めの粒度で、プロダクトで必要になった段階で徐々に細かくしていくと構築コストと学習コス
    トを抑えることができます
    l デザインと実装の順番を決める
    l Atomic Design のように、小さいものから順にデザイン・実装を進めていくことをオススメします
    l 小さいものから始めると手戻りが少なく済みます
    25
    

    View Slide

26. 運用時のプロセス
    

    View Slide

27. 導入した後の運用が難しい
    l デザインシステムを組織内でリリースした後、どのようにメンテナンスしていくべきかを検
    討していく必要があります
    l 組織内のリソース状況や、デザインの統一性をどこまで重視したいかなど、メンテナンスの
    方針や構築すべき体制が変わってきます
    l 基本的には以下の3つに分類され、組織に合わせてそれぞれカスタマイズが必要です
    27
    分散型 集約型 バランス型
    

    View Slide

28. 運用プロセス1：分散型
    l このような場合にオススメ
    l デザインシステム専任チームを構築できるリソースがない
    l プロダクトや開発チームの規模があまり大きくない
    l 開発チームの提案をすぐに反映させたい、スピード重視
    l ある開発チームがデザインシステムの修正を提案し、他の開発チームがレビューする体制です
    l 少ないリソースでも運用できるためスモールスタートしやすく、提案が反映されるまでのスピードが早いです
    l 一方、デザインの統一性を保っていくのが難しく、通常の開発に加えてデザインシステムの管理業務をするこ
    とになるため開発チームの負担が大きくなります
    28
    デザインシステム
    修正提案
    レビュー＆マージ Design System
    開発チーム [A]
    提案内容チェック
    開発チーム [B]
    開発チーム [C]
    開発チーム [D]
    

    View Slide

29. 運用プロセス2：集約型
    l このような場合にオススメ
    l デザインシステム管理チームを構築できるリソースがある
    l プロダクト規模が大きい、開発チームが多い
    l デザインの統一性を重視して管理していきたい、クオリティ重視
    l 管理チームのみがデザインシステムの管理を行い、各開発チームは開発に集中する体制です
    l デザインの統一性を保ちやすく、デザインシステムを介して多くの開発チームのサポートができます
    l 全プロダクトの要求を満たすように提案の積み上げ〜反映まで全て行うことになり専任チームの負担が大きく
    なります
    29
    デザインシステム
    修正提案
    レビュー＆マージ Design System
    デザインシステム
    管理チーム
    開発チーム [A]
    開発チーム [B]
    開発チーム [C]
    開発チーム [D]
    

    View Slide

30. 運用プロセス3：バランス型
    l このような場合にオススメ
    l 開発チーム数や人数に対してデザインシステム管理チームの人数が少ない
    l プロダクト規模が大きい、開発チームが多い
    l デザインシステム管理チームと開発チームで要望を集約し、管理チームがデザインシステムの管理をして
    いく体制です
    l 分散型よりデザインの統一性が保ちやすく、集約型よりもデザインシステム管理チームの負担は軽減されます。
    l 分散型より要望が反映されるまでのスピードは遅く、集約型よりもデザインガバナンスは弱くなります
    30
    開発チーム [A]
    開発チーム [B]
    開発チーム [C]
    開発チーム [D]
    Design System
    Product Backlog
    修正提案・要望を
    一つにまとめている
    デザインシステム
    管理チーム
    優先順や要否を
    判定
    修正対応
    レビュー＆マージ
    

    View Slide

31. まとめ
    

    View Slide

32. まとめ
    l デザインシステムは「仕組み」
    l ドキュメント、デザイン、ソースコードの３要素で構成されます
    l デザイン原則→ガイドライン→コンポーネントの順に構築
    l ドキュメントは全てのデータにアクセスできるようにします
    l 導入時、まずは小さく始める
    l 最小構成で構築を進め、まずは使えるものを用意します
    l システムの拡張と共にデザインシステムを組織全体で育てていく意識が大切です
    l 運用時、最適な体制を考える
    l 組織のリソース状況を考慮した体制を整えます
    l 分散型、集約型、バランス型の3種類です
    32
    

    View Slide

33. NCDCではデザインシステムの検討から開発まで一貫してご支援しています
    l To-be像の検討・策定
    l プロダクトや組織体制などの特徴をヒアリングしてTo-be像を検討し、デザイン
    システムを内製化するための土台作りをご支援できます
    l コンポーネント・UIサンプルのデザイン支援
    l デザインレビューやガイドライン検討、デザインファイルの作成などのご支援
    ができます
    l Storybook導入による開発の効率化支援
    l 導入コンサルから実際の実装まで行い、フロントエンド開発の効率化をご支援
    できます
    33
    

    View Slide

34. ご清聴ありがとうございました
    l ウェビナー終了後ブラウザが下の画面に切り替わります。
    「続行」を押してアンケートにお進みください。ご質問・ご相談も受け付けております。
    34
    

    View Slide

35. View Slide