BASEでデザイナーをしている吉岡です。
今回は、デザインチームにおけるデザインガイドラインの成り立ちについて書こうと思います。
書きはじめてから1年半ほど経過しますが、現状運用しているガイドラインはこちらです。
BASEでは2018年頃から、UI-kitやコンポーネントライブラリを作り始めてきました。
当時はデザイナー3〜4人、エンジニアが3人ほどでSketchのUI-kit → コンポーネントライブラリへ実装する流れですすめてきました。
一通りコンポーネントが出揃ったのですが、デザインチームの組織規模が大きくなってくることで「担当するデザイナーごとに、若干スタイルや使い方が違うコンポーネント」が生まれてくるようになっていきます。
デザインレビューの場面でも「このコンポーネントは、別の画面だとこう使ってて...」といったレビューが増え、手戻りも少しずつ出てくることに...
これでは、各デザイナーのレビューへのモチベーションも下がりますし、レビュー自体もっとユーザー体験や意図通りのUIなのかについて話し合われるべきと考えているため、既存のコンポーネントに対して認識のズレはなるべくなくしたい。
そこで、コンポーネント定義を言語化して各デザイナーの共通認識を合わせることを目的にデザインガイドラインをつくるプロジェクトがスタートしました。
当時、各デザイナーがどんなことに悩んでいたかというと
といったことでした。
各ステータスなどに関してはすでにUI-kit上で定義されていましたが
デザイナーが悩んでいた箇所は
- いつ、どういう場面で使っているのか
- どんな挙動をするのか
- または使わない場合はどういう時か
が課題でした。
当時は使っていない・もしくは実は不要なUI-kitも存在していたこともあり、コンポーネント毎に担当を割り振り下記のようなフローでガイドラインを作成していきました。
ガイドラインを小さいところから始めるメリットは、どこまで書いたか進捗具合を測ることができ、都度完成することによりモチベーションを保つことができるところです。
また、ガイドライン担当をコンポーネント毎に分けたことでそのUIが現状サービス内でどう使われていて、こういう定義だろう（もしくはこうすべきではないか）といったUI自体への理解も深まったと思います。
一方で、これらのツールでは、シンボルをガイドラインファイルへ持ってきやすいものの、デザインツールはテキストを書くものではないのでかなり面倒でした。
そのため、ある程度ガイドラインを書ききったタイミングで、もっとデザインチームにとってアクセスがしやすく、且つ書きやすいツールを探し、zeroheightに移行しました。
現在では、この流れで運用をしています。
zeroheightへ移行を決めたポイントとしては
- ドキュメントが書きやすいこと
- UI-kitを簡単に追加・変更に追従できること
- Storybook読み込みができること
です。
実際に各デザイナーが悩んだ点や過去に質問された点などをもとに、コンポーネントの定義をきめていきます。
主に書いているのは
- コンポーネント名
- コンポーネントの概要
- どういうStatusがあるのか
- どういう挙動をするコンポーネントで、どうレイアウトするのか
- Storybookを埋め込む
- NG項目
の項目になります。
具体的にお見せすると下記のように各コンポーネントを定義し、ガイドラインを言語化しました。
ガイドラインは、書くことより運用の方がかなり難しいです。
例えばUI-kitのメンテや、ブラウザのアップデートにより随時更新していく必要があります。
まだチームに最適な運用を模索しているのが現状ですが、サービスの拡大や時流に合わせてガイドラインのアップデートをしていきたいと思っています。
このデザインガイドラインは、デザイナー・エンジニアに向けて書いたものですが、今後は全社的に有用なドキュメントにしていければ良いなと思っています。
まだ明記できていない部分ですが、デザイン原則などを言語化していくことで全社的に「BASEのはこういう温度感のサービスです」ができるはずです。
BASEのデザインガイドライン、今後も進化を続けていくので続報をお楽しみに。