ここ最近、企業におけるデザインシステムの事例を公開したブログや資料を Twitter で多く公開されています。 あまりの多さに、追いきれていなかったので個人用にもまとめておこうと思い、記事を書いています。 それもそのはず、今回まとめた 2021/08/23 ~ 2021/09/17 だけでも 6 記事(例)ありました。
メルカリの記事では、「Design System Web」というデザインシステムを公開していて、React で作られていた旧「Design System Web」から Web Components で実装された新「Design System Web」へと移行したことが書かれています。
今までの Design System Web は React で作られているために、React で作られたプロダクトでしか採用することができません。新しい Design System Web もよりモダンな体験を、以前よりも広いスコープでユーザーに提供するために作り直されることになり、そのための技術選定が必要になりました。
メルカリでは、チームによってフロントエンド開発における技術スタックを選択できるため、「Design System Web」の開発ではライブラリに依存しない Web Components を採用したそうです。
各ライブラリの仕様に引っ張られて細かい箇所で挙動が違ったり、メンテナンスや実装速度の都合上仕様に差分が出てくることは避けたいと考えていました。以上のことから、新しい Design System Web を構築する技術スタックは Web Components を採用しました。
「Design System Web」では以下の機能を保証しているそうです。
"アクセシビリティ(a11y)対応" や "国際化(i18n)対応"に関しては、プロダクト開発者がロジック実装に集中できるようにコンポーネントを設置するだけでアクセシビリティに対応できるようにしているそうです。
Yahoo!は、デザインシステムを以下の機能を有するとし、目的を明確にしています。
色やタイポグラフィ、要素の形状などをルール・用語集としてスタイルガイドに定め、それを実際のプロダクトに直ちに用いることができるライブラリとして提供します。これにより、プロダクトの迅速な開発と提供を可能にし、チームの生産効率を高めます。また、プロダクトを利用するユーザーに対しては、一貫したデザインによってプロダクトに対する学習を助け、ユーザー体験を向上させます。
「Riff」は、以下の 4 つのプロダクトで構成されています。
- スタイルガイド
- UI ビジュアルデザインにおける基本的な指針を定義したもの
- Riff Design Token
- スタイルガイドで定義している各種トークン情報
- Riff Design Kit
- Sketch で利用できる UI ライブラリ
- Riff React
- React で利用できる UI ライブラリ
Riff」は、、複数のサービスで横断的に利用されるため、より汎用的なコンポーネントが求められていると書かれています。
Riff では、ボタンや入力フォームといった、再利用や組み換えが容易であり、順応性に優れたコンポーネントを主に提供しています。 Riff はさまざまなサービスで横断的に利用されるのを想定しており、サービスの文脈を阻害することなく汎用的に利用できるコンポーネントが求められるためです。
また記事には、フロントエンド開発における"デザインシステムの開発・運用時における改善の取り組み"について、「利用者の使いやすい状態になっていたり、迅速に提供し続けていけるかも重要」であるとし、いくつかの改善例が紹介されています。
デザインツールの Sketch で管理していたアイコンデータをスクリプトで SVG コードを動的に生成するようにし、デザインシステム上でアイコンを常に最新の状態に保っているそうです。
これにより、利用者はデザインツールに依存せず、純粋な SVG のアイコンデータを簡単に利用できるようになります。この機能は Riff-Icon という新たなプロダクトとして提供する予定です。
また、記事の後半に環境に依存しないデザインシステムについても書かれています。
デザインシステムは利用者の環境やアーキテクチャを制限しないようにすることが望ましいです。仮に利用者の環境が何らかの要因で変える必要が出ても、デザインシステムと利用者側の環境に依存がなければ、次の環境へ移行したとしてもそのままスムーズにデザインシステムを利用し続けられるでしょう。
デザイン庁の記事では、デザインシステムに関しては構築中としていますが、庁内で勉強会を開催した事例が紹介されています。 また、デザイン庁はデザインシステムについて、以下のように考えているそうです。
利用者にとっての使いやすさ・求める情報へのたどり着きやすさ、また開発の効率化・管理コスト削減の観点で改善の余地が大きいと考えています。
その解決に向けて、デザインやコンテンツ構成等の標準化・統一化を図るためのデザイン原則案を策定することが、「デジタル社会の実現に向けた重点計画」にも定められました。
デザインシステムとは「あるべきデザインを一貫性をもってユーザーに提供するための仕組み」です。
そして、今秋中にデザイン減速案を策定し、その後は各省庁へデザインの統一化を進めていくと書かれています。
記事中には、
これから作り上げていくデザインシステムは、利用者や提供者のみなさまと共に作り上げていきたいと考えています。そのためにも、まずは必要最小限のデザインシステムの構築から始めています。今後の動向も引き続きお伝えしたいと考えていますのでどうぞよろしくお願いします。
mikan を運営、開発している mikan はデザインシステムを以下のように定義しています。
本題に入る前に、この note で書いている「デザインシステム」の定義について触れておきます。デザインシステムとは「良いデザインを『効率的』かつ『一貫性』をもって提供するためのプロダクトのためのプロダクト」です。
記事では、デザインシステム構築を始めるための"最初の一歩"にフォーカスを当てて紹介されています。
「デザインシステム（=1 プロダクト）は 1~2 ヶ月で作って終わりではない」という前提のもと、"最初の一歩"はこうやって進めたというプロセスを共有できればと思います。
デザインシステムを構築するまでに、mikan が抱えていた課題を解決するために、まずは Figma 上のデザイントークンやコンポーネントライブラリの構築から着手したそうです。
デザイントークンやコンポーネントライブラリの構築を行い「デザイナーリソースを効率化する」ことを目指すことにしました。
mikan は、デザインシステムの構築を行う前に、デザイントークンの定義を行い、
やることは単純で、「ほとんど同じ見た目・役割なのに微妙に違うコンポーネント」を洗い出し、定義すべきコンポーネントを見極めることです。
今回はコンポーネントの粒度として、Foundation のような汎用性の高いコンポーネントより具体的な、「ある画面内で複数回使われる」または「デザイナーが頻繁に利用する」コンポーネントも定義していきました。
定義するコンポーネントの抽象度は、デザインシステムの設計にも通ずる部分ですが、提供しているプロダクトの特性に合わせて決めるといいです。それによって DesignSystem の担うべき役割や全体設計が変わってくるので、すり合わせを行いましょう。
トップには Readme やデザインシステムの構成が書かれています。 粒度の細かいコンポーネントやデザイン、カラートークンが公開されています。
記事内では、"学びと反省について"も掲載されていて、
カラースキームの設計は初期からやっておくべきだった
旧データは全部別で保存しておいた方が、いい
デバイス横断の知識、細部のクオリティ
デザインシステムへのオンボーディング
特に、"デザインシステムへのオンボーディング"に関しては、デザインシステム構築中に新しいデザイナーが Join したときのオンボーディングについても書かれています。
その中で定義していったものの設計背景を共有したり、今後の運用方法などについて少しずつ「自分以外のデザイナーが扱える」状態にしていく必要があります。これは一歩目を構築したデザイナーの重要な責任だと思うので、構築が終わった後もある程度の期間は運用サポートや修正を引き受けて軌道に乗せてあげるのがよさそうです。
サイバーエージェントが Ameba 事業で公開しているデザインシステム「Spindle」を公開しました。
デザインシステム「Spindle」は、Ameba のビジョンである「100 年愛されるメディアを創る」を元に実装されています。
Ameba はビジョンとして「100 年愛されるメディアを創る」を掲げています。
ということは 100 年続くサービスでなければいけませんし、そのために時代に合わせたアップデートしないといけません。
事業として停滞させず、継続的に成長し続けるためにとても重要なことです。
こうした考えが 15 周年の節目で事業的にも見直す機会となり、ブランドをアップデートするというプロジェクトが動きました。
「Spindle」は、ビジョンを軸にドキュメントスタイルガイド等を一括管理されたデザインシステムになっています。
– ブランドやデザイン原則などのドキュメント
– 具体的な表現や振る舞いのためのスタイルガイド
– デザインツールや、実装コードに落とし込まれたコンポーネントライブラリ
ただアウトプットとしてこれらがすべて揃ってはじめてデザインシステムと呼ぶのかは組織によっても違いますが、Ameba の場合はこれらを包括したものを目指しました。
また、"デザインシステム"を
プロダクトとサービス全体を対象にした「設計」としてのデザイン
と捉え、デザイナーやエンジニアだけに価値のあるものにならないような仕組みにしているそうです。
「デザイン」「システム」という言葉から、デザイナーあるいはデザイナーによるデザイン業務や、あるいはエンジニアのための何かと思われることもあります。そうではなく、プロダクトとサービス全体を対象にした「設計」としてのデザインと考え、「体験の一貫性」を効率よく設計するために、職種としてのデザイナー以外にも意味のあるものとしています。
Ameba のデザインシステムは言い換えるならば「Ameba を作るすべての人が、Ameba らしさを伝えるため約束事や、それを手助けするツールやガイドラインが揃ったデザインする仕組み」といえます。
「Spindle」という名前はに関しては、あえてキャッチーな名前を付けることで、コンセプトを体現し、組織の文化に根付かせる狙いがあるそうです。
デザインシステムに名前をつける、というのは最重要ではないかもしれませんが、コンセプトを表した名前のようなものはチームのアイデンティティにもなりますし、デザインシステムの浸透にあたっても「デザインシステム」よりもキャッチーな名前にしておくというのは戦略的には良いと感じています。少なくともこうした名前を持ったプロジェクトのようにしてしまうのは、私たちの会社の文化としても適切でした。
記事の中では、デザインシステムを設計や実装しているメンバーは皆、プロジェクトの掛け持ちをしていると紹介されています。 通常のプロジェクトに与えるデメリットよりも、現場のニーズを拾いやすいメリットの方が多いと考え、このような体制を敷いているそうです。
こうした横断的な活動において専任ではなく「掛け持ち」というのは事業優先度などの兼ね合いで活動がおろそかになるというアンチパターンもありますが、むしろ現場にいることで課題やニーズを拾えますし、当人が実感してその解決に取り組むきっかけにもなっています。
「Spindle」を公開する理由に関しては、外部に対してデザインに対する姿勢の発信によるブランディングの向上と採用効果が見込まれ、またドキュメント質を保つため狙いもあるそうです。
例えばプラットフォームサービスであれば、サードパーティの開発者向けに公開する意味はあります。それ以外にはデザインシステムが存在すること、あるいはそこに現れるその企業のデザインへの姿勢なども見られることから、採用の効果もあるでしょう。
Spindle の場合は、後者の採用目的も含めて「ブランディング」が今回にあるため、公開することに価値があると考えています。それ以外には外部のパートナーに協力いただくような場合にも参照してもらいやすいのも利点といえるでしょう。また副次的ですが一般公開されていることを意識することによってドキュメントの質を維持するという効果もあります。
記事内でも紹介されている、Ameba 進化するためのブランド戦略にも、「Spindle」に関する情報が記載されています。
アルプが開発する「Scalebase」では、既存のデザインシステムに対してのアップデートを行い、主に
について、紹介されています。
"色の選択基準の明確化"では、Figma の Contrast プラグインを使用し、視認性の高い色の組み合わせと低い色の組み合わせをコントラスト比から比べることができるようにアップデートしたそうです。
開発初期は特に問題なかったのですが、開発を進めていくうちにページの情報量や構造が複雑になり、色の選択基準が曖昧な部分が出たり、場所によってはかなり視認性が悪い色を選択してしまうことがありました。そこで WCAG 2.1 の Contrast Level AA に従い、十分なコントラストを確保する方針にしました。
"アイコンの視認性の向上"では、フロントエンドメンバーにどのアイコンを使うべきかを「新旧アイコン対応表」を用いて共有することで、ムダなコミュニケーションが削減できるようにしているそうです。
また、"情報の階層化"については、要素の密度が高い画面が増えてきたために情報構造が複雑化してきたペインに対して、配色やグルーピングの見直しを行ったと書かれています。
また色定義の見直し、密度が高いページでもスキャンの精度があがるようになりました。