デザイナーがデザインシステムに参加するための課題と対策

実装寄りの情報だけでは不十分

コンテンツだけでなくデザインも運用していきたいと考えたとき、デザインシステムを作ることが不可欠です。属人性を省きつつ、最低限の品質を担保することが可能なデザインシステムですが、作りさえすれば組織で広まるのかというと、そんなことはありません。

Salesforce の Lightning Design System、MailChimp の Design Patterns をはじめ、自社でデザインシステムを取り入れるためのインスピレーションは幾つか見つけることができますが、フロントエンド寄りになりがちです。早く Web サイトやアプリを実装するためのガイドラインなので当然ではあるものの、これだけではデザイナーがデザインシステムへの参加が難しくなる場合があります。多くの要因は「デザイン」と「コード」にある溝と大きく関わっています。

コードが分からないと参加が難しい

デザイナーが作ったものに対してエンジニアがコードに変換してドキュメント化するわけですが、これではデザインシステムと直接的な関わりが持てないので、システムの運用・改善に消極的になる可能性があります。簡易 CMS が導入されていなければ参加の敷居は高くなります。

デザイナーはデザインツールでデザインする

コードにまで落とし込まれた文書があっても、デザイナーから見れば遠い存在です。コードをデザインツールに取り込んでデザインできるわけではありませんし、すべてのデザインをコードから始めるには無理があります。日々使うデザインツールとはまったく別の場所にデザインシステムがあるように見えます。

対外向けのドキュメントとして、実装寄りのルールを明確にするためにデザインシステムは有効です。ただ、それでは実装の都合だけのソリューションとしてデザインシステムがあるということになる場合があります。そこで、デザイナーの仕事環境でデザインシステムを意識させるための働きかけも必要です。彼等がいつも使っている Photoshop や Sketch のようなツールでもデザインシステムのことを考えて作れるようになることで、自分もデザインシステムの実践と改善に参加していると思えるようになります。

デザインツールでシステムを作る

ただ画面をデザインする、部品をひとつひとつ作るのではなく、システムを意識してデザインするようにします。汎用性が高いところはどこか、部品としてどのような組み合わせが最適か考えながら作っていきます。幸い Sketch のシンボル機能はここ半年で劇的に使えるようになったので、汎用性の高い部品を作って管理がしやすくなりました。

例えば、iOS の Tab Bar も以下のような『部品化』ができます。

• タブのアイテム : タップエリアの中央にアイコンとテキストが入る可変のコンテナ
• アイコン : 指定のアイコンに差し替えることができる固定サイズのシンボル
• ラベル : 複数文字が中央配置で表記できるテキストボックス。任意で内容を変えることができる

Tab Bar というひとつの大きなシンボルを作るのではなく、その中に入る要素もシンボルとして部品化することで汎用性を高めることができます。このように部品で分けることで、一貫性を保ったデザインを実装へ手渡すことができますし、日々使うツールで部品管理を続けていれば、デザインシステムもより身近な存在になります。

アートボードの名前の付け方、レイヤーのラベルなど、整理しなければならない部分は多々ありますが、こうしたデザインアセットの部品化も汎用性のあるデザインを作るのに欠かすことができません。シンボルを応用すれば、可変レイアウトのデザインをツール上で考えられるようになります。

まとめ

デザインシステムは実装だけでなく、日々のデザインの現場でも使えるものであるべきです。デザイナーがコードを学べば良いという議論はあるものの、必ずしもそれが正解ではありません。また、コードが書けるデザイナーでも、デザインの模索は使い慣れたデザインツール上でしたいと考える人もいます。実装側に UI を部品化・整理してもらうのではなく、デザイナーも作っている段階からシステムを意識した制作をするべきですし、それが実践できる土壌も整ってきました。

例えば Atlassian では、HTMLベースのスタイルガイドとは別に Sketch と PSD で GUI ライブラリも提供しています。デザインシステムを組織で広めるには、ただ実装寄りの情報を充実させるだけでなく、仕事に携わる人が慣れ親しんでいる環境に合わせた提案も必要です。ツールを使いこなすためのツールを用意するのも、仕事のひとつだと感じる今日この頃です。