ドキュメント | 1人design system advent calender 12日目
12日目はドキュメントについて。
When creating a design system it’s important to be mindful that you won’t be the only designer (or developer) who works with it.
デザインシステムを作る上で、デザインシステムに関わるのが自分1人だけにならないように注意しておくのが大事になる。だれも使い方が分からなかったり、どういうコンポーネントがあるのか把握できなかったり、そういう状態のデザインシステムであればうまく運用していくのは難しいはず。なので、ドキュメントを用意することで、デザインシステムに関わる人たちがデザインシステムの内容を把握して、使いこなせるようにする助けになるようにしておきたい。
ドキュメントの構成
プロダクトによって構成要素は異なるけども、いくつかのデザインシステムに目を通した結果、多くのデザインシステムで見られた要素は以下のもの。
- ガイドライン（Voice & Tone、Principle、a11yなど）
- カラーパレット
- タイポグラフィー
- アイコン
- グリッド
- モーション
- コンポーネント
- デザイナーズキット（Sketch、Photoshop、Figmaなどのデザインファイル）
- Storybook
これらから判断するとデザインシステムを構成する要素は、従来のフロントエンドにおけるスタイルガイドに、デザインのガイドライン、デザインファイルなども含めて、UIに関わる要素全般と言って良さそう。
ドキュメントをどう作るか
特に他の形でドキュメントを用意する理由がない限り、スタイルガイドを作ることになると思う。スタイルガイド生成ツールを使うなり、テンプレートエンジンやスタティックサイトジェネレータを利用してドキュメント生成するなり、やり方はそれぞれに適したものを選択すればいい。ReactやVueであればStorybookを利用するのが良いケースもあるだろうし、Plasma design system – Andrew Couldwell – Mediumでは、最初はSketchに記述していたものを誰もが見れるようにGoogle Docsに記述するようにしたことを紹介している（今はPlasma design systemに移行している）。このように、どのようなツールを使うかはそれぞれで判断すれば良くて、ドキュメントによってプロダクトに関わる全員がデザインシステムについて知ることができる状態を作る目的を果たせていれば、 極端な話、なんでも構わない。
ドキュメントを作る上でより重要になってくるのは、ドキュメントを更新していくこととドキュメントからデザインシステムについて把握できるようになっていることの、デザインシステムを提供する側と利用する側の折り合いをどうやってつけていくかだと思う。 提供する側は、ドキュメントの更新・管理に多くの労力をさくことになれば、デザインシステムを運用していくことが負担にしかならないし、利用する側からするとドキュメントが更新されていなかったり、利用する上で必要な情報が欠けていたりすると、デザインシステムに対する信頼感は持てなくなる。デザインシステムにかけられるリソースに余裕があるのであれば、ドキュメントをちゃんと整備していけばいいかもしれないけど、限られたリソースでやりくりしなければならないことの方が多いはず。
デザインシステム自体もそうだけど、ドキュメントに関しても最初から100％の状態を目指すのではなく、提供する側が更新・管理していけて利用する側がデザインシステムに不信感を持たないような落とし所を探りながら進めていくことが、重要な点だと思う。
このペースだと今年中に終わらず来年までかかりそうだけど、とにかく最後までやりきりたい。 13日目はデザインシステムの運用について書く。
