デザインシステムを導入するまで
この投稿は さくらインターネット Advent Calendar 2018 の 19 日の投稿です。
UXデザイングループの @Sapphirus です。入社して 1年と少しが経ち仲間も増えてグループらしい体制になってきました。
さくらには さぶりこパラレルキャリア という制度があります。副業先でデザインシステムを運用して 1年ほど経過したので、導入に到るまでに実施したことや得た学びを共有したいと思います。
デザインよりの話なのに図版がひとつもないのは察してください。年末ですからね。
実施したこと
- デザインの棚卸し
- 共通認識としてのコンセプト作り
- ムードボーディング
- 批評のしかた
- デザインシステム
デザインの棚卸し
成果物からは一部の情報しか汲み取れませんが、実際にはいくつかの情報が組み合わさったものが含まれています。その情報が共有されないまま時間が経つとどうなるでしょう。解釈の違いなどで少しずつ齟齬が起き、意図しないバリエーションが増えていきます。
ボタンひとつとってもどれが押せてどれが押せないのか、都度増えるバリエーションはお客様からすれば混乱しかありません。現状を把握する上でも定期的にデザインの棚卸しをして作りすぎていないか確認します。
共通認識としてのコンセプト作り
一貫性を担保していないとお客様の負担になります。認識のズレや食い違いといった齟齬は、関わる人数が増えるにつれ起きやすくなるように思います。プロダクトに関わる登場人物をギャレットの5段階モデルの階層を例にみてみます。
表層（Surface）
- ビジュアルデザイン
骨格（Skelton）
- ナビゲーションデザイン
- インターフェースデザイン
- 情報デザイン
構造（Structure）
- インタラクションデザイン
- 情報アーキテクチャ
要件（Scope）
- 機能要件
- コンテンツ要件
戦略（Strategy）
- ユーザーニーズ
- サイトの目的
スタートアップの初期では特に多能工を求められるので、ひとりで複数の役割を担当することもありますが、それでもすべてをこなすということは稀だと思います。ひとつの成果物を作り上げるのにプロダクトオーナー、マーケター、エンジニア、ライターやデザイナーなど複数人が関わってきます。
KPI や KGI も役割によって変わってきます。プロダクトに関わるそれぞれの人の想いが乗ってくるため齟齬が起こりやすくなります。プロダクトがブレないためにも関わる人の共通認識としてのコアコンセプトが必要です。
メンバーで集まって Why から始め「目的」を言語化します。これをコアコンセプトとします。コアコンセプトはレビューをする際の指標にもなりました。
ムードボーディング
軸があってもブレてくることがあります。抽象（Abstruct）に近い、機能要件やコンテンツ要件はコアコンセプトがあれば、要件を取り込む、取り込まないの判断がしやすいのですが、具象（Concrete）に近づくと可視化されていくため、思っていた雰囲気と違うというような声が上がります。そこで関係者を集めて各々がイメージする色、形、雰囲気や手触りなど連想するキーワードを出してもらうことにしました。
そのキーワードを元に画像検索（Pinterest を使いました）をしながらメンバー間でイメージを擦り合わせ、検索結果をまとめて現時点での共通認識として方向性を決めます。その時に除外リストも作りました。全体像が掴めてくると当初の方向性と求めているものが変わってくる場合もあります。その場合はムードボードを作り直します。
批評のしかた
デザイン批評に慣れていない場合、例えばデザインの訓練を受けていない人がデザイン批評をすれば負荷が高くなります。どこを見ればいいのかわからず気になったところを指摘したり、善意から何かしらフィードバックしようとして主観的な批評を繰り返してしまい双方にいいことがありません。そんな時はレビュアーに機能要件を満たしているかを評価するよう伝えるなど、どこを観てほしいか明確にします。
その際、必ずデザイナーから先にデザインの意図と経緯を説明するようにします。批評する側は個人攻撃にならないよう注意し、批評される側は攻撃と受け止めないようにします。
デザインシステム
対象がスクリーンか印刷物かなど前提となる条件によっても満たすべき機能要件や環境依存がかわります。インタラクション、余白、グリッドなどのデザインに関わる要素もそうですし、命名規則や前後のコンテクストのような平面からは伺えないものも共有したい重要な情報です。Atomic Design を参考に、目に見えないデザイン要素も含めて階層化してカタログにしました。
階層化によるメリット
Atomic Design のように階層化したものをカタログ化することにより、コンポーネントの作り過ぎを抑制し、変更時の影響範囲の予測やデザインの一貫性、品質の担保がしやすくなります。同時に、階層構造にすることで各層ごとに必要な登場人物を交えて会話しやすく（Storybook 上で Organisms や Templates をモックやワイヤーの代替にします）なると考えます。印刷物においても、Atoms に相当するものに VI を定義すれば適用できるでしょう。
とはいえ良い点ばかりではありせん。生きたドキュメントを運用するのは大変ですし、エンジニアとデザイナーの協力が必要です。その前の現状分析やデザインの棚卸しなど目を背けたくなる現実があります。
試しに CSS Stats でサイトの URI を入力してみましょう。あなたも作りすぎているかもしれません。
おわりに
ブランディングやデザインの運用もそうですが、「サービス間の横断のしやすさ、操作感」のような、お客様に一貫性のある体験を提供しつつサービスの品質をカイゼンしていくには、さくらのデザインシステムが今後必要になると思っています。デザインシステムと合わせて OOUX も今後エンジニアと協力して取り組みたい課題です。
また、予測が困難で複雑な時代においてデザインはデザイナーだけのものではないのかもしれません。より良いものにするためには多角的な視点を取り入れて課題に取り組み、お客様に価値を届けられるよう誰でもデザインに参加できる状態が理想的だと思っています。
参考
- さぶりこ
- The Elements of User Experience
- OOUX — オブジェクトベースのUIモデリング
明日のアドベントカレンダーは
@kumikumitm さんです。
どんなお話でしょうか？楽しみです。