※過去ブログからの移転です

エンジニアとデザイナーが互いにプロダクト開発をしやすくするためにデザインガイドライン(あるいは拡張してデザインシステム)を作ることがあります。いま私がデザインしているプロダクトであるHERP ATSでは1年前にデザインガイドラインを設けて運用しています。

デザインガイドラインを実際に構築して1年ちょっと運用してみて「最初に構築するときここまで考えておけばよかったな」あるいは「どう運用するとうまく開発に乗るのかな」ということについていろいろと知見が溜まったので今回はそれらについてまとめてみました。

前提

プラットフォームはWEBで想定デバイスはPCのみ、toBのSaaSであるという前提で読み進めていただけたらなと思います。今回はiOS/Androidなどのネイティブアプリは含めていません。

デザインガイドラインとは？

人によって微妙に定義のスコープが違うので私自身が思っているデザインガイドラインについてですが「そのプロダクトの配色やコンポーネントの配置およびコンポーネント自体のルールを定めたもの」と定義しています。ここでいうコンポーネントはGUIを構成する部品という意味です。

デザインガイドラインを構築するメリットとしては、

・ブランドやインターフェースとしての一貫性を担保することができる
・新たに機能を追加するときのUIのベースになるので開発工数削減にもつながる
・開発サイドとのコミュニケーションが取りやすい

などいろいろあります。

実装側と密結合してデザインガイドラインとしても機能しているものでいうと例えばBootstrapが上げられます。フロントエンドWebアプリケーションフレームワークとして実際便利で、下手にデザインするくらいならBootstrapを使うほうが良いくらい完成度は高いです。しかしながら、かゆいところに手が届きにくくCSSだけで表現しきれないコンポーネントもあるため、サービスとしてのオリジナリティやブランドを作りたい場合はやはりゼロからデザインガイドラインを構築するのが良いかと思います。

初回構築時のポイント

スタートアップ等でMVP(Minimum Viable Product)な開発をしているならば、最初は必要最小限のコンポーネント構成でデザインガイドラインを構築していくのが正解だと感じています。実際私たちもまず使うコンポーネントのみで構築していき、無理なく導入していくことができました。

しかしながら、将来的には必ず実装・デザインしなければならなくなるコンポーネントというのは存在しており、それらに関してはその時点で実装するかはともかくデザインは予め最初に作っておくべきだと反省しています。

初回構築時に必要なコンポーネントは以下の通りです。

・ボタン
・フォーム
・チェックボックス
・ドロップダウン
・カラー

どういうポイントに気をつけるべきか解説していきます。

ボタン

ボタンの用途の整理(primary, secondary, danger, ghostなど)
主要なアクションが実行されるボタンではprimary、削除をはじめとした不可逆なアクションではdanger、キャンセル等の補助的なアクションではghost、などというようにどういった用途のときにどんなボタンなのか規定する必要があります。

ボタンの幅はどのようにして規定されるか
n文字までは固定幅のボタンにする、n文字以上の文言がボタンに入るときはpadding固定で文字数依存の可変なボタンにする、あるいはグリッド分割に依存するなどが挙げられます。

文言のルールの規定
UX Writingにも関わってきますが文言にルールが必要です。例えば体言止め(例. 送信)を基本とするのか必ず動詞とするのか(例. 送信する)や、そもそもn文字以上の文言はボタンに入れることはできないなど。

ありえるstateの洗い出し
デフォルト, hover, focus, disabled, loadingなどがあります。

アイコンに対するスタンス
ボタンに対してアイコンは必須なのか、任意か、使えないのか、どのようなルールで利用すべきなのかといったことを決める必要があります。

フォーム

<input> or <textarea>
いわゆる一行のフォームなのか複数行のフォームなのかで条件分岐できます。<textarea>の場合はline-heightをどうするのかなど考える必要もあります。

labelはあるのか
ほぼほぼ必須だとは思うのですがフォームに対してlabelはどう規定されるかを決める必要があります(例. 位置やstyle)。ここには必須labelも含まれます。

descriptionの有無
そのフォームに対する説明がなされる場合はどのような形式でされるか、そもそもdescriptionは無いものなのか。

ありえるstateの洗い出し
デフォルト, hover, focus, disabled, invalidなどがあります。また、invalidなときはどのようにフィードバックを出すかも決める必要があります。

placeholderの文言ルール
ボタンと同じくplaceholderとして表示される文言にルールをもたせましょう。

チェックボックス・ラジオボタン

ありえるstateの洗い出し
checked状態とunchecked状態、hover, focus, disabledが考えられます。uncheckedとdisabledに対して差を付けにくいからちょっとデザイン力が必要になるなあと個人的には感じます。

ドロップダウン

通常時とドロップダウン展開時
通常時とクリックしてitemが展開およびhoverしたときのデザインを考える必要があります。ドロップダウンをブラウザ標準のものではなくオリジナルなデザインにする場合はTabキーあるいは↑↓キーで操作できるように実装を頑張るのかどうかエンジニアと要相談です。工数に対してのリターンや他のものとの優先度を考えるともっと他の部分にリソースを割いたほうがいいのではないかという判断もありかと思います(弊社はそういう判断をしています)。

ありえるstateの洗い出し
デフォルト, hover, focus, disabledがあります。

カラー

Primary paletteとSecondary paletteの設定
AtlassianのデザインシステムでいうところのPrimary paletteとSecondary paletteを設定するのが私が思う今のところの最適解です。弊社は最初アクセントとなるキーカラーが1色しかなくて何とかやりくりしてたのですが機能を追加していくたびにどんどん苦しくなっていって最終的にはPrimary paletteとSecondary paletteに落ち着きました。Primary paletteでキーとなるカラーに対して明度で展開しているところがミソです。

全体として

各コンポーネントは挙動が細かいのと種類が多いのでベースとなるデザインだけ作って、エンジニアと一緒にペアプロしながら試行錯誤して決めていくと結果的に早くできて非常によかったです。

デザインガイドラインの運用方法

仕組み編

弊社ではherpismと呼ばれるコンポーネントのライブラリとして切り出しています(ひとつの独立したリポジトリになっている)。実際のプロダクト(メイン画面や管理画面)はこのherpismを参照して基本的にUIが構成されていて、したがって「このコンポーネントをちゃんとデザインガイドラインとして定めて実装もしてほしい！」となったらこのherpismに追加しなくてはいけないようになっています。

なぜこのような形にしているかというと独立したコンポーネントのライブラリとして切り出すことで今後別のサービスが生まれることになった場合に既存のサービスのコードベースを参照しないで済むからです。

コンポーネント追加編

herpismにコンポーネントを追加するときには以下のフローを踏んでいます。

①新機能実装や既存機能改善にあたり(最適な体験を届けるためやむを得ず)新作のコンポーネントが生まれる

②エンジニアとそのコンポーネントの強度(そもそもWEB上に存在するものとしてあり得るものかや実装可能性とUIとしてのわかりやすさ)と普遍性(今後も他の画面にコンポーネントとして出てき得るか)の検討をする

③コンポーネントとして追加する合意が得られたらエンジニアはherpismにコードとして追加、デザイナーはSketchのSymbol Libraryに追加、もし合意が得られずしかしUIとして最適ならばherpismには追加しないが野良のコンポーネントとしてそのページのみに実装する

②の段階でいつもデザイナーとエンジニアでヒートアップしながら採用するかどうかのバトルが起きます(いい意味で)。

そしてこの一連の運用の仕方のメリットは以下になります。

・ちゃんとエンジニアとデザイナーで合意を得てデザインガイドラインを構築していける(ちゃんと運用していこうとなる)

・とんでもないUIコンポーネントが生まれづらい(明らかにWEBではコスパの悪いものやWEBの挙動としておかしいものに検閲がちゃんと入る)

・herpismをライブラリとして切り出しているので(追加していくという運用コストはあるが)実装とデザインデータの乖離がなくなる

使い方編

デザインガイドラインはWEB上あるいはStorybook上にまとまっておりデザイナーとエンジニアはそれを参照します(WEB上のものは諸事情により非公開になっています)。例えば、ボタンの文言ルールやコンポーネントの使い分けなどは全てここにまとまっており、これさえ見れば誰が見てもキャッチアップできるようなものになっています。

またHTML, HyperScript, Pugベースでどうコードを記述すればいいか、どうクラスを指定すべきかも盛り込んであるので単にデザインがこういうものですよというドキュメントではなく、実装と密結合したデザインガイドラインとなっています。

業務委託やインターンがはじめて開発に着手するときに困らないように指針となるようなアウトプットであることが大事ですね。

最後に

このデザインガイドラインの初回構築時のポイントと運用方法はあくまで弊社の現段階での場合ということで参考程度に考えてもらえればと思います。プラットフォームがiOS, Androidのネイティブアプリになるとまた違ってきますし、各チームで最適解を模索していく必要があります。他社のデザインガイドラインの運用方法もっと知りたいなあ〜。