デザインシステム入門
最終更新
役に立ちましたか？
最終更新
役に立ちましたか？
デザインの構造を正しく捉えることは、UI の実装を専門にしているかどうかを問わず、開発生産性が高く、ユーザにとっても使いやすい実装を実現するための重要なポイントです。 この章では、Wantedly におけるデザインシステムの構成、そして UI を実装する上で基礎となる Wantedly の UI デザインシステムの概念と考え方について解説します。
なお、この記事はを元に書いています。
Wantedly のデザインシステムの全体像と UI デザインシステム
UI デザインシステムは何であるか/何でないか
UI デザインシステムの構成要素
UI デザインシステムを利用して UI コンポーネントを組み立てる
その他覚えておくと良いこと
Wantedly には、 "Graphic Standard" と "UI デザインシステム" というデザインに関する 2 つの基準があります。
: デザインの一貫性を保つ（らしさ を表現する）、デザインのガイドライン
価値観と原則
ビジュアルガイドライン: ブランドカラー, カラーパレット, フォント, ...
UI デザインシステム: UI や体験の一貫性を保つ、（実装に準じた）概念と UI の設計
スタイルガイド
Foundation(デザインパラメタ, デザイントークン): Elevation, テキスト(サイズ, 行の高さ), ...
Component: ボタン, テキストフィールド, ...
UI デザインシステムは、特定のプラットフォームや技術に依存しない概念です。 UI デザインシステムの実装として、「デザイナー向けの実装（Figma）」「Web 向けの実装（React）」「iOS 向けの実装」「Android 向けの実装」などが存在します。
特定の UI デザインシステムを実装したライブラリを指して "(UI)デザインシステム" というのは誤りです。 誤解が発生しないよう、正しい表現を使うように心がけましょう。
Wantedly の UI デザインシステムは「Wantedly の UI をデザインする上での共通の考え方とツール＆アセット」と定義されています。
Wantedly らしい UI をデザインするための共通の考え方とツール＆アセットを提供することにより、一貫した表現で、基本的なユーザビリティを備えた UI を効率的に生み出すことを目的としています。
具体的には、以下の 4 つが目的として挙げられています。
ブランド表現（Wantedly としての見た目と振る舞い）の一貫性を保つ
ベーシックなユーザビリティの担保
デザインアウトプットの効率化
細かい造形で悩まず、プロダクトとして大切な体験にフォーカスできるように
複数のプロダクトをまたいでも、共通の考え方で対応できるように
エンジニアとのフロントエンド開発、コミュニケーション、メンテナンスの効率化
エンジニア視点では、共通している考え方などを知っておくことで、デザイナーのコミュニケーションを円滑に行う（あるいは省略する）ことが可能になります。 結果として、開発速度やアプリケーション実装のメンテナンス性向上に寄与します。
エンジニアとしてはどうしても実装レベルの話、たとえば「共通 UI コンポーネントライブラリ」のようなものを想像してしまいがちです。 しかし。Wantedly の UI デザインシステムはあくまでも「共通の考え方とツール＆アセット」であることに注意が必要です。
UI デザインシステムの目的の一つに「エンジニアとのフロントエンド開発、コミュニケーション、メンテナンスの効率化」とありました。 これを高いレベルで実現するためにも、エンジニアが利用する実装（React や Swift などによる実装）がデザイン側実装と同じ抽象度であることが重要です。
UI デザインシステムは、複数のレイヤーが積み重なって構成されます。以下のレイヤーがあります。
UI コンポーネントを構成するためのデザイン最小単位である「Foundation」
Foundation の組み合わせからなる「Surface」
1 つ以上の Surface の組み合わせからなる UI コンポーネント
次の節から、それぞれの要素を見ていきます。
Foundation には以下の 10 の要素が存在します
Graphic Standard をもとに定義されているもの
Color Palette
Text
Icon
プロダクト開発上必要になるもの
Layout Unit
Responsive
Shape
Elevation
Dimming
Reaction
Basic Easings
順に紹介します。
Wantedly のデザイン上で利用されるカラーパレットです
ブランドカラーと統一性のある表現ができる色のセットです
blue, purple...のような色の種別と、blue400, blue500...のように色ごとのバリエーションが定義されています
Wantedly の青は blue400 です
whiteAlpha100, blackAlpha800 など半透明の白と黒は UI 上で頻繁に利用されます
グレースケールのテキストやアイコン、区切り線の色は黒または白の濃度で指定することで、背景色に対して常にコントラストを維持することができるためです
文字の大きさ、太さ、フォント、行の高さなど Typography に関するパラメタのセットです
忘れがちですが、太さも Text の定義に含まれます
つかみ 1(catch1), 見出し 3(headline3), 本文 1(body1) など、複数のテキストのスタイルが定義されています
英語 or 日本語、 PC or Mobile(Web or iOS or Android) でパラメタが変化したり、プラットフォーム固有のパラメタが存在することがあります
Wantedly のプロダクト上で利用されるアイコンです
Graphic Standard では実際に利用されるアイコン集と、アイコンを作るためのスタイルガイドが定義されています
レイアウトは基本的に 8px を基本単位として、その倍数で構成されます
場合によっては 4px の倍数が使われることもあります（sub unit）
逆に言うと、小数や奇数を CSS に書いていた場合は何か（解釈か元のデザイン）に間違っている可能性を疑いましょう
レスポンシブ対応における breakpoint を定義しています
Mobile（縦向きスマホ）、Tablet（縦向きタブレットや横向きスマホ）、Laptop（横向きタブレットや PC）の 3 種類を利用することが多いでしょう
Surface（後述）の形状を定義しています
R0, R4, R16 のように角丸の半径を表し、R100 の場合は円形となります
Z 軸方向の高さを shadow で定義しています
Z 軸方向の高さを、裏側の UI コンポーネントに半透明のレイヤをかぶせることで表現します
アラートダイアログのような、ページ内の上位のレイヤに表示されるモーダルな UI コンポーネントで利用されます
ユーザ操作の UI コンポーネントのリアクションの種類とその方法を定義しています
リアクションに通常状態（Normal）に加え、Hover, Pressed, Focused, Disabled の 5 種類が存在します
ベーシックなリアクション方法は「色のオーバーレイ」「Elevation」「色のオーバーレイ + Elevation」の 3 種類が存在します
ボタンなど小さい Surface には「色のオーバーレイ + Elevation」、TextField など大きいものには「Elevation のみ」というように、多くの場合は Surface の大きさで決まります
UI コンポーネントや利用箇所によってはリアクション方法がオーバーライドされることがあります
コンポーネントの状態が別の状態に変化するとき、時間に対してどのように変化していくかを定義します
CSS だと transition プロパティなどに渡す Easing Function に相当します
ユーザ操作が起点（direct）かそうじゃないか（indirect）や遷移にかかる時間によって利用すべき Easnig Function が決まっています
前述した Foundation のうち、Shape, Elevation, Reaction と Background Color(背景色) の 4 値を組み合わせることで、「色がついて、ユーザの操作に反応できる板」を作ることができます。これを Surface と呼び、あらゆるコンポーネントの基礎となります。
たとえば Wantedly Visit で使われるプライマリのボタンであれば、以下の 4 値から構成される Surface が基本で、その上に白い文字（Text は button）が乗っています。
Shape: R100
Elevation: 4
Background: VisitGrad（Wantedly Visit のプロダクトカラー）
Reaction: Color + Elevation, 白の overlay
UI デザインシステムに定義されているコンポーネントはもちろん、Wantedly のプロダクトの UI に登場するコンポーネントは原則この Surface から作られています。 UI を実装するエンジニアは、このことを意識しておくことでデザイン意図を正しく実装することができるでしょう。
例えばボタンであれば、ユーザへの訴求の強さに応じて 3 種類の Surface を使いわけます。
また、同じ強さであってもプロダクトごとに異なる Surface が定義されています。以下は People 用のボタン定義です。
また、そのコンポーネントが配置される場所の明るさ（あるいはシステムのライトテーマ・ダークテーマ設定）によってもコンポーネントの見た目が変わることがあります。
この 「プロダクト」と「明暗」の 2 つをまとめて Theme と定義しています。 3 種類の強さのボタンのように、同一テーマ内でのコンポーネントの種類分けを Variant と定義します。 Theme は visit-light や people-dark など、Variant はボタンであれば primary, secondary のようになります。
1 つの画面で利用される Theme は原則として 1 つですが、例外もあります。 たとえば Wantedly プロフィールページのグローバルヘッダには Variant が clear なテキストボタン・アイコンボタンがありますが、カバー画像の上に表示する関係で dark 系の Theme が使われます。
また、Surface の各種パラメタは Theme および Variant によって定められていますが、デザインによってはオーバーライドされることもあります。 たとえば Wantedly プロフィールのカバー画像下の CTA ボタンは Secondary と Primary の 2 つのボタンが並んでいます。 これらのボタンは本来 Elevation は異なる値が割り当てられていますが、「ページ上で 2 つ並んで浮いてるボタンが異なる高さに配置されている」というのは見た目上明らかに良くないため、Secondary の Elevation がオーバーライドされています。
Theme および Variant が定めるのパラメタには以下のようなものが存在します。
Surface
Shape
Background Color
Elevation
Reaction 種別
特殊な Reaction の設定
Reaction のオーバーレイの色
Reaction ごとの Foreground Color
Elevation の影の色
Foreground Color(文字色, アイコン色)
ボタンやテキストフィールドなど、一部のインタラクティブコンポーネントは TouchArea（タッチエリア）と呼ばれる余白を持ちます。
目的は「コンポーネントのタッチ可能領域を広げる」ことです。 Wantedly が提供するプロダクトは PC だけでなく画面の小さなスマートフォンでも多く利用されます。 小さな画面であまりに小さなコンポーネントを出していると、ユーザはタップするのにも苦労するでしょう。 コンポーネントの間が詰まっていると誤タップしてしまうかもしれません。
Google や Apple のデザインガイドラインでは Interactive Element のタッチ可能領域の最低値を定義しています。
Surface の節では 「Wantedly のプロダクトの UI に登場するコンポーネントは原則この Surface から作られている」 という説明をしました。 これが実際どういうことなのか、例をいくつか見てみましょう。
たとえば Wantedly Visit で企業が見る候補者のプロフィール画面には、以下のような UI コンポーネントが存在します。 全体として薄いグレー（正確には透明度の高い黒）が下敷きにあり、その上にホバーやクリックで色が変わるアイテムが乗っています。
このコンポーネントは以下 2 つの Surface の組み合わせで作られています。
背景はグレーでリアクションがない、リスト全体の Surface
背景はないがリアクションで overlay が乗る、リストアイテムの Surface」の 2 つを組み合わせています。
（この場合だと背景もリストアイテムにつけることもできますが、どちらがいいかはケース・バイ・ケースでしょう）
別の例として、以下の画像のようなクレジットカード情報入力フォームを考えます。 見た目上は 1 つのテキストフィールドコンポーネントに見えますが、実際は番号, 月/年, CVC の 4 つのフィールドが存在しています。
これも 2 種類の Surface の組み合わせであると考えます。
テキストフィールドの見た目で、内側の要素の hover や focus で見た目が変わる Surface（HTML 的には div）
背景と Elevation は無いが文字色だけは残っているテキストフィールド（HTML 的には input）
このように、Wantedly のプロダクト上の UI コンポーネントの多くは Surface の組み合わせで説明できるようにデザインされています。 これを知っているか知らないかで、UI 実装のスピードや精度は大きく変わるので覚えておきましょう。
最後に、「UI デザインシステムを利用する」「UI を実装する」など、デザイナーと協業することがあるソフトウェアエンジニアが覚えておくと良さそうなことを紹介します。
UI デザインシステムを眺めていると、あらゆる値がカッチリ決まっているように見えるかもしれません。 実際、UI の一貫性を保つため定義通りの値を使うことがほとんどです。 しかし、たとえば「ユーザに強く訴求したい」であったり「局所的な見た目の一貫性を優先したい」など、情報設計やビジュアル的な理由で、オーバーライドが発生することがあります。
Wantedly の UI デザインシステムは Foundation, Surface など一見すると完成されたものに見えますが、実態としては一般化しきれていない例外などがまだまだ残っています。実装者・利用者はそのことを理解して、「各種パラメタは拡張に対して開いておく」「例外を無理に一般化せずに、ケース集にストックしておく」ことを意識しておくといいでしょう。
また、関連して「勝手に単語を作らない」というのもちょっと意識するといいかもしれません。 ほとんどのケースでエンジニアはデザイナーよりも UI に関する知識が少ないため、エンジニアが「これと同じ概念かな？」と思ったら実は全然違っていた、みたいなことは起こりえます（Java と JavaScript は同じでしょ！って言われたら困りますよね？）。 UI コンポーネントの名前に自信がないときはデザイナーに確認して認識を合わせておくといいでしょう。 また、実装（React コンポーネント）の名前とデザイナーが使う名前を合わせておくと、よりコミュニケーションしやすくなってオススメです。
「UI デザインは直感で見た目が良くなるように作られている！」なんてことはなく、そこには原理・原則のようなものが存在します。 「UI デザイナーがどういうロジックで UI デザインを作っているか」を多少なりとも理解できれば、それはそのまま実装時のモデリング（コンポーネント設計）にも反映でき、UI をより正しく実装する助けになるでしょう。 正しいモデリングのもとに実装された UI はデザイナーの意図も反映されやすく、壊れにくい・拡張しやすいものになります。 「ここ揃ってないんだけど？」みたいな指摘を受ける頻度もかなり変わってくるでしょう。
デザイナーの成果物を実装しているときに、そのデザインの意図がわからず実装が難しくなるケースがあると思います。 そういうときに「デザイナーと話して確認する」という選択肢を持つようにしましょう。 たとえば「ここだけマージンが他とちょっと違うんだけど、なんでだっけ？」みたいな、ときに「エンジニアがデザインに関する知識をつけてエスパーで解決する」みたいなことはできなくはないでしょう。 しかし、エンジニアはデザインの専門家ではありません。誤った推測から誤った設計になってしまうよりは、時間とって話すほうが結果手戻りが少なくなる可能性もあります。
もちろん、コミュニケーション回数が増えるとオーバーヘッドは大きくなっていきます。効率の良いコミュニケーション方法は考えてみるといいでしょう。
デザイナーの業務は専門性の高いものなので、エンジニアからするとその成果物に対して何かフィードバックするのは難しい・あるいはおこがましいと思ってしまうかもしれません。 しかし、我々エンジニアがたまに勢い余ってバグを出すのと同じように、デザイナーの成果物も常に完璧というわけではありません。
Wantedly ではエンジニア・デザイナーが一緒になってプロダクトを作っています。 なのでいいプロダクトを作るために、お互いにリスペクトを持ちつつフィードバックしあえるような環境にしていけるといいですね。
UI デザインシステムの最小単位として、Foundation が定義されています。 と呼ばれるものと同義です。
と同じものと思って問題ないでしょう
TouchArea が存在することでコンポーネント同士の間隔が自然といい感じになるといった作用もあります。 これも で同じような話が紹介されています。
でも触れていますが、同じ言葉・同じ単語セットで会話をすることは円滑なコミュニケーションをする上で非常に重要です。 たとえば "Modal" という単語についてエンジニアとデザイナーでそれぞれ違うものを思い浮かべていた場合、話が噛み合わなくなります。
デザイナーがどういう原則のもとでデザインしているかを知るには、「」を読んでみるといいでしょう。 デザインの「4 つの基本原則」などわかりやすく解説してくれています。 原則を知らない状態で UI を実装するということは、インデントを知らずにプログラミングをしてるみたいなものと言えるかもしれません。
もよくまとまってておすすめです。
エンジニアが UI を実装していく中で違和感を持つことはたまにあるでしょう。 たとえば「実データを流し込んでみたらどうも変な感じする」や「実装した画面から情報を読み取りづらい気がする」など。 そういう違和感はデザイナーにどんどんフィードバックをしていくといいでしょう。 「」は良いフィードバックのために意識すべきこと・目的・テクニックやコラボレーション方法について解説してくれています。 フィードバックする際には、感情でフィードバックするのではなくロジカルにフィードバックをすることが重要です。 この本では、それがどういうことか具体性を持って示されているので、学びになると思います。
