はじめまして。デジタルメディア アラウンド15年生のデザイナーMoritomoです。今所属しているRettyで最近Twitter+note熱が高くなっているので、現在手掛けている、とある突貫リニューアル（部分改修）で、エンジニアさんと改善を加えながら進めることの出来たデザインシステム構築の体験談をご紹介させていただきます。

　―　
そもそもデザインシステムは必要か？

デザインシステム作るぞーと気張ってみたものの、資料化した頃には疲れ果てていて、誰かに渡しておしまい。絶対そうなるし、それならコストに合わないよね？そう思っている方、結構いらっしゃるのでは？
もしくはデザインガイドラインがそうだったのでデザインシステムもきっとそうだ！という方。
わかります。
私もかつて、クライアントは絶対使わないのにこの無駄な資料作成時間なんなのと思いながらガイドラインを作ったことがあるので。
とはいえ、ガイドラインは、ある程度決まったものを共有するためのものですよね？
ですが今回は“システム（仕組み）”のお話です。
一部でも決まっていればその分は役に立つ。それが“システム”。
色彩設計を明確にし、タイポグラフィのルールをととのえ、グリッドを定義し、、、何もかも揃えて、、をしなくても、さくっとお役に立って有益なものでしたよというお話で皆様のお役に立つのもだとお伝えしたいと思います。

　―　
最小単位のデザインシステム

まずは、デザインシステムを構築するための要件。そして、それを形にするためのコアコンセプトを最小単位のデザインシステムとします。
今回の事例では、サイトに求める機能の多くが複雑な機能を多数有するWEBアプリケーション寄りのサイトだったため、以下をポイントとして定義しました。

―　TARGET　―
対象の業界に関して平均的な知見を持ち、
WEBリテラシーは高くない方に
―　HOW　―
理解のサポートや親しみやすいトンマナで
機能の持つハードルを下げる事で
―　WHAT　―
人的サポートなしでもある程度理解できる機能を
提供すること

この3点をサイトが持つべき最低限のUXと定め、それを満たせるコアのルールとして下記を定義しました。

インタラクティブコンテンツと
非インタラクティブコンテンツを
明確に分ける

どれが上記に当たり、最もシンプルに表現される時にそれが必要とする最低限の特性は以下にしました。

上のインタラクティブコンテンツの基本特性を言語化すると以下になります。
・インタラクティブ、もしくは、インタラクティブコンテンツを内包するエリアは必ず角丸で囲む。
・ある一定の組み合わせでヒエラルキーを壊さない条件をクリアできる時のみ奥行きの概念を採用
・主体となるであろうSUBMIT機能はブランドカラーをとりあえず採用
・要素同士の組み合わせによって発生するであろうサイズの変化に視覚的な統一性を持たせるためのRのバリエーション

こちらは非インタラクティブコンテンツの想定要素です。
情報の認知を促進するための要素とインタラクティブコンテンツとルールが混ざりがちなテキストのアイコン・ラベルをぎりぎり混ざらないようにするための基本形。

これだけ。
誰でも決められるこれだけのことを決めて画面設計の展開に臨みました。

　―　
色彩設計の補完

今回の例ですと、情報・画面設計も同時に進めたので、初期は必要とされる基本の色彩設計を洗い出すことが出来ませんでした。
なので、既存のサービスで使っている色を絞りながら、最低限必要の役割に対する色の定義を脳内で整理しました。
※上の図はUXに強いエンジニアと相談しながら、既存の色をUIのフィードバックなども踏まえ調整した段階で作成したものです。

　―　
リスト作成

色彩設計のベースとキーページの構築を並行して進める中で、主体となるUIモジュールをちょこちょこ集めていきました。
これは、アートボードを用意してそこに集めています。そうすることで、シンボルごとのアートボードの装丁に惑わされず、展開していく中で生まれた迷い、それによるブレを俯瞰しやすくなりました。
（例えば、要素を並べていく中で、色の濃さが気になりだして途中から薄くしてしまったぱっと見分かりにくい差分など）

　―　
関係値の整理

色の意味と、形、利用シーンがサイトデザインの方でも明確になってきたところで、汎用パーツの関係値を整理しました。ここを整理することで、これらの要素が複雑に組み合わさったときでもサイト内で培われるユーザーさんの学習経験に迷いを生まずに進められると判断したためです。
もちろん、一番最初に決めた３点に矛盾しない構造であるかどうかも判断基準です。

　―　
構成要素の最適化

一緒に進めていたエンジニアがUX観点で意味のある要素展開を指摘してくれたので、それらを全体に展開した場合に矛盾が生じないか構成要素を洗い出し、それらの反応すべきタイミングなどもつめていきました。

こちらはフォームモジュールに置き換えて考えたものです。

ここでは省きますが、それまでの基準を具体的に踏まえて行くことで、どこを変え、どこを残すかをエンジニアと効果的に擦り合わせが出来たと思います。

今は空き時間に最終的な整合性を確認する意味でモジュールリストを作っていますが、もうあまりぶれないので、必要な時にそこだけ作る様にしています。

　―　
まとめ

いかがでしたか？
ほぼみなさんが普段やっていることですよね？
ただ、デザインシステムであるとして進めた、ちょっとの比較と言語化でそのロジックが有効かどうかの検証を行い、無駄なブレを省いたクオリティ定義が効果的に行えた気がします。

とはいえ、スタートが“突貫”だったので、出来ないことも多くあり、この案件はこれからのユーザーテスト、ヒアリングで大きく変えていくべきものです。それでも、基準、法則がないよりはどの部分の思考を修正すればいいかはっきりしますし、一覧性もあるので修正も効率的かと思います。

幸運なことに私の会社にはユーザーさんの体験を良くするための開発という点をしっかり提案してくださるエンジニアさんが多くいます。今回の案件では特にその傾向がつよい人とお仕事できたこともあり、初期の方針に対し、どうするべきか、何がふさわしいかを積極的に議論できました。修正を入れていく段階でも同様により良い形とシステムを作っていけるのではないかと期待しています。

それでは、最後にポイントをまとめて終わりにしたいと思います。

デザインシステムはリリース後に必要かどうかというだけではなく、
出すべき設計の精度を上げるためにも機能する。
―
完成を目指すより部分でもいいから
“仕組み“としていち早く使う事を目指すといい。
―
機能させるにはコアを見誤らない事が重要。
―
見極める目的よっては、システムで整理していくべきポイントが、
タイポグラフィや、色再設計、レイアウトなど変化する
―
作りきってからの変更ではないので、
必要なら変更は柔軟に行える。
―
そして、恐らく、
デザインシステムで作ったロジックは
とても再利用しやすい

みなさんも小さなかわいいデザインシステム構築を
まずは初めてみませんか？

--
もっといいやり方あるよ！
もっとこうしたほうがクオリティ上がるよ！
などご意見いただけたらとっても嬉しいです。

　―　
関連note

このデザインシステムを元にしてタイポグラフィのシステムに展開した事例を新しくご紹介しています。よかったらこちらもどうぞ☺️

□ デザインシステムをアジャイルで。タイポグラフィックマトリックスをデジタルの世界に
□ デザインシステムをアジャイルで。表記ルールをサービスデザインに
□ デザインシステムをアジャイルで。カラーシステムは機能性から
□ デザインシステムをアジャイルで。UIをブランドリソースのようにルール整理してみる
□ CDO2年生のアイコンはサインシステム。そう考えて設計をする。