> For the complete documentation index, see [llms.txt](https://docs.wantedly.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wantedly.dev/fields/apps/design-system-for-non-designers.md).

# デザインシステム入門

デザインの構造を正しく捉えることは、UI の実装を専門にしているかどうかを問わず、**開発生産性が高く、ユーザにとっても使いやすい実装を実現する**ための重要なポイントです。 この章では、Wantedly におけるデザインシステムの構成、そして UI を実装する上で基礎となる Wantedly の UI デザインシステムの概念と考え方について解説します。

なお、この記事は[ノンデザイナーズ・Wantedly デザインシステム完全理解ペーパー](https://www.wantedly.com/companies/wantedly/post_articles/395772)を元に書いています。

## Agenda

* Wantedly のデザインシステムの全体像と UI デザインシステム
* UI デザインシステムは何であるか/何でないか
* UI デザインシステムの構成要素
* UI デザインシステムを利用して UI コンポーネントを組み立てる
* その他覚えておくと良いこと

## Wantedly のデザインシステムの全体像と UI デザインシステム

ウォンテッドリーには、 "Graphic Standard" と "UI デザインシステム" というデザインに関する 2 つの基準があります。

* [Graphic Standard (internal)](https://www.figma.com/file/94aqAiQ5ZWq4CkgYV07r2J/ForDesigner): デザインの一貫性を保つ（らしさ を表現する）、デザインのガイドライン
  * 価値観と原則
  * ビジュアルガイドライン: ブランドカラー, カラーパレット, フォント, ...
* UI デザインシステム: UI や体験の一貫性を保つ、（実装に準じた）概念と UI の設計
  * スタイルガイド
  * Foundation(デザインパラメタ, デザイントークン): Elevation, テキスト(サイズ, 行の高さ), ...
  * Component: ボタン, テキストフィールド, ...

![デザインシステムが加速させるプロダクト開発 p12 (Yoshinori Kawasaki, 2019) https://speakerdeck.com/kawasy/design-system-and-scalable-product-development?slide=12](/files/4IiNaBYA5i1XcmI1SjJA)

UI デザインシステムは、特定のプラットフォームや技術に依存しない概念です。 UI デザインシステムの実装として、「デザイナー向けの実装（Figma）」「Web 向けの実装（React）」「iOS 向けの実装」「Android 向けの実装」などが存在します。

特定の UI デザインシステムを実装したライブラリを指して "(UI)デザインシステム" というのは誤りです。 誤解が発生しないよう、正しい表現を使うように心がけましょう。

![](/files/F0rCCFtek9BH1GND0sLI)

## UI デザインシステムは何であるか/何でないか

### これは何？

Wantedly の UI デザインシステムは「Wantedly の UI をデザインする上での共通の考え方とツール＆アセット」と定義されています。

Wantedly らしい UI をデザインするための共通の考え方とツール＆アセットを提供することにより、一貫した表現で、基本的なユーザビリティを備えた UI を効率的に生み出すことを目標としています。

具体的には、以下の 4 つが目的として挙げられています。

* ブランド表現（Wantedly としての見た目と振る舞い）の一貫性を保つ
* ベーシックなユーザビリティの担保
* デザインアウトプットの効率化
  * 細かい造形で悩まず、プロダクトとして大切な体験にフォーカスできるように
  * 複数のプロダクトをまたいでも、共通の考え方で対応できるように
* エンジニアとのフロントエンド開発、コミュニケーション、メンテナンスの効率化

エンジニア視点では、共通している考え方などを知っておくことで、デザイナーとのコミュニケーションを円滑に行う（あるいは省略する）ことが可能になります。 結果として、開発速度やアプリケーション実装のメンテナンス性向上に寄与します。

### 何ではない？

エンジニアとしてはどうしても実装レベルの話、たとえば「共通 UI コンポーネントライブラリ」のようなものを想像してしまいがちです。 しかし、Wantedly の UI デザインシステムはあくまでも「共通の考え方とツール＆アセット」であることに注意が必要です。 特定のプラットフォーム向けの実装のことを指して UI デザインシステムというのは誤りです。(e.g. React 向けのコンポーネントライブラリのことだけを指して UI デザインシステムというのは誤り)

UI デザインシステムの目的の一つに「エンジニアとのフロントエンド開発、コミュニケーション、メンテナンスの効率化」とありました。 これを高いレベルで実現するためにも、エンジニアが利用する実装（React や Swift などによる実装）がデザイン側実装と同じ抽象度であることが重要です。

## UI デザインシステムの構成

UI デザインシステムは、複数のレイヤーが積み重なって構成されます。以下のレイヤーがあります。

* UI コンポーネントを構成するためのデザイン最小単位である「Foundation」
* Foundation の組み合わせからなる「Surface」
* 1 つ以上の Surface の組み合わせからなる UI コンポーネント

![https://www.figma.com/file/94aqAiQ5ZWq4CkgYV07r2J/For-Designer?node-id=40%3A76 (internal)](/files/A2rDAcZt7foG6Oo88H3n)

次の節から、それぞれの要素を見ていきます。

### Foundation - UI デザインシステムの最小単位

UI デザインシステムの最小単位として、Foundation が定義されています。 [デザイントークン](https://blog.adobe.com/jp/publish/2021/03/29/cc-web-what-are-design-tokens)と呼ばれるものと同義です。

Foundation には以下の 10 の要素が存在します

* Graphic Standard をもとに定義されているもの
  * Color Palette
  * Text
  * Icon
* プロダクト開発上必要になるもの
  * Layout Unit
  * Responsive
  * Shape
  * Elevation
  * Dimming
  * Reaction
  * Basic Easings

順に紹介します。

#### Color Palatte

* Wantedly のデザイン上で利用されるカラーパレットです
  * ブランドカラーと統一性のある表現ができる色のセットです
* blue, purple...のような色の種別と、blue400, blue500...のように色ごとのバリエーションが定義されています
  * Wantedly の青は blue400 です
* whiteAlpha100, blackAlpha800 など半透明の白と黒は UI 上で頻繁に利用されます
  * グレースケールのテキストやアイコン、区切り線の色は黒または白の濃度で指定することで、背景色に対して常にコントラストを維持することができるためです

#### Text

* 文字の大きさ、太さ、フォント、行の高さなど Typography に関するパラメタのセットです
  * 忘れがちですが、太さも Text の定義に含まれます
* つかみ 1(catch1), 見出し 3(headline3), 本文 1(body1) など、複数のテキストのスタイルが定義されています
* 文字種 (Alphanumeric or CJK)、 PC or Mobile(Web or iOS or Android) でパラメタが変化したり、プラットフォーム固有のパラメタが存在することがあります

![https://www.figma.com/file/VxoGPQPihKXA9dPsU8sqSz/UIElements?node-id=0%3A2868 (internal)](/files/2V8hJw0ke1VlkEfRHkBs)

#### Icon

* Wantedly のプロダクト上で利用されるアイコンです
* Graphic Standard では実際に利用されるアイコン集と、アイコンを作るためのスタイルガイドが定義されています

![https://www.figma.com/design/VxoGPQPihKXA9dPsU8sqSz/UI-Elements?node-id=26604-2514\&t=8TQS6pP1s5MLAJcd-11 (internal)](/files/pr07QyZIP3Vusud6fA6K)

#### Layout Unit

* レイアウトは基本的に 8px を基本単位として、その倍数で構成されます
* 場合によっては 4px の倍数が使われることもあります（sub unit と呼ばれます）
* 逆に言うと、小数や奇数を CSS に書いていた場合は、何か（解釈か元のデザイン）が間違っている可能性を疑いましょう。デザイナーとコミュニケーションを取ることを推奨します。

![https://www.figma.com/file/VxoGPQPihKXA9dPsU8sqSz/UIElements?node-id=0%3A2232 (internal)](/files/vlOsr0EcKnY8N5gj6r4V)

#### Responsive

* レスポンシブ対応における breakpoint を定義しています
* Mobile（縦向きスマホ）、Tablet（縦向きタブレットや横向きスマホ）、Laptop（横向きタブレットや PC）の 3 種類を利用することが多いでしょう

![https://www.figma.com/file/VxoGPQPihKXA9dPsU8sqSz/UIElements?node-id=0%3A2416 (internal)](/files/TcqQNKqbJE4izh9yZeSC)

#### Shape

* Surface（後述）の形状を定義しています
* R0, R4, R16 のように角丸の半径を表します
* 円形、またはピル型の形状を表現したい場合は ROUND を指定します

![https://www.figma.com/file/VxoGPQPihKXA9dPsU8sqSz/UIElements?node-id=0%3A2571 (internal)](/files/uBegUfy8gfFOi5VpkCPn)

#### Elevation

* Z 軸方向の高さを shadow で定義しています
* [Material Design における Elevation](https://material.io/design/environment/elevation.html)と同じものと思って問題ないです
* 各レベルの影は計算によって求められます

![https://www.figma.com/file/VxoGPQPihKXA9dPsU8sqSz/UIElements?node-id=1438%3A0 (internal)](/files/OxxHdD47tlVrd0qyfRvx)

#### Dimming

* Z 軸方向の高さを、裏側の UI コンポーネントに半透明のレイヤをかぶせることで表現します
* アラートダイアログのような、ページ内の上位のレイヤに表示されるモーダルな UI コンポーネントで利用されます

![https://www.figma.com/file/VxoGPQPihKXA9dPsU8sqSz/UIElements?node-id=0%3A2551 (internal)](/files/5hMkzW6V5RRoN1O0xxff)

#### Reaction

* ユーザ操作の UI コンポーネントのリアクションの種類とその方法を定義しています
* リアクションに通常状態（Normal）に加え、Hover, Pressed, Focused, Disabled の 5 種類が存在します
* ベーシックなリアクション方法は「色のオーバーレイ」「Elevation」「色のオーバーレイ + Elevation」の 3 種類が存在します
* ボタンなど小さい Surface には「色のオーバーレイ + Elevation」、TextField など大きいものには「Elevation のみ」というように、多くの場合は Surface の大きさで決まります
  * UI コンポーネントや利用箇所によってはリアクション方法がオーバーライドされることがあります

![https://www.figma.com/file/VxoGPQPihKXA9dPsU8sqSz/UIElements?node-id=0%3A2182 (internal)](/files/wpJYuFLsHt9vXjz7xH7E)

#### Basic Easings

* コンポーネントの状態が別の状態に変化するとき、時間に対してどのように変化していくかを定義します
  * CSS だと transition プロパティなどに渡す Easing Function に相当します
* ユーザ操作が起点（direct）かそうじゃないか（indirect）や遷移にかかる時間によって利用すべき Easing Function が決まっています

![https://www.figma.com/file/94aqAiQ5ZWq4CkgYV07r2J/For-Designer?node-id=136%3A9341 (internal)](/files/txt1rgHF5TCtgVBoHHtQ)

### Surface - あらゆる UI コンポーネントの基礎

前述した Foundation のうち、Shape, Elevation, Reaction と Background Color(背景色) の 4 値を組み合わせることで、「色がついて、ユーザの操作に反応できる板」を作ることができます。これを Surface と呼び、あらゆるコンポーネントの基礎となります。

たとえば Wantedly Visit で使われるプライマリのボタンであれば、以下の 4 値から構成される Surface が基本で、その上に白い文字（Text は button）が乗っています。

* Shape: ROUND
* Elevation: 4
* Background: VisitGrad（Wantedly Visit のプロダクトカラー）
* Reaction: Color + Elevation, 白の overlay

![](/files/jFt4Zgsqq4R8ufmagCYc)

UI デザインシステムに定義されているコンポーネントはもちろん、**Wantedly のプロダクトの UI に登場するコンポーネントは原則この Surface から作られています**。 UI を実装するエンジニアは、このことを意識しておくことでデザイン意図を正しく実装することができるでしょう。

![https://www.figma.com/file/94aqAiQ5ZWq4CkgYV07r2J/For-Designer?node-id=136%3A7208 (internal)](/files/EiLuHID6jtiGTv0d3yxv)

#### Theme, Variant

例えばボタンであれば、ユーザへの訴求の強さに応じて 3 種類の Surface を使いわけます。

![](/files/05H5s2c0jshQVrkQCEYt)

また、同じ強さであってもプロダクトごとに異なる Surface が定義されています。以下は People 用のボタン定義です。

![](/files/G1awbgtaInOTSt0ROynR)

また、そのコンポーネントが配置される場所の明るさ（あるいはシステムのライトテーマ・ダークテーマ設定）によってもコンポーネントの見た目が変わることがあります。

![](/files/VpDARpfO4Joq9qVhefNP)

この 「プロダクト」と「明暗」の 2 つをまとめて Theme と定義しています。 3 種類の強さのボタンのように、同一テーマ内でのコンポーネントの種類分けを Variant と定義します。 Theme は visit-light や people-dark など、Variant はボタンであれば primary, secondary のようになります。

1 つの画面で利用される Theme は原則として 1 つですが、例外もあります。 たとえば Wantedly プロフィールページのグローバルヘッダには Variant が clear なテキストボタン・アイコンボタンがありますが、カバー画像の上に表示する関係で dark 系の Theme が使われます。

![](/files/SBNfijRNsB0yQx0gRWdE)

また、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(文字色, アイコン色)

### その他の UI デザインシステム構成要素

#### TouchArea

コンポーネントのタッチ可能領域を広げることを目的として、実際の要素の外側に不可視のタッチエリアを設けることがあります。 ウォンテッドリーが提供するプロダクトは PC だけでなく画面の小さなスマートフォンでも多く利用されます。 小さな画面であまりに小さなコンポーネントを出していると、ユーザはタップするのにも苦労してしまいます。 コンポーネントの間が詰まっていると誤タップしてしまうかもしれません。

Google や Apple のデザインガイドラインでは Interactive Element のタッチ可能領域の最低値を定義しています。これと似たような概念を原則として設けています。

* [Google の Material Design では 48px 四方](https://material.io/develop/web/supporting/touch-target)
* [Apple の Human Interface Guideline では 44px 四方](https://developer.apple.com/design/human-interface-guidelines/foundations/accessibility#buttons-and-controls)

個別のコンポーネントについてタッチエリアを定義するのではなく、原則として小さな要素についてはタッチエリアを設ける必要があると定義しています。特にモバイル向けのページ実装時に配慮されているか注意しましょう。

## UI デザインシステムを利用して UI コンポーネントを組み立てる

Surface の節では **「Wantedly のプロダクトの UI に登場するコンポーネントは原則この Surface から作られている」** という説明をしました。 これが実際どういうことなのか、例をいくつか見てみましょう。

たとえば Wantedly Visit で企業が見る候補者のプロフィール画面には、以下のような UI コンポーネントが存在します。 全体として薄いグレー（正確には透明度の高い黒）が下敷きにあり、その上にホバーやクリックで色が変わるアイテムが乗っています。

![](/files/WdILXwfcWxP38V62m3L8)

このコンポーネントは以下 2 つの Surface の組み合わせで作られています。

* 背景はグレーでリアクションがない、リスト全体の Surface
* 背景はないがリアクションで overlay が乗る、リストアイテムの Surface」の 2 つを組み合わせています。

（この場合だと背景もリストアイテムにつけることもできますが、どちらがいいかはケース・バイ・ケースでしょう）

![](/files/5X3qNLFd7no5czLw2mXV)

別の例として、以下の画像のようなクレジットカード情報入力フォームを考えます。 見た目上は 1 つのテキストフィールドコンポーネントに見えますが、実際は番号, 月/年, CVC の 4 つのフィールドが存在しています。

![](/files/IjbFwaQ1Tbb1zHptH6cS)

これも 2 種類の Surface の組み合わせであると考えます。

* テキストフィールドの見た目で、内側の要素の hover や focus で見た目が変わる Surface（HTML 的には div）
* 背景と Elevation は無いが文字色だけは残っているテキストフィールド（HTML 的には input）

このように、Wantedly のプロダクト上の UI コンポーネントの多くは Surface の組み合わせで説明できるようにデザインされています。 これを知っているか知らないかで、UI 実装のスピードや精度は大きく変わるので覚えておきましょう。

## その他覚えておくと良いこと・心がけ

最後に、「UI デザインシステムを利用する」「UI を実装する」など、デザイナーと協業することがあるソフトウェアエンジニアが覚えておくと良さそうなことを紹介します。

### UI デザインシステムの全てはオーバーライド可能である

UI デザインシステムを眺めていると、あらゆる値がカッチリ決まっているように見えるかもしれません。 実際、UI の一貫性を保つため定義通りの値を使うことがほとんどです。 しかし、たとえば「ユーザに強く訴求したい」であったり「局所的な見た目の一貫性を優先したい」など、情報設計やビジュアル的な理由で、オーバーライドが発生することがあります。

### UI デザインシステムに定義されているもの・されていないもの

Wantedly の UI デザインシステムは Foundation, Surface など一見すると完成されたものに見えますが、実態としては一般化しきれていない例外などがまだまだ残っています。実装者・利用者はそのことを理解して、「各種パラメタは拡張に対して開いておく」「例外を無理に一般化せずに、ケース集にストックしておく」ことを意識しておくといいでしょう。

### 言葉は正しく使おう

[プロダクトデザイナーと上手に協働するための心得](https://docs.wantedly.dev/fields/apps/collaboration-with-designers)でも触れていますが、同じ言葉・同じ単語セットで会話をすることは円滑なコミュニケーションをする上で非常に重要です。 たとえば "Modal" という単語についてエンジニアとデザイナーでそれぞれ違うものを思い浮かべていた場合、話が噛み合わなくなります。（デザインとしての "モード" を表現するためのモーダルなのか、ダイアログ要素を指しているのか、など。）

また、関連して「勝手に単語を作らない」というのもちょっと意識するといいかもしれません。 ほとんどのケースでエンジニアはデザイナーよりも UI に関する知識が少ないため、エンジニアが「これと同じ概念かな？」と思ったら実は全然違っていた、みたいなことは起こりえます（Java と JavaScript は同じでしょ！って言われたら困りますよね？）。 UI コンポーネントの名前に自信がないときはデザイナーに確認して認識を合わせておくといいでしょう。 また、実装（React コンポーネント）の名前とデザイナーが使う名前を合わせておくと、よりコミュニケーションしやすくなってオススメです。

W3C が公開している [ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/patterns/) を参考にするとよいかもしれません。

### デザイナーが何を考えているかを知ろう

「UI デザインは直感で見た目が良くなるように作られている！」なんてことはなく、そこには原理・原則のようなものが存在します。 「UI デザイナーがどういうロジックで UI デザインを作っているか」を多少なりとも理解できれば、それはそのまま実装時のモデリング（コンポーネント設計）にも反映でき、UI をより正しく実装する助けになるでしょう。 **正しいモデリングのもとに実装された UI はデザイナーの意図も反映されやすく、壊れにくい・拡張しやすいものになります**。 「ここ揃ってないんだけど？」みたいな指摘を受ける頻度もかなり変わってくるでしょう。

デザイナーがどういう原則のもとでデザインしているかを知るには、「[ノンデザイナーズ・デザインブック](https://www.amazon.co.jp/dp/4839955557)」を読んでみるといいでしょう。 デザインの「4 つの基本原則」などわかりやすく解説してくれています。 原則を知らない状態で UI を実装するということは、インデントを知らずにプログラミングをしてるみたいなものと言えるかもしれません。

[2019 年に実施されたノンデザイナー向けデザイン研修の資料 (internal)](https://wantedly.slack.com/archives/C91E7SCU8/p1653901056050939)もよくまとまってておすすめです。

### わからないことがあったら話をしよう

デザイナーの成果物を実装しているときに、そのデザインの意図がわからず実装が難しくなるケースがあると思います。 そういうときに「デザイナーと話して確認する」という選択肢を持つようにしましょう。 たとえば「ここだけマージンが他とちょっと違うんだけど、なんでだっけ？」みたいな、ときに「エンジニアがデザインに関する知識をつけてエスパーで解決する」みたいなことはできなくはないでしょう。 しかし、エンジニアはデザインの専門家ではありません。誤った推測から誤った設計になってしまうよりは、時間とって話すほうが結果手戻りが少なくなる可能性もあります。

もちろん、コミュニケーション回数が増えるとオーバーヘッドは大きくなっていきます。効率の良いコミュニケーション方法は考えてみるといいでしょう。

### フィードバックを恐れない

エンジニアが UI を実装していく中で違和感を持つことはたまにあるでしょう。 たとえば「実データを流し込んでみたらどうも変な感じする」や「実装した画面から情報を読み取りづらい気がする」など。 そういう違和感はデザイナーにどんどんフィードバックをしていくといいでしょう。 「[みんなではじめるデザイン批評](https://www.amazon.co.jp/dp/B01J2OEYLU)」は良いフィードバックのために意識すべきこと・目的・テクニックやコラボレーション方法について解説してくれています。 フィードバックする際には、感情でフィードバックするのではなくロジカルにフィードバックをすることが重要です。 この本では、それがどういうことか具体性を持って示されているので、学びになると思います。

デザイナーの業務は専門性の高いものなので、エンジニアからするとその成果物に対して何かフィードバックするのは難しい・あるいはおこがましいと思ってしまうかもしれません。 しかし、我々エンジニアがたまに勢い余ってバグを出すのと同じように、デザイナーの成果物も常に完璧というわけではありません。

ウォンテッドリーではエンジニア・デザイナーが一緒になってプロダクトを作っています。 なのでいいプロダクトを作るために、お互いにリスペクトを持ちつつフィードバックしあえるような環境にしていけるといいですね。

## 参考資料

* [ノンデザイナーズ・Wantedly デザインシステム完全理解ペーパー(元記事)](https://www.wantedly.com/companies/wantedly/post_articles/395772)
* [プロダクトデザイナーと上手に協働するための心得](https://docs.wantedly.dev/fields/apps/collaboration-with-designers)
* [Webアプリのデザインシステムライブラリ](https://docs.wantedly.dev/fields/apps/design-system)