ちいさく始めて、おおきく育てる。週1時間からはじめるデザインシステム構築

こんにちは、デザイナーの長尾です。2024年の8月からAssuredにジョインし、プロダクトデザインを担当しています。今回は、その一環として取り組んでいるデザインシステム構築についてお話しします。

着手した当初は「何をすべきか」「どこまでやるべきか」が分からず、手探りで進めていました。また、プロダクトの開発タスクと並行で行うため、デザインシステムに費やす時間をなかなか捻出できないという課題感もありました。

ですが、以下のようなことを大切にしながら、すこしずつ形になってきたので、振り返りを兼ねてこれまでのプロセスをまとめてみます。これからデザインシステムを始めようという方の参考になれば幸いです。

ゴールを描いて、バックキャスティングする
- 将来どうなっていたいか、の認識を揃えてからステップにおこす
現状を整理し、MVPを決める
- 現状を整理して、必要最低限の範囲からはじめる
ちいさな改善をつみあげる
- 完璧を目指すのではなく、少しずつすすめる

デザインシステムを作ることになった背景

前に所属していたチームでは、Storybookを活用することで、コンポーネント単位ではFigmaを参照しなくても実装できる仕組みが整っていました。しかし、色や余白、コンポーネントを「どう使うか」に関してはデザイナー同士のコミュニケーションのみで完結しており、ルールに関して、エンジニアと連携できていなかった部分が多くありました。

そのため、画面変更を伴うリリースのたびにデザイナーがリリース前のQAを行う必要があり、プロセスが複雑化していました。このような状況を経験する中で、「チーム全体が使いやすい仕組みが必要かもしれない」と考えるようになりました。

Assuredでは、クラウドサービス利用企業様、クラウドサービス事業者様、社内管理用の3つのプロダクトに関わっています。私がジョインした当初、プロダクトはリリースから約2年半と歴史が浅く、デザイナーは1人だったにも関わらず、Figmaでは一定のコンポーネントライブラリが整備されており、PdMや他のチームメンバーと議論しながらデザインを検討しやすい仕組みができていることに驚きました。一方で、ライブラリの設計意図や、コンポーネントの利用ルールが暗黙知として存在していることが課題でした。これにより、コンポーネントを探す、利用意図を探るという点に時間がかかる場面が多く見られました。

ステップ１：ゴールを描いて、バックキャスティングする

こうした課題を踏まえ、まずは以下3つをゴールとして設定し、デザインシステムの構築をはじめました。

誰もが簡単に目的のコンポーネントを見つけ、理解できる仕組みを作ること
- コンポーネントの設計意図や使い方を言語化し、迷いなくUIを構築できることを目指しました
効率的でスムーズなデザインプロセスを確立すること
- プロトタイピングしながらディスカッションする場も多いため、アイデアを素早く具体化して複数人で円滑にコミュニケーションできるような基盤を目指しました
将来的なサービス拡張に対応できる柔軟性を持たせること
- クラウドサービス利用企業様、クラウドサービス事業者様の両プロダクトで共通のデザインシステムを使うほか、さらにプロダクトが増えることを見越した設計を目指しました

ステップ２：MVPを決める

まず着手したのは、コンポーネントの整理と基本要素のデザイントークン化です。散在していたコンポーネントをFigma上で整理し、アクセス性を高めました。その際、各コンポーネントに対して次のような情報を明文化しました

概要：サマリ
仕様：構造や状態、インタラクションをまとめたもの
パターン・使い方：どのようなシーンで使うのか

これにより、画面設計時に一貫したコンポーネントを選定しやすくなり、新規にコンポーネントを作る際の基盤が整いました。

さらに、トークン化では、色や余白、角丸などの基本要素を対象に Primitive Tokens を作成し、Semantic Tokens まで定義をしました。Semantic Tokens を設計する際は、並行して進んでいたフロントエンドのライブラリ変更プロジェクトとも連携し、フロントエンドエンジニアに意見をもらいながら進めました。特に色に関しては、どの色をどの状況で使うべきか、意味づけの粒度やパターンを議論・検討しながら命名しました。

ステップ３：ちいさな改善をつみあげる

継続的な改善を意識し、毎週1時間の定例ミーティングを設け、どんなに小さな進捗でも必ず共有するようにしました。他の業務と並行してデザインシステムを構築していくためには、少しでも進捗を出し、こまめに共有することが重要だったと感じています。

当初は定例を2週間に1回の頻度にする案もありましたが、週1回とすることで、より短いサイクルで課題を発見し、改善していく体制を整えることができました。この週1の頻度が功を奏し、小さな進捗を積み重ねるなかでデザインシステムが少しずつ育ち、結果としてスムーズな構築体制が整ったと思います。

また、小さな進捗でも共有し、それがチーム全体での成果として認識されることで、各々が自分の貢献を実感して、モチベーションを維持できたことで継続してデザインシステムに関わる時間をつくることができました。

さらなる課題解決に向けて

次に取り組んでいるのは、「文章設計におけるグロッサリーの統一」と「ブランドガイドラインとの連動」です。

文章設計におけるグロッサリーの統一

Assuredでは、開発チームだけでなく、セキュリティチームやオペレーションチームもプロダクトを介してお客様とコミュニケーションをとっています。しかし、同じ意味を持つ単語や表現がサービス内で統一されておらず、それぞれが自由に異なる言葉を使っている状況でした。

それぞれのチームでこの状況に問題意識があったのですが、Slack上で声が上がったことをきっかけに、チームを横断して協力しながら統一ルールを整備する取り組みが進んでいます。

たとえば、クラウドサービスを利用する企業やお客様を指す際に、「クラウドサービス利用企業」「クライアント」「サービス利用者」など、同じ意味を持ちながら異なる表現が使われていました。こうした解釈の違いを解消することで、社内の認識齟齬を防げるだけでなく、お客様の認知負荷を減らしたり、よりコミュニケーションが円滑になると考えています。