> 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.md). # Web アプリのデザインシステムライブラリ ## TL;DR * Wantedly の UI デザインシステムは「WantedlyのUIをデザインする上での**共通の考え方とツール＆アセット**」であり**エンジニアとデザイナが効率よくコミュニケーションするための共通言語**となる * デザインシステムを (Web) Frontend に持ち込む際は、単なるコンポーネントカタログではなく、システムが定義するものと同じレベルの抽象を持つライブラリ・フレームワークとして実装することで、より有効性を発揮する ## UI デザインシステムについて ウォンテッドリーにおけるデザインシステムは、「プロダクト・デバイスをまたいでも・誰がデザインしても体験やブランドとしての一貫性を保つ」「デザインの生産性を向上させ、デザイナ - エンジニア 間コミュニケーションを改善することで、ユーザーに価値を届ける速度を向上させる」といった目的のために作られたものです。 より詳しくは、[デザインシステムが加速させるプロダクト開発 / Design System and Scalable Product Development](https://speakerdeck.com/kawasy/design-system-and-scalable-product-development)を参照してください。 次の2つの画像にあるように、Wantedly のプロダクトなどをデザインするときに利用するフォントなどのスタイルと、ボタンやテキストフィールドなどの UI コンポーネントなどが定義されています。 ![](/files/JrD0nX7TI3HOO7DjXAyG) ![](/files/2fB7SU5OutATBm6Wt1G3) ## Wantedly の UI デザインシステムとは何か・何でないか ウォンテッドリーが作っている「UI デザインシステム」とは何か、内部のドキュメントでは次の一文で表現されています（強調は筆者による）。 > WantedlyのUIをデザインする上での**共通の考え方とツール＆アセット** この「共通の考え方とツール＆アセット」とは何か、いくつか具体例を見ていきます。 たとえば「Button」を表すコンポーネントですが、Figma 上では以下のような決められた設定を持ちます。 ![](/files/OON44HwMA3Z5I6B4LFhd) また、上記の画像では Button の見た目よりも少し外側に線が出ていますが、実際にその空白まで含んで Button であると定義されています。これは TouchArea と呼ばれ、そのコンポーネントが持つべき最低限の余白を表しています。これは Button や TextField などの Interactive なコンポーネントに適用されており、余白自身もコンポーネントの一部になります。 > TouchArea によりコンポーネント間の余白がいい感じになるの図。この領域を含めて Apple や Google の Interface Guideline を満たすように設計されている。 ここまで例に上げたとおり、Wantedly の UI デザインシステムは「コンポーネントカタログ」ではなく、コンポーネントの構成要素・原則からなる「**共通の考え方とツール＆アセット**」であるというのがなんとなくわかってもらえたでしょうか。 ## なぜ UI デザインシステムを作るのか ウォンテッドリーでは何のために UI デザインシステムというものを作っているのか、社内のドキュメントでは以下のような目的が挙げられています。 * ブランド表現 - Wantedlyとしての見た目と振る舞い の一貫性を保つ * ベーシックなユーザビリティの担保 * デザインアウトプットの効率化 * 細かい造形で悩まず、プロダクトとして大切な体験にフォーカスできるように * 複数のプロダクトをまたいでも、共通の考え方で対応できるように * エンジニアとのフロントエンド開発、コミュニケーション、メンテナンスの効率化 ここでは「エンジニア」と明記されている「エンジニアとのフロントエンド開発、コミュニケーション、メンテナンスの効率化」について、なぜそうなるのかをもうちょっと掘り下げます。前節での「デザインをする上での共通の考え方とツール＆アセット」というのを前提として考えると、以下のような理由があると考えています。 * （UI）デザインシステムが、**エンジニアとデザイナが効率よくコミュニケーションするための共通言語**となる * UI デザインシステムにより、**コンポーネントの作り方に一貫したルール**が生まれる * このルールを知り、使いこなす（使いこなせるツールが存在する）ことで、誰でも「Wantedly らしい UI コンポーネント」が作れる 「デザイナがどういう言語を用いて、どのようなルールの上でデザインをしているか」をエンジニアが知ることで、コミュニケーションが円滑になり、背景・ロジックを知った上で実装ができるようになる。それにより「エンジニアとのフロントエンド開発、コミュニケーション、メンテナンスの効率化」が達成できるのではないでしょうか。 余談ですが「デザイナがどういう言語を用いて、どのようなルールの上でデザインをしているか」というのは、Web エンジニアが Ruby on Rails や Next.js といったフレームワークを利用するのと似たような構造に思えます。ウォンテッドリーのデザイナは**デザインシステムというフレームワークに乗ることで、細かいことを気にせずプロダクトの価値を生み出すことに集中できる**と解釈するとわかりやすそうです。 ## React 実装の設計 前節で（UI）デザインシステムは「**エンジニアとデザイナが効率よくコミュニケーションするための共通言語**」であり「**コンポーネントの作り方に一貫したルール**」をもたらすものである、という解釈をしました。また、「**UI デザインシステムというフレームワーク**」とも表現しました。これを実現するために、エンジニア向けの実装はどのようにあるべきでしょうか。 「共通言語」であり「一貫したルール」であるために、エンジニアとデザイナはデザインシステムに関して**同じレベルの抽象**をもってコミュニケーションしていく必要があるはずです。ライブラリとして提供する実装に関しても、基本的にはデザイナが扱っている抽象・フレームワークと同じレベルのものを提供していく必要があるでしょう。 「同じレベルの抽象」というとかなり抽象的な表現ですが、誤解を恐れずに言い換えると「**デザイナと同じロジックでコンポーネントを作れること**」ということでしょうか。わかりやすいところでいうと「デザイナがコンポーネントを作るときに指定するパラメーターが、そのまま実装されている」などです。もっと深堀りすると「ここのMessage は 見出し2 で...」みたいなものが、正しく React コンポーネントの実装およびインターフェースとなっている必要があります。 ![](/files/ynf6ZE8Ti5NzvVo9rc24) ```typescript const Message = styled(createText('h2', { textStyle: "headline2" }))`` ``` ここまでで満たすべき要件を確認したので、設計に移っていきます。前提として、TypeScript + React でシステムを実装していきます。これはウォンテッドリーにおける Web Frontend の主要な技術選択にあわせています。内部では [styled-components](https://styled-components.com/) を利用していますが、これは peerDependencies を除きインターフェースとして露出することは無いようにしています。 ### UI デザインシステム構成要素について これは React 実装に限らない UI デザインシステムの定義上の話です。UI デザインシステムは次の3\~段階の要素から構成されています。 * **Lv.0 Foundation** * 一貫した Corporate Branding のためのシステム * UI に限らない Graphic Standards: 色, フォント, アイコン など * UI で守るべき基本原則: Layout unit, Shape, Elevation, Reaction, Typographic scale * **Lv.1 Basic Components** * (Designer|Developer) Productivity を向上させるためのシステム * ボタンやテキストフィールドなどの基礎コンポーネント群 * Lv.2 ここまでの要素の組み合わせからなる UI コンポーネント群 * Lv.3 プロダクトの UX を向上させるための機能コンポーネント群 * ... Lv.2 以降に関してはそこまでのコンポー ネントの組み合わせが主になります。よって、Lv.0 Foundation および Lv.1 Basic components を React の上でどう表現するかがポイントになってきます（Lv.2以降についてはまたの機会があれば紹介します）。 ### Lv.0 Foundation Lv.0 Foundation には前述したとおり、色・フォント・アイコン・Elevation などのデザインパラメタが定義されています。また、[Elevation](https://material.io/design/environment/elevation.html) や Reactionなど UI コンポーネントの振る舞いの原則も含まれます（Reaction: [Material Design における State](https://material.io/design/interaction/states.html#usage) のような、Hover や Focus など、ユーザーのアクションによってコンポーネントに起こる反応のパターン）。 さて、この Foundation はどのように定義されていると良いでしょうか？ css の Syntax Sugar として定義されてほしい場合と、Component のパラメーターとして定義されていてほしい場合がありそうです。 ```js // css の Syntax Sugar として定義 const HeadText = styled(createText('span', { textStyle: "headline1" }))` color: ${colors.blackAlpha800}; white-space: pre-wrap; ` ``` ### Lv.1 Basic components Foundation の実装は Basic componentsとして実装されています ```js const Button = styled(createButton('button', {variant: "button-primary", size: "medium"}))`` ``` コンポーネントの実装は、ui-react-2022によって提供され、必要に応じてstyled-componentsでcssを上書きすることになります。 ## まとめ & Future work ここまでで、「Wantedly における UI デザインシステムとはなにか」「デザインシステムの React 実装の設計」について紹介しました。この記事で紹介したデザインシステムの実装は、Wanteldy の最近のプロジェクトで活用されています。 一方で、デザインシステムについては、ここで紹介した React 実装以外にもやるべきこと・やると良さそうなことが無数に残っています。いくつか例を上げると下のようなものがあります。 * Android および iOS 向けの実装 * デザイナ - エンジニアのさらなるコミュニケーション改善のためのエンジニアリング * エンジニア実装（React, Android, iOS, ...）とデザイナ実装（Sketch or Figma）のインテグレーション #### 話を聞きに行きたい * Slack: [#frontend\_chapter](https://wantedly.slack.com/archives/CA46K091P), [#design\_system](https://wantedly.slack.com/archives/CAS1153PD) * GitHub: `@wantedly/design-system-implementer` #### もっと知りたい * [React でデザインシステムを正しく実装する - コンポーネントカタログを超えて | Wantedly Engineer Blog](https://www.wantedly.com/companies/wantedly/post_articles/302873) * [UIデザインに必要な『一貫性』へのアプローチ - 管理画面のアップデートに際して | Wantedly Design](https://www.wantedly.com/companies/wantedly/post_articles/306400) * [ノンデザイナーズ・Wantedly デザインシステム完全理解ペーパー](https://www.wantedly.com/companies/wantedly/post_articles/395772)