デザインドキュメンテーションにある制作と共有の課題

ドキュメンテーションのための３つの課題

Web サイトデザインはもちろん、アプリデザインでも画面ではなく部品から始めるほうが有効です。画面ごとで制作していくと、いつの間にか一貫性を失うことがありますし、様々なスクリーンサイズに対応するためのルールを後付けにすると、結局またやり直しになってしまうこともあります。

では、インターフェイスを一度見直してスタイルガイド（パターンライブラリ）を作り始めれば良いのかというと、それほど単純は話ではありません。私の中で以下の 3 つの課題があると考えています。

• 人とコトの課題 – これはワークショップを通して指摘しましたが、ステークホルダーによって優先順位が違えば、指している要素の呼び名が違うことがあります。制作側視点だけで作ると思わぬ誤解が発生する可能性があります。
• 共有の課題 – 様々な企業が自社フレームワークを Web で公開しているのを見ても分かる通り、最近は多くの人が見れる場に公開する傾向にあります。GitHub などのサービスを介して公開するのも手段ですが、運用しやすく、参加者が最新情報へアクセスできるようになっているかが選定の基準になります。
• デザインとコードの課題 – 特に Web サイトデザインに言えることですが、スタイルガイドと言うとフロントエンド寄りのソリューションになりがちです。見た目とコードに一貫性を持たせるという意味では必須ですが、ビジュアルデザイナーもスタイルガイド制作に参加しやすい仕組みも必要です。

一長一短なアプローチの数々

案件によって関わり方やアウトプットの要件が異なることから、上記の課題をそれぞれ模索しながら進めている状態ですが、特に課題に感じているのがデザインとコードの記録をどのようにしていくかという部分。Sketch や Photoshop でシンボルやレイヤー名できちんと整理すれば、デザイン側である程度ルールを組み立てることができますし、Folio のようなアプリを使って、Git 上でバージョン管理ができれば、開発者もデザインアセットにアクセスしやすくなります。

こうした話になると、デザイナーもコードを書けば良い議論が発生するわけですが、必ずしもそれが正しいアプローチではない場合があります。現場によってはフロントエンドのコードは専門家にきちんと書いて記録を残してもらったほうが良いです。しかし、だからといってデザイナーがスタイルガイドをフロントエンドの方に『納品』するという一方通行のワークフローでも不十分です。実装した後に気付いた課題をデザイナーにまた考えてもらうときに、どのようなやりとりが適切なのか。そして、その間を埋めるためのツールは何なのかの選定が難しいです。

また、スタイルガイドを作ったデザイナー以外でも、ある程度デザインができる状態を作っておく必要がありますし、それがコードを書かないデザイナーでもある一定の水準のものが作れるようになるのが理想的です。となると、すべてコードで管理で済むのかといえば、そうでもなかったりします。コードとしてドキュメントを作るのは当然ですが、ビジュアル言語としての記録は別途必要なことがあります。

Photoshop と Sketch との連携ができる Zeplin。
Sympli だと Xcode や Android Studio 用のプラグインもあります。

例えば Zeplin や、Simpli はデザインとコードの間を埋める良いツールです。デザイナーは、いつものように Sketch を使っているだけで、自動的にデザインスペックが記録されます。カラーパレットや寸法が手軽に見れるようになるので便利ですが、ドキュメンテーションという意味では少し物足りないものがあります。それぞれのデザイン要素にはどういうルールがあって、どういう経緯で実装されているのかまでは書き込むことができません。

記録という意味では、GitHub の Wiki や Confluence は共同作業や更新履歴が取れるので魅力です。ただ、これをどうコードにするかまでのルールの記載、コードが書かれているファイルへのリファレンス、コードによってどうレンダリングされるのかといったプレビューは見れません。これらの課題を埋めるためにドキュメンテーションの運用負荷がかかる可能性があるのを懸念しています。

老舗静的ページジェネレーターですが、カスタムフィールドを作ったりテンプレートを拡張できるなど柔軟性は高いです。

昨年から、Jekyll を使ってドキュメンテーションをするケースも出てきています。静的ページジェネレーターは他にもたくさんありますが、開発が非常に長く続いていて安定しているのが選んでいる理由です（最近はどれも Markdown で書けるので、書き出しの心配はないのですが）。また、jekyll-styleguide のようにスタイルガイドに特化したテーマも用意されているので、比較的早くドキュメンテーションの枠組みを作ることができます。これで、デザインとコードの壁は埋まらないですが、Markdown なのでルールや経緯をデザイナー自ら書きやすいと思います。

コードとデザイナーの間ではなく、デザイナーとデザイナーの間を埋めるための方法として最近始めているのが、Sketch と Craft の組み合わせです。Craft は、ダミーデータの入力、要素の細かな配置や複製、インタラクション追加など、Sketch にはない機能を埋めてくれるプラグイン。inVision が開発しているものですが、サービスを利用しなくてもプラグインを使うことができます。

ボタンやフォーム要素など、カテゴリを作って管理することもできます。

この Craft のなかにある Library がよく出来ていて、カラーパレットだけでなく、ボタンやアイコンなど様々なデザインアセットをライブラリにして保管することができます。Library は Dropbox や Google Drive を経由して共有することができるので、Sketch + Craft を使っているデザイナーであれば、最新のライブラリにアクセスすることができます。今までだとテンプレートファイルのようなものを作って共有していましたが、その手間が省けることになります。Sketch 39 からはシンボルのグループリサイズもできるようになったので、ライブラリを作って共有するメリットがますます増えてきました。

まとめ

スタイルガイドはただ作れば良いというものではなく、どのように運用するのか、誰が活用するのか、ワークフローにどう役立てるのかによって作り方が変わってきます。デザインとコードの間だけでなく、デザイナーとデザイナーとの間の溝をどう埋めるのかという課題があります。デザインは、コードのように進捗・工程の可視化が難しいです。だからといって、デザイナーに寄り過ぎたツールになるとコーディングとの連携がかえって難しくなることがあります。

残念ながら、「これを使えば完璧」と呼べるようなパーフェイクトツールはありませんが、選べるツールは増えてきましたし、組み合わせと工夫次第で溝が埋まりやすくなりました。ひとりで作るわけではないからこそ、ツールを触りながら「これは共有しやすいだろうか」ということを意識していきたいです。