LOADING

Abstractを使ってフレキシブルな「デザインシステム」を組織に導入する

2017-08-20 | DESIGN

デザインシステムとは

紙などのデザインと比べて、ソフトウェア開発は制約が極めて少ないが故にプロダクトの統一感を保つのが難しいと言われています。その為カラーやマージンのパターンといった様々な制約を設けるわけですが、これらの制約をサービス開発に携わる全ての開発者が理解できる共通言語として言語化したものがデザインシステムです。

AirbnbのDesiginSystem

そんなデザインシステムですが、時間とお金に余裕がある企業だけが単に見栄と社内の余剰な労働力の消化のためだけに存在していると思っていませんか?僕は思っていました。今日はひどい誤解をしていたデザインシステムへの謝罪の意も込めて、5人弱の開発組織にデザインシステムを導入したときの話と、導入方法について書きます。

具体的には今回、アプリ開発を行うチームなら共通して抱えている事が多い以下2点の問題を解決することを目的としています。

  • 色が無限に増えてしまう問題
  • コンポーネントが一元管理されていない問題

色が無限に増えてしまう問題

色が増えてしまう問題とは

デザインしたスクリーンをどのような方法でエンジニアに共有しているでしょうか?Zeplinなどの外部サービスや、marketchなどのsketchプラグインを使っている人がほとんどだと思います。その際に意図しない色が混入してしまい、その色がプログラム上のカラーパレッドにゴミとして蓄積されてしまう問題こそがこの’色が無限に増えてしまう問題’です。

これは極端な例ですが、デザイナーの認識では一色しか無いはずのIndigoカラーが、スペックを書き出す際のミスで、気がついたらプログラム上では7色になっていた、なんてことも起こりえます。四六時中エンジニアとデザイナーが密にコミュニケーションが取りずらい環境ではなおさら、このような不幸な事故が起こる傾向は高いです。

色が増えていくことによる弊害

このように色が際限なく増加してしまったことによる弊害は多々ありますが、なによりも深刻なのは、「改修しずらい」ことではないでしょうか。メインカラーをindigoからDeep Purpleに変更する、ただこれだけのことをするために、エンジニアは多大な労力と、ヒューマンエラーとの戦いを強いられます。

解決にあたって

この「色が増えてしまう問題」を解決するにあたって、以下3点のアプローチを採用しました。

1.Sketchでのスポイト禁止 – 全色Symbol化する

Sketchでの超便利機能といえばスポイトですね。ブラウザなどのアプリケーション外からもカンタンに色を取ってこれるスケッチの便利機能ですが、こちらを封印しました。

プロダクトで使用する全ての色をシンボル化し、デザインを作成する時はシンボルからしか色を選択できないという制約を設けます。

2.カラーパレッドをZeplinにアップロード

作成したSymbolを使ってカラーパレッドを作ります。

この時にポイントなのが、HexやRGBAコードを記述しないというところです。コピペの際のミスを防ぐとともに、アップデートに伴う変更に強いカラーパレッドにするため、単純にカラーのシンボルと開発者間のコミュニケーションの際に使用する名前を付けます。色はZeplin上に表示されるので、そこからプログラムに反映してもらいましょう。

例としてこの色には、Main700という名前を付けました。エンジニアに色の指示をだす場合、こちらの色名を用います。

3.Abstractの導入

Abstractはデザインファイルをプログラムで言うところのgitの用に管理することができるバージョン管理ツールです。 Abstractの概要や詳しい使い方などは、Standard,inc.吉竹さんがすごくわかりやすくまとめておられるので、こちらの記事を見て勉強すると良いと思います。

デザインデータのバージョン管理ができるAbstractを試してみた✌ | UXデザイン会社Standardのブログ

先程のカラーパレッドに変更が生じた場合、abstractの出番です。

このようにabstractにはsketchのartboard単位でコメントができる機能が備わっています。変更点をこのannotation機能を使って強調し、コメントに内包すれば変更点が一目瞭然です。変更後のカラーコードを確認してもらえるようにZeplinのリンクを貼り、さらにこちらのレイヤーへのリンクをissueにまとめるなりslackで送るなりすれば万事完了です。追加、削除の場合も同様の手順で行います。

コンポーネントが一元で管理されてない問題

コンポーネントが一元で管理されてない問題とは

例えばこのように単純なアイコン+テキスト1行のセルがありあます。アプリの色々なところで使われているこのコンポーネントですが、多くのチームでコード上このコンポーネントを、異なるスクリーンでは異なるUIパーツとして管理してしまっていることがわかりました

当然デザイナーとしては1つのコンポーネントとして認識していることでしょう。ただこれらのスクリーンを別々にスペックだけ書き込んでエンジニアに渡すことでその意図を汲み取ってもらうのはかなり難しい。結果として、コンポーネントが無限に増えていき、もはや”コンポーネント”として機能しなくなってしまいます。

一元で管理されてないことによる弊害

やはり色と同様改修が大変というのが一番の問題です。「セクションタイトルのスタイルを流行りの今っぽい感じにアップデートしよう」といった軽いアップデートが、エンジニアにとってとてつもなく骨が折れる作業になりかねません。

解決にあたって

カラーパレッドを作成したように、コンポーネント専用のガイドを作成します。ガイド内では基本的にスタイルガイドで命名した色名を使って色を指定したり、マージンの取り方など単にスペックを書き出しただけは汲み取ってもらえなそうな部分のみを記述し、Zeplinにアップロードします。

直接書き込んでいる情報を優先しつつ、足りない情報はZeplinで保管しながら開発を進めてもらいます。ここではcellのみを例として出していますが、ボタン、ナビゲーションバー、タブ、トグルスイッチなどなど、基本的にはアプリ内で使う全てのコンポーネントをこのガイドラインにまとめていきます。

肝心のスクリーンスペックはabstract上に書き込みます。その際にやることは、component名のみを簡潔にメモするだけです。card/003というコンポーネントはすでに、コンポーネントガイドラインに仕様がまとめられているため、あとはそのスタイルをこのスクリーンで採用する旨だけ伝えれば良いのです。こうしてエンジニアとデザイナー感でコンポーネントに関しては齟齬のないプロジェクトの完成です。

デザインシステムの導入のメリット・デメリット

今回はこのように、色やコンポーネントなどのUIパーツといったものに共通言語を割り当て、よりシステマチックな開発を実現しました。確かに従来のZeplin放り投げ方式から、このAbstract併用型のトラックに切り替えるにはそこそこの工数がかかります。しかしその程度の作業時間は、改善改修に要する開発側の時間短縮と開発メンバー間でのコミュニケーションコストの大きな減少によって瞬時に相殺できてしまいます。

また、コンポーネント化をしっかりと行うことで、デザインがcreateするものから、UIの選択へと切り替わり、これまでとは比べ物にならないほどのスピードでアップデートを行うことが可能になります。

少々回りくどいことをしているように見えるかもしれませんが、リモートワーカーやフルタイム以外のメンバーが少なからずいるチームでは、デザインシステムはかなりの効果を発揮するはずです。全員フルタイムというチーム構成が実現しにくい創業間もないスタートアップこそ、デザインシステムの導入を検討してみてください。

読んでもよくわからなかった方は僕を雇うと良いと思います!!

共有よろしくおねがいします!