見出し画像

みんなに知ってもらいたいデザインシステムのこと

この記事はクラウドワークス Advent Calendar 2019 の15日目になります。

みなさんこんにちは。2019年の10月よりクラウドワークスで働いております@yamanokuです。
普段は勉強会やカンファレンスに行ったり、インターネットを徘徊したり、飲酒をしたり、一児の父をやっていってます。現在はフロントエンドエンジニアとしてデザインシステムを作るチームにジョインしています。

今回はそのデザインシステムについて、どういったときに必要となるのか、エンジニア・デザイナーが知っておくべきこと、みんなに知っておいてほしいこと、をそれぞれ紹介したいと思います。

デザインシステムについて

「デザインシステム」。フロントエンドのみならずWebに従事する人であればここ最近で耳にすることがあるワードかと思います。今一度認識を揃えるためここでは何なのかという解説をします。

デザインシステムの定義については以下記事より引用します。

デザインシステムは、個人、チーム、またはコミュニティによってコードおよびデザインツールとしてドキュメント化されていて、スタイル・コンポーネント・その他の懸念事項のライブラリが用意されているため、製品をより効率的かつ統一的に導入できます。
A design system offers a library of visual style, components, and other concerns documented and released by an individual, team or community as code and design tools so that adopting products can be more efficient and cohesive.

「ドキュメント化」と「ライブラリ」いうと、UIの色や形に関するルールが載っているスタイルガイドであったり、コンポーネントが様々展開できるようにするパターンライブラリのそれにあたると思われるかも知れません。

ですがデザインシステムでは、スタイルガイドやパターンライブラリでは実現できなかった「プロダクトを拡張できること」が差異としてあげられます。

スタイルガイドやパターンライブラリは、一覧性を重視したガイドの機能しかなく、それらを作りきることに完結してしまい、プロダクトの成長に追随することまで考慮されているものではありませんでした。

デザインシステムがスタイルガイドとパターンライブラリの機能を内包している図

デザインシステムにおいては、それらを包括した上で、デザイン原則、情報設計、基盤、アクセシビリティ、についても定義されています。これらはガイドやライブラリだけでは分からない、それによって何が実現できるのか何を解決しうるものなのか、といったプロダクトのアイデンティティをも体現してくれます。
原理・原則についてもドキュメント化されるので、プロダクトで新たな機能をつくったり、改修を行うにあたり「何を基準にしていけば行えばよいか」がより分かりやすくなります。

プロダクトのアイデンティティを示すものとしてUIコンポーネント以外にも、今年発表されたAdobeのデザインシステムであるSpectrumでは「Voice and Tone」、「Grammar and mechanics」といった言葉やライティングにおけるスタイルガイドラインも制定されているなど、より広義でのデザインについてもシステム化されています。

SpectrumのVoice and toneページ

https://spectrum.adobe.com/page/voice-and-tone/
https://spectrum.adobe.com/page/grammar-and-mechanics/

更に2017年にはアメリカ合衆国が国のデザインシステムを発表し、国単位での一貫性のあるウェブサイトを作る取り組みが行われています。

United States Web Design Systemサイトのスクリーンショット

また、日本でもさまざまな企業が活用事例をあげるようになってきています。以下はその事例になります。

ちなみに今年の3月よりdesignsystems.tokyoという、事業会社にてデザインシステムに取り組む有志にて、どのように導入していくか検討したり議論するコミュニティが発足して、クラウドワークスもこちらに所属し、各勉強会に参加させていただいております。

デザインシステムはいつ必要とされるのか

次にそんなデザインシステムについて、いつ必要となってくるものなのかについてを紹介します。

こう言ってしまうと元も子もありませんが、それを構築する必要性を感じなければ(コミュニケーションなどで解決できるなど)無理にやる必要はありません。デザインシステムに限らず、なんとなく始まってしまうものほど怖いものはありません。

ですが高度な要件定義を求められたり、その中で高速にリリースしていく必要がでてきたとしたら、デザインシステムなしでそれらに立ち向かうのは困難なようにも思えます。なぜなら、デザイナーとエンジニアの協業をより潤滑にしたり、サービスが拡大してもその品質を一定維持した開発ができるようになるからです。

事業利益に貢献するデザインとユーザー満足度に貢献するデザインを各々評価する
(中略)
当然ですが、どれだけユーザー満足度が高くても事業利益が上がらなければ、サービスは潰れます。逆にどれだけ短期の事業利益が上がっていてもユーザーが満足していないサービスはいづれユーザーが離れていくので、やはりサービスは潰れます。
この両者を高い品質で成立させるようにデザインすることは難しいですが、サービスが大きく成長しながら長く生き残るためには必須です。

新規事業をはじめるにあたり、1から新しく作るUIが適正に評価できるかはわかりません。ですが、デザインシステムでは一貫した体験を提供できるコンポーネント開発がされています。
それらを的確に組み合わせることで、小規模のチームであったとしても、品質を維持できた状態で効率的にプロダクト開発ができるとされています。

更にコンポーネントの混在化を防ぎ統一性をもたせるため、車輪の再開発といわれる無駄な工程を削減することができます。

もしあなたの企業に25のチームが存在していて、 それぞれのチームがボタンを作っている場合、 優れたボタンを作るのに100万ドルかかります。
ー ネイサン・カーティス

以前こうしたコンポーネントの機能面とビジュアル面の関係性を確立するための100万ドル案件と呼ばれていた会議が弊社でおこなわれていたようです。

以上を踏まえた上で次は、エンジニアとデザイナーの視点から考慮していく必要があることについてを紹介します。

エンジニアに知ってもらいたいこと

デザイナーとの間でコミュニケーションが必要なものは、言葉における「状態の表現」だと思っています。

ボタン(button)というコンポーネントを例にとって考えてみます。
通常のとき、フォーカスされたとき、アクティブになっているとき、操作不能になったとき、とボタン1つにしても状態が色々と存在します。

ボタンの操作状態について。通常、フォーカス、アクティブ、利用不能の図

またボタン自体がリンク(aタグ)であるときはその状態とはまた違った定義をしないといけません(disabledは使えない等)。

これらは実装者であればイメージしやすいかもしれませんが、そのコンポーネントがもてる状態についてを明記していないと、デザインする際に漏れが発生しかねませんので、明文化していく必要があります。

また、デザインシステムにはDesign Tokensというものがあります。これは定義されたトークンを使うことでそれらの値を一括で置き換えることができるものです。
デザインシステムが担保しうる機能としてSingle source of truth(信頼できる唯一の情報源)というものがあり、それに当たるものです。
使い方としてはCSS Custom PropertiesやSassにおける変数のようなものとイメージしてもらえれば良いと思います。

$brand-primary: rgb(21, 137, 238);
$brand-primary-active: rgb(0, 122, 221);
$brand-primary-transparent: rgba(21, 137, 238, 0.1);

トークンを定義する際も、その言葉自体が「どういった状態を示すのか」「どこまで責務をもつものか」を、デザインシステムを作る際に考慮しておくべきでしょう。
言葉の定義で混乱を招いてしまうことは、今後の設計が破綻してしまうのを招きかねません。

デザイナーに知ってもらいたいこと

デザイナーは視覚表現を担当領域とすることが多いのですが、作った人以外が「それが何故そういう表現をしているのか」を理解できるようにする必要があります。

Shopifyのデザインシステム「Polaris」の例をあげると、国際化対応において各国の文化の違いを汲み取る、というのがあります。

ShopifyのデザインシステムPolarisでの国際化対応における正しいUIと間違っているUIを説明する図

日本であればCountryにつづいてPrefecture(都道府県)の入力項目を追加してあげたり、名前入力を北米式のような姓名入力フォームで設置しないようにするといった例を上げています。こうした例を示すことで、何故そうしたデザインになっているかの理解に大いに役立ちます。

デザインにおいては使用するツールについても厳選していかなければなりません。
Sketch、Figma、Invision、Storybookなどデザイナーが他業種と協業していくために様々なツールがあります。しかし「これを使うと出来る」といった明確な正解はありません。それよりもそのツールたちがどういった世界を実現しようとしているかという思想をもとに使っていくほうが良いと思っています。

その中でもFigmaがデザインシステムを構築する際で利便性を感じられるのは、横断的に連携して使えるだけではなく、アナリティクスでデータを可視化をしてくれたり、オンボーディングなど使う際のデザインデータを制限するなど、より実践的に使える点だと思っています。

協業に関して、Sketchでも同時編集機能が搭載される発表がありました。今後はツールのアップデート動向をチェックしてみるのと良いでしょう。

すべての人に知ってもらいたいこと

最後は、より包括的に、役職を限定しないデザインシステムにまつわるすべての人に知ってもらいたいことになります。

1つのプロダクトしてデザインシステムを作っていくにあたり、完成というものはあるのか?という問いが出てくるかも知れません。それに対しての答えは「NO」になります。

先述したようにデザインシステムは拡張していく・誰もが維持された品質でデザインできることを前提としています。
そのため0か1かといった明確な答えがないことを前提に、拡張できることに耐えうるための運用をしていくことが必要となります。

デザインシステムは生き物。少しずつ育てて行こう。
デザインシステムを作るなら、あらゆるパターンに対応した、より完璧なものを作りたいと思うものです。でも、デザインシステムに完璧なんてないことに気づきました。
プロダクトや組織の成長や変化とともに、デザインシステムも変化し続けます。デザインシステムは生き物なのです。

デザインシステムも1つのプロダクトであるゆえ、失敗することもあります。
失敗について解説した記事では、組織的支援やコミュニケーションの不足や初期投資できていないこと、そもそも使ってもらえない等の例を上げています。
2017年に書かれた記事とはいえ、今でも十分に通じる内容となっています。

持続性と発展が不可欠であり、それを欠くことは失敗ないしデザインの悪循環を招きかねません。しっかりとした受け入れ体制をもっておこなうことが望まれます。

デザインシステムが間違った方向のまま進んでしまうと、結果として悪いものを生んでしまいかねません。デザインによっては人を傷つけたり、ある層を排除することもできてしまうので、自分たちのプロダクトは何を目的としているのか?どういう未来を描こうとしているのか?といった視点を持つことも忘れてはいけません。

おわりに

以上、デザインシステムについて知ってもらいたいことの紹介でした。

デザインシステムを用いることで、一定の品質を維持しながら柔軟にクリエイティブを発揮できるようになれるのですが、実施するにあたり明確な目的意識や何をしてはならないかを理解しないまま進めると、正しくないデザインが広まってしまう恐れがあります。

去年から発足されたフロントエンドチームでは、クラウドワークスでのデザインシステムのあり方についても、試行錯誤しながら、ひとつずつ整えていっている段階です。
今はまだ内部に閉じているのですが、いずれ皆さんにお披露目できればいいなと思っております。

* * *

ここまでご覧いただき、ありがとうございました。
明日(12/16)の担当はクラウドワークスのアクセシビリティやっていき隊長、みーた氏です。

English Version

参考

「Atomic Design & Design Systems」をお話させて頂きました
* デザインシステムの資料を作る時に参考にしたリンク集
* デザインシステムとは?

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

25
一児の父です。https://yamanoku.net

この記事が入っているマガジン

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。