デザインシステムのプロジェクトの実践で学んだ3つの大切なノウハウ
この記事は、2019年3月8日にクラウドワークスデザイナーブログで執筆した記事です。
こんにちは。クラウドワークスのデザインシステムのデザインを担当している小林です。
昨年末の 「CrowdWorks Advent Calender 2018」3日目の記事で、これまでのクラウドワークスのデザインシステムを作ってきた過程での失敗を書かせていただきました。
この記事を書くにあたり、これまでのプロセスや今の問題点を振り返ることができました。また、この記事を書いたときは、デザイナーだけで作っていたシステムにエンジニアが加わり、チームとして新しい一歩を踏み出しはじめた時期でした。そして、エンジニアが加わり強化されたチームで、年明けからデザインシステムの構築を加速するべくいくつかの取り組みをはじめました。
今回は、実際に作成しているデザインガイドラインも一部公開しながら、加速し始めるエンジンになった取り組みやノウハウを紹介できればと思います。
私たちの失敗。
アドベントカレンダーの記事を読んでいただければ、失敗について詳しく書いてありますが、このときの1番の失敗は、メンバー間のコラボレーションがうまくできず、それぞれの頭の中がちぐはぐになっていることでした。
毎日一緒に仕事をするメンバーといえども、頭の中までは覗き見ることはできませんよね。自分の頭の中でさえ無意識では見えていない部分があって、同じ理解をしているつもりになってしまっていることも少なくないと思います。
プロジェクトを加速するためには、ちぐはぐな頭の中をぴったり揃えてあげる必要がありました。
学び1. デザインシステムは生き物。少しずつ育てて行こう。
デザインシステムを作るなら、あらゆるパターンに対応した、より完璧なものを作りたいと思うものです。でも、デザインシステムに完璧なんてないことに気づきました。
プロダクトや組織の成長や変化とともに、デザインシステムも変化し続けます。デザインシステムは生き物なのです。
だから、最初から全てを作ろうとしていたものを、まずは対応できる画面を限定し、その画面を正しく作り上げられるために必要なコンポーネントのみを定義すること集中しました。今やらなければいけないことの優先度が明らかになり、チーム全員が方向を向き、一気に集中してデザイン・実装ができたため、停滞期に感じるモヤモヤは少しずつ晴れ、私たちは加速し始めました。
学び2. 明日記憶が無くなってもいいくらいに、デザインルールは徹底的に見える化しよう。
今まではデザインデータ上に記載していなかった、アンチパターンや細かなスペックなどを含む、以下の項目たちを徹底的にデザインルールとして見える化しました。
・そのコンポーネントのもつ役割
・コンポーネントの原則（推奨する使い方と推奨しない使い方）
・コンポーネントの細かなスペック（余白やフォントサイズ、カラー等）
・ブレークポイントごとのレイアウトや変形のルール
・コンポーネントの種類とパターンごとの役割
一つひとつのコンポーネントに対して、細かく正しい使い方を定義するのではなく、最低限守りたいアンチパターンを定義しています。実際にプロダクト内でどのように使われるか、各デザイナーの裁量とデザインシステムが良いバランスを取れるように模索中です。
サイズで定義しているような細かい数値は、zeplinでも確認できます。しかし、このように明らかに言語化することで、何が決まっていて何が決まっていないかが一目でわかります。
可視化していないと、優しいエンジニアさんたちは「デザイナーってこう思って作ったんだろうな」と気持ちや考えを汲んで実装してくれることが多いです。しかし、そもそもデザイナーが考えられていなかったり、デザイナーの意図と違う解釈をしてしまい、最終的に意思疎通できないアンハッピーな状況になることもあるので、私たちは定義したいことは言葉や図で見えるようにしました。
頭の中に埋もれていたデザインルールやデザイナーに見えていることを、デザインシステムをデザインしていないデザイナーやエンジニアにも見えるようにしました。これで、明日私の記憶がなくなっても安心ですね。
デザインルールが見える化されると、今まで気づかなかった仕様の考慮ミスや認識違い、対応できていなかったWEBアクセシビリティ対応など、デザイン仕様が次々とアップデートされています。
学び3. いろんな概念の細かなところまで認識を共有しあえる機会を作ろう。
私たちのチームは、デザインシステムについて考えてきた時間も、それぞれが持つ知識のバックグラウンドも異なります。同じものを見ていても、違う見え方をしているかもしれません。
そこで、デザインとエンジニアの両方の視点を持っていたUXエンジニアが中心となり、「赤本を読む会」「アトミックデザインを考える会」を開催しました。
デザインシステムの本を読む会
今までも「デザインシステム」をキーワードに様々な議論をしてきました。でも、それぞれが考える「デザインシステム」が違ったので、ピタッとはまらず、幾度となく同じ議論が繰り返されることがありました。しかし、本を介在しながら、それぞれが持つデザインシステムという概念の違いや大切にしたいことなどが浮き彫りになりました。
また、この本は私たちが知らないこともたくさん教えてくれます。新しい発見に出会うと、そこから議論が広がり、「私たちがどんなデザインシステムを作っていきたいのか」をたくさんの視点から考えさせくれます。
アトミックデザインを考える会
この会では、紙に印刷したクラウドワークスの画面を、アトミックデザインで定義するコンポーネントのレベル（atom/molecules/organisms）にハサミで切り分けるワークショップです。
満場一致で切り分け方が同じになることは少なく、多くの場面でコンポーネントの分解の仕方に議論が必要でした。議論の過程では、化学式に例えて考えてみたり、人の体に例えてみたり、実装した時の汎用性から考えてみたり、私たちが持っている知識全開で意見を出し合いました。
最終的には、私たちなりのアトミックデザインの分解の定義を決めました。この定義ができた以上に、チームのコミュニケーション量が増え、不安がらずに意見をぶつけられる環境の土台ができたこともこのワークショップのおかげだと思っています。
このワークショップやアトミックデザインについては、UXエンジニアの林（@earlgrayML）が登壇したときの資料もあるので、ぜひこちらも見てください。
さいごに
デザインシステムのプロジェクトでは、日々、大小さまざまな壁にぶつかりながら、チームで壁を壊していかなければいけません。ここで一番大切なことは、メンバーが同じ方向を向いて、見えないことをどうやって共有していくことができるかだと思います。みなさんも一人ではなく、チームでデザインシステム作りに向き合ってみるとうまく進むかもしれません。
この記事が気に入ったらサポートをしてみませんか？