レストランプロダクト開発部の矢澤です。
一休では「RESZAIKO」というプロダクトの開発を行っています。 この開発を進めるにあたり、UI/UX に関するいくつかの課題があり、エンジニア主導でデザインシステムを構築することにしました。
本記事では、エンジニア主導でデザインシステムを構築することになった背景や、実際に取り組んだ内容について赤裸々にお話しします。
デザインシステムの導入を検討しているものの、最初の一歩を踏み出せずにいる・あるいは何から始めればよいかわからないチームにとって参考になれば幸いです。
そもそも RESZAIKO とは
RESZAIKO は飲食店の予約管理を DX する SaaS 事業で、現在3つのプロダクトを提供しています。
- 複数予約サイトの在庫を一括管理する「サイトコントローラー」
- 予約や顧客情報を管理する「予約台帳」
- 店舗独自の予約ページを提供する「Web予約」
現在は3つのプロダクトがありますが、元々はサイトコントローラーだけを提供しており、予約台帳とWeb予約は後発のプロダクトとしてリリースしました。
デザインシステム作成の背景
後発プロダクトの開発を進めていく中での課題
私たちはサイトコントローラーがある状態で、「予約台帳」と「Web予約」の開発に着手しました。 同時進行で開発することになったこの2つの後発プロダクトは、既存プロダクトであるサイトコントローラーの UI/UX を参考にして設計・開発を進めていましたが、さまざまな課題に直面しました。
課題① スピード感を持ってデザインを固めていくことが難しい
RESZAIKO にはサイトコントローラーの開発時から社内に専任のデザイナーがいなかったため、社外のデザイナーと週一回のミーティングでデザインを進めています。 限られた時間で多くの画面のデザイン調整を行うことは難しく、簡単な画面はエンジニアがデザインすることもありました。しかし、デザイナー以外デザインルールの把握ができていない状況であったため都度認識を合わせる必要があり、スピード感を持って進めていくことができませんでした。
課題② プロダクト間で UI/UX の統一感を生み出しづらい
RESZAIKO は飲食店のスタッフが3つのプロダクトを横断して使用することを想定しています。横断して使用しても違和感のない操作を提供するために UI/UX を合わせる必要がありましたが、デザインや操作感に関する知見を開発チーム間でうまく共有できず、差異が生じてしまうことがありました。
これを防ぐために、社外のデザイナーに Figma 上でコンポーネントの置き場を作成してもらいました。 しかし、各プロダクトで使用するための仕組み化ができず、操作感の統一も Figma 上で十分に表現されていなかったため、うまく運用することができていませんでした。
課題③ デザインのクオリティの担保が難しい
同一プロダクト内で同じコンポーネントを使用していても、余白の取り方やコンポーネントの組み合わせ方など細かい部分まで統一することは難しいです。実際に、既存箇所を参考にしてできた画面は、大枠は同じでも完璧には揃えられておらず、画面ごとに少しずつ違いが出てしまいました。 また、デザインに関するチェック基準がないため、チーム内でのレビューもある程度までしか確認できず、デザイナーのレビューも毎回細部までチェックすることができない状態でした。
このような課題を感じながら当初は開発を進めていましたが、リリースが近づくにつれ、デザインのスピード感がボトルネックになり始めました。 そこで、エンジニアの中から比較的 UI/UX にこだわりをもつ3人が集まり、RESZAIKO デザインシステムを作成することになりました。
デザインシステム構築の流れ
このようにしてデザインシステムを作ろうという話になったものの、メンバーがエンジニアだけだったため、デザインシステムに関する知見が不足していました。 そこで、知見を得るために「ちいさくはじめるデザインシステム」という本を読むことにしました。
この本は、SmartHR 社のデザインシステムの取り組みを例にデザインシステムの構築・運用の方法について書かれています。 私たちはこの本を参考に以下の流れで進めていきました。
コンセプト設定
デザインシステムは、流行っているからや、なんとなくデザインの課題が解決しそうという理由で作成しがちです。 しかし、「ちいさくはじめるデザインシステム」には前提として目的が必要であると記載されていたため、まずデザインシステムを作成する目的を改めて定めるところから始めることにしました。
デザインシステムには正解がなく、「デザイン」という何らかの目的を機能させるための「システム」であり、システムとして成立させるために何らかの目的が必要
集まったエンジニア同士で現在感じている課題点を挙げ、それらの解決には何が必要なのか、どのような状態が理想なのかを話し合いました。 その結果、以下のようなデザインシステムのコンセプトとして明文化しました。
デザインシステム コンセプト
- デザインと開発を効率化し、課題解決に集中できる環境を作り、リリースや改善サイクルを早くする
- デザインに一貫性をもたせ、ユーザービリティとアクセシビリティを向上させる（サービス単体）
- 3つのプロダクトを違和感のないユーザー体験を提供する
- 非デザイナーとデザイナーとのコミュニケーションとして使用し、共通認識を作る手段とする
- 非デザイナーが自走して簡易的なデザインを行えるようにする（デザインのよりどころにする）
構成決め
コンセプトを決めたところで、次にデザインシステムをどのような構成で実際に作成していくのかを検討しました。
構成を決めるにあたって、まずは他社のデザインシステムではどのような項目を採用しているのか調べました。 「ちいさくはじめるデザインシステム」にあるとおり、全てを網羅する必要はないため、調べたすべての項目を採用するのではなく、必要なものを取捨選択したり独自で項目を追加したりしました。
スタイルガイドには様々な種類がありますが、すべてを網羅している必要はありません。必要や目的・組織などに応じて柔軟に選ぶことができます。
私たちが特に参考にしたデザインシステムは、「SmartHR Design System」「Spindle」「デジタル庁 デザインシステム」の3つです。 「SmartHR Design System」はトークンやコンポーネントなど基本要素が網羅されているため、アウトライン作成の参考にしました。 「Spindle」は定義したコンポーネントの使用ルールがわかりやすくまとめられていたため、デザインルール作成の参考にしました。 また、今回作成するデザインシステムは元々コンポーネント置き場として使用していた Figma に定義したいと考えていたため、「デジタル庁 デザインシステム」のまとめ方を参考にして作成することにしました。
レビュー
デザインシステムのコンセプトと構成が決まったところで、他のプロダクトのデザインシステムを作成している方にレビューを依頼しようということになりました。 一休.com ではすでにデザインシステムが構築されているため、その作成に携わったデザイナーやエンジニアにレビューを依頼しました。
レビュー会では、定義するコンポーネントに対してどのように使うのかルールを記載した方が良いというアドバイスをいただきました。 これを受け、もともとルールは「デザインパターン」という名目でレイアウトに関することを定義する予定でしたが、これを「デザインルール」という名称に変更し、コンポーネントの使い方まで定義することにしました。 また当初は Figma 上でガイドラインの定義のみを行う予定でしたが、せっかくエンジニアが作成しているのだからライブラリまで作成したらどうかと提案をいただき、ライブラリの作成も試みることにしました。
そして、最終的に決定した構成がこちらです。
- 利用の手引き: デザインシステム構築の目的・利用方法
- デザインフィロソフィー: RESZAIKOプロダクトが大切にしていること
- デザイントークン: デザインシステムにおける最小単位のスタイル定義
- コンポーネント: UIを構成するための最小単位のパーツやアイコン
- デザインルール: デザイントークンやコンポーネントを使用する際のルール
- ライティングガイド: です/ます調や句読点の打ち方
- チェックリスト: デザインシステムに則っているか判断するための確認項目
この中でも、まずは最小限でリリースしてみようということになり、主要部分となる「デザイントークン」「コンポーネント」「デザインルール」の策定を初回リリースの目標として進めていくことにしました。
作成
レビューのフィードバックを受けたところで、デザインシステムの作成に着手しました。 本業の実装も並行で行っていて、あまり時間を確保できない中、Figma に各自がトークンやコンポーネントを追加し、週に1回3人で集まってお互いが作成したものにフィードバックを行うという流れで進めました。 また、3人の中で合意が取れたものは、社外のデザイナーに確認してもらい、エンジニアとデザイナーの双方が問題なく使用できるように整えていきました。
実際にできたデザインシステムの一部をお見せします。
デザイントークン
コンポーネント
デザインルール
β版リリース！
初回リリースとして掲げていた「デザイントークン」「コンポーネント」「デザインルール」の作成がある程度完了したところで、β版のデザインシステムとしてチームに展開しました。
現在は、実際に社外のデザイナーや開発メンバーに利用してもらい、元々の定義で不十分だった内容を拡充したり、新たなUIについては都度定義を追加したりしています。 デザインシステムを通じて、デザイナーとのコミュニケーションが円滑になっただけでなく、エンジニア同士でもデザインに関する会話ができるようになり、コミュニケーションツールとしても機能しはじめています。
まとめ
本記事では、RESZAIKO デザインシステムの導入背景からβ版リリースまでの流れをご紹介してきました。
エンジニア主導でデザインシステムを構築してみると、前提知識が不足していたことから調査しなければならない事柄が多く、最初の段階ではリリースまでたどり着けるのか不安に感じることもありました。 しかし、実装で必要になるコンポーネントやデザインルールが明らかなので、Figma への定義のフェーズに移ってからは特に迷うことなく進めることができました。 自分たちが実装時に必要としているものをダイレクトに反映することができることは、エンジニア主導で作成するメリットだと思います。
今回デザインシステムを導入したことにより、当初感じていた3つの課題は解決できたのかという点についてですが、解決できた部分もあればもう少し手を加える必要がある部分もあると感じています。
課題① スピード感を持ってデザインを固めていくことが難しい
デザイナーとエンジニアの共通言語ができたことにより、デザインに対する質問の精度も上がり、コミュニケーションが取りやすくなったため、これまでよりスピード感を持って開発が進められるようになってきました。
今後は、さらにデザインルールなどをアップデートし、デザインについて考えやすい環境を整えていければと思います。
課題② プロダクト間で UI/UX の統一感を生み出しづらい
各プロダクト間でコンポーネントを検討しデザインに反映することがなくなったため、導入前よりも統一感を出すことができるようになりました。 しかし、実装レベルでの統一がまだ十分ではありません。これを解決するために、UI ライブラリとしてパッケージ化し、RESZAIKO の各サービスに反映していければ、さらに課題の解決につながると考えています。
課題③ デザインのクオリティの担保が難しい
ルールが定まったことで、誰が作成しても差異が出ないようにする基盤は整えられましたが、チェック時の効率はまだ改善の余地があります。 より効率的に確認できるようにするため、チェックリストの作成など、デザインシステムの拡張も進めていきたいと考えています。
運用を始めたばかりの現段階では、まだ全体的に改善の余地が多く残っています。 これからさらにデザインシステムをアップデートし、利便性を高めていきたいと考えています。
おわりに
全く知見がない中で始めたデザインシステムの作成でしたが、ありがたいことにデザインシステムをオープンに運用している企業が多く、参考にできるものが豊富にありました。そのおかげで自分たちなりにアレンジしてなんとか形にし、プロトタイプまで持っていくことができました。 知見がない中で、またエンジニア主導でデザインシステムを導入しようとしている方々にとって、この経験が一つの手がかりになれば嬉しいです。
RESZAIKO デザインシステムはこれからもっとアップデートさせていくので、今後もブログで発信していきます！
一休ではともに良いサービスをつくっていける仲間を募集していますので、興味を持っていただけたら、ぜひ一休の採用サイトをご覧ください。
