Building Design System for Pairs
この記事は「eureka Advent Calendar 2019」15日目の記事です。
14日目はPairs JP Web Teamの竹内による「Pairsのスマートフォン向けWeb版をフルスクラッチリニューアルしました」でした。
こんにちは！Pairs JP Web Teamの新（@ooDEMi）です。主にPairsのWeb版開発を担当していますが、最近はデザインシステム構築の推進もしています。好きなデザインシステムはShopifyのPolarisとAdobeのSpectrumです。
さて、皆さんはデザインシステムというものをご存知でしょうか。
ここ数年で名前をよく聞くようになったデザインシステム。
- いったいデザインシステムとは何なのか
- なぜPairsにデザインシステムが必要なのか
- Pairsのデザインシステムはどのように作られているのか
本記事ではこれらについて語ります。
デザインシステムとは何か
最近は様々な企業が自社のデザインシステムを公開しています。
有名なところですと、GoogleのMaterial Design SystemやSalesforceのLightning Design Systemなどでしょうか。デザインシステム構築を進めている皆さんはこれらを大いに参考にされているかと思います。もちろん私たちも参考にしています。
さて、ここで皆さんに質問です。デザインシステムとはいったい何なのでしょうか？
Material Design Systemを見てみましょう。デザイン原則やコンポーネント集の存在が見て取れますね。Lightning Design Systemにもほぼ同様の要素があることがわかります。
では、デザインシステムとはそれらの要素が揃っているということなのでしょうか？
ここで改めて「デザインシステム」という言葉の意味について考えてみます。「デザイン」と「システム」という2つの言葉に分けることができますね。
「デザイン」が意味するところはわかりやすいと思います。プロダクトのデザインですね。私はもう少し広く「一貫性をもってプロダクトを作ること」と捉えています。
それでは「システム」の意味とは何でしょうか。デザインという言葉に比べるとあまり馴染みのない言葉かもしれません。こういうときはWikipediaを参照してみましょう。
Wikipediaには
相互に影響を及ぼしあう要素から構成される、まとまりや仕組みの全体。
と書かれています。
これら「デザイン」と「システム」という言葉の意味を組み合わせて考えると「デザインシステム」という言葉が持つ意味は「一貫性をもってプロダクトを作るための様々な要素から構成される仕組みの全体」と捉えることができます。
デザインシステムをこの意味で捉えた時、デザイン原則やコンポーネント集は「一貫性をもってプロダクトを作るための様々な要素」の中のひとつでしかないということがわかります。
これらの要素が組み合わさって運用され、一貫性をもってプロダクトを作ることに活かされている状態こそがデザインシステムであると言えるでしょう。
したがって、デザイン原則やコンポーネント集などの個々の要素を指してデザインシステムであるという話ではないわけですね。
仕組み全体として成立していることが重要であると考えられます。
なぜPairsにデザインシステムが必要なのか
デザインシステムとは何なのかということがわかりました。
それでは、なぜPairsというプロダクトにデザインシステムが必要なのかという話をします。
Pairsにデザインシステムが必要な理由は以下の2つです。
プラットフォーム間の差異解消のため
Pairsは7年以上運用され続けているプロダクトです。
提供しているプラットフォームはiOS、Android、ブラウザ（PC・モバイル）と多岐にわたります。
これらの状況が「プラットフォーム間でUIに細かな差異が出てしまい、なかなか解消できない」という問題を引き起こしています。
例えばiOS版とブラウザ版で微妙にリストのデザインが異なる。使用されている色が異なるというような問題です。
このような問題はデザイン・開発効率の低下やコミュニケーションコストの増加をもたらします。
お客様に価値を最速で届けるため
デーティング市場の成長率は著しいです。その中でPairsには市場の成長率と同等以上の成長速度が求められます。
そしてPairsの成長速度を支えるものはプロダクトのデザインと開発の効率向上に他なりません。
お客様にとって価値のある機能を最速で提供するためにも、素早くデザイン・検証・開発のサイクルを回すことが求められます。
私たちはこれらの状況をより良くするためにデザインシステムの構築を進めています。
デザインシステムを構成する要素は何か
デザインシステムとは何か、なぜPairsにデザインシステムが必要かということがわかったところで、具体的にデザインシステムを構築する話をしましょう。
デザインシステムとは「一貫性をもってプロダクトを作るための様々な要素から構成される仕組みの全体」だと話しました。
では、その「様々な要素」とはいったい何でしょうか。
デザインシステムとは仕組み全体だ！と言いつつも、実際にそれを成立させるためには当然ながら、個々の要素を作り上げていく必要があります。
まずはデザインシステムを構成する要素を知るところから始めましょう。
これは世の中に公開されている様々なデザインシステムを分析することで見えてきますが、今回はそれらを一枚の図にまとめてくださっている「Anatomy of a Design System」の記事から図をお借りしたいと思います。
冒頭でも言及したデザイン原則（Design Principles）やコンポーネント集（Components）の他にDocumentationやProcesses、Voice & Toneなど様々な要素が見て取れます。
ここで注意すべきは「これら全ての要素が揃っているということがデザインシステムである」ではないということです。
たとえデザイン原則だけしか、もしくはコンポーネント集だけしか存在していなくても、それが一貫性をもってプロダクトをつくることに役立っているのであれば、それはデザインシステムと呼べるでしょう。
逆に、ここに書かれている全ての要素が存在していたとしても、それが一貫性をもってプロダクトを作ることに役立っていなければ、それはデザインシステムとは呼べず、単なるお飾りでしかないでしょう。
実際のところ、これらの各要素を作り上げることよりも、それをプロダクトに適用し運用していくことのほうが遥かに難しいと感じます。
何から作るべきなのか
デザインシステムを構成する要素がわかりました。次に、何から作っていくべきなのかということを考えなければなりません。
これに関しては組織やプロダクトがおかれている状況に大きく依存するかと思います。
例えば、エンジニアやデザイナーの入れ替わりが激しく、プロダクト内にどのようなUIが存在するのかわからない人が多いというような問題が発生しているなら、コンポーネント集やそれらをまとめたドキュメントから作ることが効果的でしょう。
例えば、人員の入れ替わりは発生せず全員が存在しているUIを熟知しているが、デザインのアウトプットに統一感がないというような問題があるようなら、コンポーネント集を作ることよりもデザイン原則から考えていくことのほうが効果的かも知れません。
デザインシステムの構築を始める時、安易に他社の事例を真似すると、実は自社には不要だった要素を作り上げてしまう恐れがあります。「とりあえずStorybookでコンポーネント集を作ってみたけど上手く回っていない」などはその典型例かもしれません。
世の中に公開されているデザインシステムは、公開されているだけあってあらゆる要素が揃っています。デザインシステムの構築を始める時、それらと同様に全ての要素を作ろうとしがちですが、実際は自分たちに必要な要素から始めていけばいいのです。
このように小さく始めるデザインシステムのことをDesign System LiteやMinimum Viable Design Systemと呼んでいる方々もいらっしゃいます。
Pairsではどこから始めたか
Pairsでは、前述したプラットフォーム間の差異解消やデザイン・開発効率化のために、以下の要素に注力するところから始めました。
- Styles
- Components
- Documentation
Styles
主にColor・Typography・Iconの統一から始めました。
いきなり見た目に関する全ての要素を統一しようとすることは非常に困難なため、ColorやTypographyなど比較的整理しやすく、それでいて統一による効果が高いものから始めると良いでしょう。
SketchのLibrary機能を活用して全員が同じStylesを使用してデザインできる状態にし、それらと一対一で対応するCSS Variableを定義することでスムーズに開発まで落とし込めるようになりました。
Components
Stylesの統一と並行してコンポーネントの整理・統一も始めました。
Atomic Designの分類手法をベースにPairsのUIを分類し、AtomからMoleculesまでのコンポーネントを分類・命名しました。
（Atomic Designによる分類と命名については過去の登壇資料でも言及していますのでもしご興味があれば読んでみてください）
ComponentsもStylesと同様にSketchのSymbolとそれに対応するReactコンポーネントを実装することで、デザインから開発までのスピードを向上させることができています。
Documentation
StylesとComponentsを作り上げたとしても、その存在をデザイナーとエンジニアに知られなければ意味がありません。
私たちはデザイナーやエンジニアが更新しやすく、SketchやStorybookなどの各種ツールとの連携も充実しているZeroheightという管理ツールを利用してドキュメントを構築しています。
これに関しては弊社Design Teamの西宮が記事を書いていますので、そちらを読んでいただければと思います。
先程のデザインシステムを構成する要素の図に照らし合わせると、いまのPairsのデザインシステムは以下のような状態です。
ComponentsやDocumentationは徐々に拡大していますが、まだ発展途上です。そして、目下一番の問題として考えているのがProcessesです。
実際に作り上げた要素をプロダクトに適用していくことが遥かに難しいとお話しましたが、まさに私たちもこの問題に直面しています。
有志で「デザインシステム委員会」としてデザイナーと各プラットフォームのエンジニアから1名ほど参画しデザインシステム構築の活動を進めている状態ですが、プロダクトの適用までに時間がかかってしまっているのが現状です。
Pairsのデザインシステムのこれから
このような現状にあるPairsのデザインシステムですが、直近の目標としては以下に焦点を当てて改善していきたいと考えています。
- Components
- Documentation
- Processes
Components
全てのデザインや実装に対して整理したコンポーネントを適用できているわけではありません。コンポーネントのカバレッジを高めていき、プラットフォーム間での差異が残っているものをなくしていくことに注力していきたいと考えています。
Documentation
Zeroheightという管理ツールを利用したり、各プラットフォームでStorybookのようなコンポーネントカタログの作成もしていますが、それらが完全に同期されているわけではありません。依然として更新にかかる労力は高いため、それらを効率化・自動化する改善に取り組む必要があると考えています。更新が簡単でなければ誰もドキュメントを更新しようとは思いません。
Processes
現状、デザインシステム委員会に参画しているメンバー以外でデザインシステムについて把握している人はとても少ない状態です。デザイナーはもちろんのこと、各プラットフォームのエンジニア、さらにはプロダクトマネージャーなども含めデザインシステムに関与してもらうことで、よりデザインシステムの効果を発揮できるようにしたいと考えています。
どんなデザインシステムを作りますか？
デザインシステムとは何なのか、なぜPairsにデザインシステムが必要なのか、Pairsのデザインシステムはこれからどうなっていくのかを一通りお話しました。
デザインシステムとは「一貫性をもってプロダクトを作るための様々な要素から構成される仕組みの全体」であると私は考えています。
そこに決まりきった正解はなく、自分たちの所属する組織・プロダクトのあり方によって多種多様な形を取るものでしょう。
本記事が、いまデザインシステムを構築している皆さん、これからデザインシステムを構築しようとしている皆さんの参考になれば幸いです。
皆さんはどんなデザインシステムを作りますか？
