ブログblog

デザインシステムの世界

Writer： otsubo　更新日：2024/10/11

こんにちは、デジナーレ福岡オフィスの大坪です。

みなさん、「デザインシステム」という言葉を聞いたことがありますか？ 

デザインシステムとは、製品やブランドのデザインを一貫して効率的に作り出すための、ルールやコンポーネント(部品)の集まりです。 言わば、デザインのためのレシピ本やレゴブロックのセットのようなもので、これによりデザイナーやエンジニアは毎回一から作り直すことなく、品質の高いデザインを素早く作ることができます。

本記事では、デザインシステムの基本概念、エンジニア目線でデザインシステムで気を付けておくことについて解説していきます。

 

デザインシステムの目的

デザインシステムの主な目的は、ウェブサイトやSNSといった全てのサービスと接する場面で、エンドユーザーに対し一貫した体験を効率的に提供することです。 FigmaやAdobe XDといったツールを使ってデザインを作成しますが、この時にコンポーネントと呼ばれる再利用可能な部品を設計していくことで、デザイン作業の効率性を向上させます。 このコンポーネントは効率だけではなく、統一されたデザインを可能にし品質を保ちつつ、デザイナー、エンジニア、プロダクトマネージャーといったプロジェクトに関わるすべてのチームにとって「信頼できる唯一の情報源」となります。

つまり、デザインシステムは共通認識を持つためのツールとして機能します。ただし、プロダクトの数、チームの規模、事業フェーズなどによって変化していくため完成形はなく、目的達成のためにトライ＆エラーを繰り返しながら継続的に改善していく過程こそがデザインシステムの本質と言えます。

 

デザインシステムの構成要素

典型的なデザインシステムは、以下の要素で構成されています：

  1. デザイン原則：企業の理念や対象となるプロダクトに対しての思想を記述したもの。これが明確になれば、様々なチームやメンバーで共同作業をすることになったとしても、何を重視しなければならないかが判断できるようになります。
  2. スタイルガイド：カラー、タイポグラフィ、アイコンやスペースなど、UIを構成する要素をまとめたもので、ここで定義されたスタイルやプロパティを使って、画面やコンポーネントを作成していきます。また、エンジニアもスタイルガイドの内容を元に実装していくので、数値や命名は注意して定義しておく必要があります。
  3. パターンライブラリ：コンポーネント、レイアウト、テンプレート、デザインパターンといった再利用可能な要素をまとめたコレクション。UIを作成する時にはこのパターンライブラリから必要な部品を探し出し、レゴブロックのように組み立てていきます。

このほかにも、ライティングガイド、実装コード、イラストレーション・アニメーション、なども必要な場合があります。

これらの要素を組み合わせることで、一貫性のあるデザインを効率的に作成できるのです。

 

デザインシステムを始めるには？

デザインシステムの構築は、多くの企業にとって重要な課題です。しかし、どこから手をつければよいのでしょうか？
まずは、デザイン原則とブランディングを確立することから始めましょう。これが基盤となります。
次に、現状の洗い出しや分析が必要です。もし、既存のプロダクトの改修が必要であれば、そのプロダクトの問題点を把握する必要があります。プロダクトがなく、０からシステムデザインを作成する場合でも同じです。ゴールを定め、どんなデザインが必要なのかを洗い出していく必要があります。
ここで重要なのは、小さなスコープから始めること。一度にすべてのデザインを作成するのは不可能なので、デザインシステムの構築は小さなスコープで始めるのがいいとされています。
例えば、ユーザーインタラクションの多いボタンUIから着手するのも良いでしょう。

段階的に拡張していくこのアプローチにより、持続可能なデザインシステムの開発が可能になります。小さな成功を積み重ね、徐々に大きな成果へとつなげていきましょう！

ユーザーインタラクションって？

ユーザーインタラクションとは、ウェブサイトやアプリケーション上でユーザーが対話する方法のことです。

ユーザーとボタンの間でインタラクションはこのようなことが考えられます。

  1. enabled : ボタンの初期の状態です。
  2. hovered：マウスカーソルをボタン上に置くと、色が変わったり、サイズが少し大きくなったりします。
  3. click/tap：ユーザーがボタンを押すと、アクションが実行されます。この時、ボタンの見た目が一瞬変化しします。
  4. focused：キーボードでナビゲーションする際、ボタンにフォーカスが当たると視覚的に強調されます。
  5. disabled：条件が満たされていない場合、ボタンがグレーアウトして押せなくなります。

 

実装を意識したデザインシステムの構築

デザインシステムが完成したら、次に重要なのはエンジニアとの連携です。
優れたデザインシステムも、実装されなければ意味がありません。デザインシステムも可能な限りエンジニアの実装を意識した設計が必要になってきます。エンジニアはデザインシステムで定義された通りに実装していきますので、この段階で不明な所があると、本来不要だったコミュニケーションが発生してしまう可能性があります。
理想はデザインシステムを見ただけで、デザイナーに質問が行かないように理解できるという事です。
もちろんそれは簡単なことではありません。ですが、どういうことに気を付けてデザインをすればいいか知ることはできます。以下の点に気を付けて、デザインシステム構築の段階でのミスコミュニケーションを防ぎましょう。

 

デザイン要素の具体的な定義

デザインを行う上で、コンポーネントのサイズ、色、動作などを明確かつ具体的に記述し、エンジニアが迷うことなく実装できるようにします。
例えば、

  • ● ボタンのホバー時の色の変化と遷移時間
  • ● フォームのバリデーションエラーの表示のタイミング
  • ● モーダルの表示/非表示時のアニメーション速度
  • ● レスポンスデザインにおける各ブレイクポイントでの要素の振舞い

また、デザイン上の制約や「やってはいけないこと」も明記したほうが親切でしょう。

  • ● ボタン内のテキストは一行に制限し、折り返さない
  • ● アイコンは指定されたサイズ以外で使用してはいけない
  • ● 指定したカラーパレット以外の色を使用してはいけない

これらのような曖昧な表現を全て明確にしていくことが出来れば、エンジニアの推測作業を最小限に抑えられ、デザインの意図をより正確に伝えられるでしょう。

 

命名規則の統一

Figmaのようなコラボレーションデザインツールでは、コンポーネントやプロパティ名は日本語でも命名可能です。しかし、実装のことを意識するのであれば日本語は避け、必ず英語で命名しましょう。
エンジニアは、デザインシステムに書かれているコンポーネントやプロパティ名と同じ名前を使って実装をしていきます。ここで命名規則が統一されていない・不適切であれば、また新たに命名し直さなくてはいけなくなります。

 

命名規則の記法

例えば、エンジニアがJavaScriptのライブラリであるReactを使用して実装を行うと仮定しましょう。
この場合、レイヤーやコンポーネント名はパスカルケースで書き、コンポーネントのプロパティ名はキャメルケースで命名にします。
そうすることで、エンジニアはそのままその名前で定義することができます。

キャメルケースとパスカルケース
どちらも複数の英単語の間の余白を入れずに一綴りで書く記法です。
先頭以外の単語の頭文字はどちらも大文字です。
キャメルケース(ローワーキャメルケース)：接頭辞を小文字から始める書き方
(例：camelCase, buttonIcon)
パスカルケース(アッパーキャメルケース)：接頭辞を大文字から始める書き方
(例：PascalCase, ButtonIcon)
この他にもスネークケースや、ケバブケースなどがあります。
プログラミング言語によっては記法が異なるので、エンジニアと連携を取ってどの記法にするか決めたほうがいいでしょう。

 

英単語の選択

英単語についても工夫が必要です。例えばヘッダーのUIを作成しているとしましょう。
この時ヘッダーを表すコンポーネントの命名で悩んだとします。
Header, NavgationBar, TopBar…といった候補が並びましたが、どの表現が適切でしょうか？

Header: 文書の冒頭部分を指す可能性があり、ページ上部の機能的な要素との混同が起きやすい。
NavgationBar: テキストが長くなると実装時にスペルミスの可能性が高まる。

TopBar: 位置を特定しすぎており、レスポンシブデザインでスマートフォンの時に位置が変わる場合、この名前は適していないかもしれない。

Headerを採用する場合は他のコンポーネントでHeaderといった命名を避ける、NavgationBarをNavBarに短縮して採用するといった検討が必要になってきます。

 

プロパティ名から意図を伝える

コンポーネントを作成した際、そのコンポーネントの状態や見た目が変わる可能性がある場合、適切なプロパティの設定する必要があります。ボタンのコンポーネントを例に考えてみましょう。

プロパティ名で意図を明確に伝える

  1. 状態の表現 前章のユーザーインタラクションの説明で考えられるボタンの状態（enabled, hovered, pressed, focused, disabled）を表すプロパティには state が適切だと考えられます。
  2. サイズの変更 レスポンシブデザインに対応するため、ボタンのサイズを変更できるようにします。size というプロパティ名が明確です。
  3. アイコンの有無 ボタンにアイコンを付加するオプションには、ブール値を使用します。hasIcon という名前で、アイコンの存在を直感的に表現できます。
  4. その他の懸念事項
    • type: もし、ボタンの種類が複数あるのであれば、必要かもしれません(primary, secondaryなど)
    • label: ボタン内のテキストが動的に変わる可能性があるなら、labelバリアントを追加しておけばデザインシステムを構築する時にラベルの修正がスムーズになりますし、エンジニアに対しても親切でしょう。

プロパティ名は、その役割や影響を明確に示すものを選びましょう。
特に３のような値がtrue, falseの二択の機能を持つコンポーネント場合(トグルスイッチ等)には、
hasIconのように３単元動詞 + 名詞、もしくはis + 形容詞、has + 形容詞といった機能に沿った命名を行うといいでしょう。この命名はエンジニアがメソッド名を定義するときの命名規則に合わせるので、バリアント名を見るだけで、エンジニアはメソッドを定義したらいいんだというのが瞬時に理解できます。

これにより、デザイナーとエンジニア間のコミュニケーションが円滑になり、エンジニアにとっても意図したデザインの実装が容易になります。

 

まとめ

デザインシステムは、一貫性のあるユーザー体験を効率的に提供するための強力なツールです。本記事では、デザインシステムの基本概念から実装を意識した構築方法まで解説しました。

コンポーネントを作成する際、そのUIだけでなく、バリアントや命名で苦戦することがあるかもしれません。バリアントを作成する上で「UI stack」という考え方を取り入れてみるのも良いでしょう。
UI stackについては、以前弊社ブログで紹介しておりますので、ぜひそちらもご覧ください！↓↓

 

デザインシステムには完成形がなく、継続的な改善が必要です。チーム全体で協力し、ユーザーのニーズやプロダクトの変化に柔軟に対応しながら、より良いデザインシステムを構築していくことが重要です。デザインシステムを通じて、効率的な開発プロセスと魅力的なユーザー体験の両立を目指しましょう。

otsuboの
他の記事を読む

otsuboの記事一覧
スタッフブログ一覧

関連タグ

UI デザイン 設計 UI/UX ウェブデザイン デザイン デザインシステム

デジナーレをもっと知るABOUT US