スタートアップによくある話ですが、デザイナー不在でかつプロダクト開発をスピード重視で進めていたので、デザイン、レイアウトが実装者によってばらつき、一貫性が取れていない。
開発が落ち着いたタイミングで、デザイナーの方がジョインしデザインシステム導入、既存のUIデザインの見直しをして、より良いUXを提供しようという動きになり、自分はデザインシステムとフロントエンドを繋ぐ橋渡し的な役割を担当しました。
その時の学びと、書籍などから引用した情報をまとめました。
デザインコンセプト
- ユーザーはどんな人達か？
- どんな価値を提供するのか？
- そのサービスを擬人化したり、どんな性格かを決める
以上踏まえて、一言でまとめたものがデザインコンセプト
それを基にデザインシステム、UIデザイン、ライティングなど設計して頂きました。
色設計
デザインシステム構築にあたり、色がなくてはコンポーネントも作れない一番基本となる要素です。
色設計で押さえておきたい種類
- Primary ブランドの色
- Secondary ブランドを引き立たす、コントラストとなる色 x 10
- Success、Errorなどシステムに必ず必須な色
*コントラスト：視認性を高める
デザイナーに上記を設計してもらい、構造、命名などをフロント側のコードと完全に一致させました。これにより、Figmaに適用されている色をみればフロント側でどう指定すればいいかが明確にわかる状態になりました。
例えば以下の日付は背景が error/100 で文字が error/default です。
これをフロント側でスタイルを当てるにはこうなります。
tailwindを採用していたので、classに直接CSSを書きます、またdefaultは省略可にしてます。
<div className="bg-error-100 text-error">
{data.date}
</div>
コンポーネント設計
機能、見た目をまとめた部品を共通化する事で、UIの統一化ができ、車輪の再発明を防いだり、開発効率を上げる事もできる。いきなり全て部品をコンポーネント化するのは高コストなので、利用頻度の高いボタン、ラベルなどをまずは導入しました。
ボタン
UIの中で多く使われ、カーソルで狙いを定めて、ユーザーが重要な意思決定をする（購入の場合は特に）事に使われるので、とても大事な部品。
共通化は意外と難しく、共通化にこだわりすぎて返って複雑な実装になったり、どれを共通化するか、どう分けるかをデザイナーと議論して、調整してもらい、シンプルな設計にしてもらった。
以下はボタンの例：
- テキスト：必須
- サイズ：２種類のみ
- アイコン：あり、なし
- 色：プライマリーかセカンダリーの２種類から、後から1つ追加 (これ以上増えたらコンポーネントを分ける事を検討)
- ホバー状態
- disabled状態
- クリックハンドラー
例えばfigmaでコンポーネントの詳細を確認すると、こんな風に表示されるので、
フロント側はBrandButtonをインポートして、必要なパラメーターを設定すれば簡単にFigmaで指定されたデザインを再現できる様になります。
<BrandButton
type="secondary"
size="small"
icon={<Icon />}
title="情報整理シート"
handleOnClick={() => {}}
/>
デザインシステムを導入して良かった事
いきなり全ての部品をリプレイスするのはコストがかかるけど、色と一部のコンポーネントの導入だけなら低コストで、結構一貫性が出ました。重複する似た様な実装をだいぶ減らせて、実装も楽になりました。
（小規模システムなら、色とコンポーネントだけのデザインシステムをミニマムに導入するケースが多いらしいです）
そして、導入後間もなくサービスロゴが変わり、色もアップデートする必要が出ましたが、カラーファイルのみ更新で済んだのでサクッと終わりました。
作って終わりではない、継続して進化させるもの
デザインシステムも「プロダクト」なので、後から変更が入ります。
新機能やページを設計してみると既存のコンポーネント群では対応できない事も起こりえます。そういう場合は拡張したり、新規で作ったりもして対応し、デザインシステムも進化させていく必要があります。
最後に
デザイナーとエンジニアが一緒になって議論しながら設計・開発を行った事で実用的なデザインシステムになったと思います。
これを機にStorybookを導入、さらに、コンポーネントテスト導入もつなげていける。
余談：
某社ではサービス内で使用するイラスト、アイコンにまでシステムを作って統一化してるらしいです。大規模サービスだとデザインに関わる人員も多いからだと思います。