共感されるデザインシステムをつくるべき理由とそのつくり方 | アドビUX道場 #UXDojo

連載

エクスペリエンスデザインの基礎知識

共感を持ってデザインシステムを構築するのは本当に重要です。共感を大事にすれば、新しいUXプロセスの採用により生じるかもしれない多くの不満や問題を解決することができます。この記事では、まずデザインシステムと共感について説明します。そして、共感の欠けたデザインシステムの採用事例から得られた重要な学び、どんな問題が発生して共感がどのように解決に役立ったかも紹介します。

デザインシステムとは何か?

デザインシステムとは何でしょう？どうすれば共感されるデザインシステムになるでしょう？デザインシステムという言葉を耳にすると、「コンポーネントライブラリ」「パターンライブラリ」「スタイルガイド」といった言葉が頭に浮かぶかもしれません。これらはすべてパズルの一部ですが、それだけではデザインシステムではありません。

ネイサン・カーティスは以下のようにまとめています。

「デザインシステムとは、
再利用可能な相互に連携する部品の集合
統合され相互に連携する製品の一群
協力的で相互に連携する人々のコミュニティ」

通常、コンポーネントライブラリは、企業全体で一般的に使用される一連の要素を指します。パターンライブラリは、企業全体で使用される一連のデザインパターンを指します。スタイルガイドは、ルック&フィール、UIパターンのユースケース、正しいタイポグラフィのサイズなど、デザインシステムの外観を記述する静的なドキュメントです。

共感とは何か?

共感とは、他者の感情を理解し共有する能力です。これはギリシャ語の「em」と「pathos」という2つの言葉から派生しています。Google BooksのNgram Viewerを見ると、「共感」という言葉への興味がこの70年の間に高まっていることが分かります。デジタル時代の深い分断の中で、これまで以上に人々がつながりを求めているとしたら、これは驚くことではありません。

共感とデザインシステムをまとめる

共感とデザインシステムを一緒に考えることは何を意味するのでしょう？それはつまり、デザインシステムを使って構築されたアプリを使うユーザーや、デザインシステムを利用する同僚、オープンソース化するならそれを使う外部の関係者といった人々のニーズに注意を払うことです。

UXデザインプロセスにおける問題について議論すると、しばしばあらゆる領域に話が及ぶのを耳にすることになります。ユーザテストや要件の確認に始まり、役割の異なるチーム同士のコラボレーションやエンジニアへの仕様の伝達まで、様々な話題が話されます。それぞれは異なる話ですが、いずれもユーザーや同僚との共感に関連があります。つまり、UXプロセスの問題を解決するには、少しの共感が助けになるのです。

ケーススタディ

前の職場で働いていた時に、デザインシステムの立ち上げに参加しました。私たちがそれを始めた理由は、会社がブランドの再構築に取り組んでいる最中で、新しいデザインをシステムに取り入れることに着手するのが理にかなっていたからです。既存のスタイルガイドが、古い世代のCSS生成ライブラリKSSを使用していたため、それを置き換えたいという理由もありました。

ネイサン・カーティスのツイート。静的なドキュメントであるスタイルガイドと、運用される動的なエコシステムであるデザインシステムを対比している

このプロジェクトには、フロントエンドプラットフォームチーム全体が関りました。3人のシニアフロントエンドエンジニア、新人研修から雇われた3人の新人エンジニア、そして最大15人のデザイナーが参加していました。

それと、フロントエンドプラットフォームチームは、デザインシステム構築プロセスの一部として、BackboneからReactに移行することを決定しました。

私たちが上手くできたこと

ファイルの生成

plop.jsを使い、デザインシステムに新しく追加されたコンポーネントに関連する一連のファイルの生成を行いました。これにより、ファイル名とフォルダ構造の一貫性という利点を得られました。

文書化

デザインシステムのホームページに以下の情報を掲載しました。使用されているアトミックデザインのシステム、デザインシステムへの貢献の仕方、コンポーネントのデザインに採用されたアプローチの3点です。

計画的なアプローチ

デザインシステムに貢献するには、標準化された一連のドキュメントに情報を記述することを必須にしました。

アクセシビリティ

eslint-plugin-jsx-a11yパッケージを使用して、デザインシステム全体における一部のアクセシビリティを自動化しました。また,アクセシビリティの障害となりがちなモーダルの使用には特に注意を払い、問題が無いことを確認しました。

私たちが上手くできなかったこと

検索

デザインシステムの検索機能は、コンポーネント名から調べるものでした。しばしば指摘されたのは、自分が知らないことはわからないということです。デザインシステムにおいて、コンポーネントの名前がわからない場合、どのように検索することができるでしょうか？

命名

物に名前を付けるのは難しいものです。当初、このデザインシステムは「Black Panda」というコードネームでしたが、新規の利用者を混乱させる場合がありました。その後、名称は「company’s design system」に変更されました。しかし、多くの人がCDSと呼ぶようになりました。こうした省略形は、その性質上、何を表しているかをわかりにくくします。そのため、名称変更による改善はあまりありませんでした。

廃止

コンポーネントがサポート外になる可能性が出てきたときは、「コンポーネントは不安定で、変更される可能性があります」というバナーを表示しました。ですが、「不安定」と「変更の可能性」が意味するのは何でしょうか？コンポーネントを使用しない方が良いのか、それとも、使用しても構わないのか、どちらだと思いますか？

ある時あるチームが「テキストインプット」というコンポーネントを使用しました。彼らは、「インプットフィールド」が、デザイナーが「テキストインプット」を置き換えるために作成した新しい部品であることを知りませんでした。そのチームは、新しいコンポーネントに対応する作業のために、何週間も仕事が遅れることになりました。

不明瞭なコンポーネント

私たちには、「ドロップダウン」、「ドロップダウンメニュー」、「セレクト」、「セレクトフィールド」というコンポーネントがありました。これら違いをきちんと把握するのは困難でした。その上、「セレクトフィールド」は「インプットフィールド」のサブコンポーネントでした。コンポーネントについても、名前を付けるのには苦労しました。

デザイナーの巻き込み

Reactを採用し、コンポーネントを単位とする構造に移行したことにより、デザイナーがちょっとした変更を行うことが困難になりました。Reactの学習には時間がかかり、CSSフォルダの構造は複雑で把握しにくいものでした。

CSSのdisplayプロパティの競合

将来への備えの一環として、デザインシステムではFlexbox（display:flex）を使用した新しいグリッドシステムを採用しました。残念なことに、整列用のクラスには、以前のスタイルガイドの名残であるdisplay:inline-blockを引き継いでいました。これら2つを同じコンポーネントで使用すると、お互いが上書きして、レイアウトの問題を引き起こしていました。

公開手順

フロントエンドのプラットフォームチームが週に1度デザインシステムを公開していました。つまり、100人以上の関係者の中でたった3人だけが公開できたということです。その後に、最新バージョンのデザインシステムを会社のメインのリポジトリに反映する必要がありました。新機能の開発のために新しいコンポーネントが利用できるようになるのを待っていたチームの作業には遅れが生じました。

問題の解決に共感を使う

全体的に見て、デザインシステムを実現する過程で、私たちは多くの過ちを犯しました。では、私たちはどのようにこれらの問題を解決しようとしたのでしょうか、そして問題を完全に解決できたのでしょうか?

同僚に対する共感が前進するための手段でした。

コミュニケーションの向上

私たちはフロントエンドの話題を語るミーティングを始めました。そこでは、グリッドシステムと整列用のクラスの問題、カスケードの使い方の問題、今後追加予定のコンポーネントの話題などについて議論することができました。

コード名と略語の使用は中止しました。そして、両方のコードベースを削除しました。

明確なラベル付け

コンポーネントの小さな画像を含む検索ページを作成する計画が立てられました。そうすれば、誰でもデザインシステムを眺めながら検索することができるでしょう。また、コンポーネント名だけでなくキーワードでコードベースを検索する機能も計画されました。

廃止予定のコンポーネントに関しては、UIとテキストを変更して、コンポーネントを使用するべきでない場合が明確に表示されるよう修正しました。

チーム外のメンバーへの対応

React StudioのようなツールがReactの学習を支援するために導入されました。ソフトウェアを使って作成されたデザインに基づいてJSXを自動生成する機能が提供されているツールです。

公開は週に2回行うようになりました。さらに、公開のプロセスを実行するたびに新しいエンジニアを指名する機能をひとりのエンジニアが作成しました。そうすることで、すべてのエンジニアに将来公開に関わる機会が与えられました。

これから始めようとする人に

自分に問いかけてみてください。実際にデザインシステムは必要ですか？そうでない場合は、小さく始めてみましょう。ニーズを先取りしてコンポーネント構築するのはやめましょう。後から新しい機能を利用して実装した場合に、まったく使用できないコンポーネントになってしまうことだってあります。

私たちの場合、デザインシステムのために6人のエンジニアと15人のデザイナーが必要でした。本格的なデザインシステムを計画する前に、投入可能なリソースについて考えてみてください。

そして何より、デザインシステムを構築する際には共感が重要です。誰がそれを使うのか、誰がそこに貢献するのか、あるいは宣伝するのかを考えてみましょう。それはエンジニアでしょうか？それともデザイナー？製品マネージャー？マーケティング？または外部のステークホルダーでしょうか？

以下は、デザインシステム構築についてもっと知りたいときに役に立つリソース（英語）です。

この記事はThe How, and Why, of Creating an Empathetic Design System（著者:Jennifer Wong）の抄訳です