こんにちは。エンタメ業界のDXを進めるブロックチェーンスタートアップ、Gaudiyで主にフロントを担当しているkodai（@r34b26）です。
弊社は、まだエンジニア10人、デザイナー2人ほどの小規模な開発チームですが、デザインシステムの構築に取り組んでいます。
デザインシステムは、一貫性のある品質の高いUIを継続してデリバリーする上ですぐれた仕組みですが、リソースの限られた環境ではなかなか着手しづらい面もあると思います。実際、デザインシステムを導入している会社では、専任の人やチームを組成して取り組まれていることが多い印象です。
そこで今回は、スモールな開発チームで、デザインシステム、特にコンポーネントライブラリを構築する上で工夫していることをご紹介してみたいと思います。
デザインシステムとは？
デザインシステムとは、一言でいうと「一貫性のある品質の高いUIを継続してデリバリーするための仕組み」です。デザインの原則や基準をまとめたドキュメントと、それを満たすデザイントークンやコンポーネントから構成されます。
複数人のデザイナー/エンジニアが、複数アプリケーションの実装を進めていくと、各々の実装の仕方によって "似て非なるもの" が繰り返し生成されてしまいがちです。
デザインシステムを適切に構築することで、繰り返し生成するコストやUIの実装コストを削減したり、表現のブレをなくしてユーザー体験の向上を実現することができます。
なぜ導入したのか？
これまで、弊社ではMaterial Designをデザインシステムに、Material UIをコンポーネントライブラリに使用してきました。
プロダクトの検証フェーズでは、このようなOSSに完全に依存し、ごく少人数で高速に実装できることはValueの高いことでした。ですが、新しいファン体験をより高品質に提供していくフェーズに変わり、開発チームの人数も増えてきたことで、従来のやり方ではValueを出せなくなってきました。
例えば、
- iOSはMaterial Designの表現やインタラクションの体験がなじまないこと
- HIGベースに話すデザイナーと、MUIしか認知していないエンジニアでの認識齟齬
- ありふれ"すぎた"体験のものしか作れないこと
- MUIを都度上書きして使うことによる、表現のブレの多発
- Figmaと実装のコンポーネントが結びついていないことによる、認識のずれ、再発明の多発
といった課題がありました。また弊社の特徴として、複数のコミュニティアプリを作っているため、レバレッジの効く仕組みづくりに早いうちから着手する必要があります。
このような課題を解決する手段のひとつとして、デザインシステムを導入する意思決定をしました。
Gaudiyのデザインシステム
現在は、デザイナー1人、エンジニア1人の体制で、少しずつデザインシステムを構築し始めています。
弊社のデザインシステムを簡単にご紹介すると、デザインはFigmaを、フロントの実装はReactを使用しており、そのコンポーネントの組み方と命名を完全に一致させています。この組み方が違うと、のちにFigmaで新しく組んたものが実装で反映できないことがあるので、はじめに認識を合わせておきます。
また、細かい色やマージンなどのデザイントークンと呼ばれるものは、Tailwindのconfigで管理して、こちらも命名と内容を合わせます。さらに、実装したものはStorybookにすべて登録してFigmaに存在する使用例を再現し、次回の実装からStorybookの例からコードをコピペできるように用意しています。
実際にどう作っているのか？
フェーズが変わり、デザインシステムの導入を始めたとはいえ、まだまだ少人数で高速に開発しなければならず、プロダクト開発以外にリソースを潤沢に割くことはできません。
そこで、限られたリソースでどのようにコンポーネントライブラリの構築を進めているか、その工夫を3つほどご紹介します。
1. プロダクト開発の一部に取り込む
すべてのデザインシステムを揃えるには、相当な労力がかかります。そこで弊社では、「プロダクト開発の一環で使用したいもの」かつ「その時点で複数機能/環境で使うような汎用性をもちたい要件であった時」に、新しいコンポーネントを作成するようにしています。
具体的には、必要とする実装者がオーナーとなり、まずは既存のデザインシステムに存在するかを確認します。そこでなければ、他のエンジニアやデザイナーにヒアリングしながら実装のやり方を考え、プロジェクトのチケットの一部として進行します。
こうすることで、チームへのデザインシステムへの意識を伝え広げるとともに、プロダクト開発の一部として、デザイナー/エンジニア以外への認識向上も含めながら進めていくことができます。
2. 完璧をめざさない
最初からベストプラクティスを追い求め、バグがなく、アクセシビリティも高く、汎用的なコンポーネントをめざしてしまうと、いくら時間があっても足りません。 また、実際に使うことでわかることもあるため、他エンジニアへのヒアリングやツールの導入で最低限の水準を担保しつつも、はじめから求めすぎないことが大切だと考えています。
実際に開発の一部として進めることで、自分たちのユースケースを反映することができるので、そこで実現できないものがあったときにはリファクタ、追加、修正することで改善の機会を逃さないようにしています。
3. OSSの力を借りる
ModalやTransitionなど、若干の実装コストがかかるが車輪の再発明になってしまうようなものに関しては、OSSを使用するなどして、直近のコストを積極的に下げるようにしています。
その使い方に関しては、MUI v5のunstyledやheaedlessui のようなものを使ってunstyledな層は任せ、styledな層を自分で実装する。もしくはstyledな層も任せるが、それらを組み合わせたutility的な層を自分で実装するなど、ケースによって柔軟に対応できるように工夫しています。
運用を始めてみての効果と課題
実際にデザインシステムを導入してみて、UI実装をするときの変化を感じています。
例えば、デザイナーと「デザインシステムに定義すべきか」を話したり、他のエンジニアに「どう使用すべきか」を尋ねたり、また「実現できなかったときはどのように調整すべきか」といった会話もチームでなされています。
デザイントークンとコンポーネントライブラリ自体の向上が少しずつ進んでいますが、 それ以上に、デザイナーとエンジニア間でのコラボレーション機会が増え、お互いにヒアリングし合うべき内容を伝播できていることに一番効果を感じています。
一方で、
- プロジェクトでスピードが重視される期間に、導入/改善が挟みづらい
- 初回の実装や相談相手が、まだまだ特定の個人に偏っている
- デザインシステムの実装が絡まないパートである、デザイン原則などのドキュメント整備やその周知が進まない
といった課題もあり、この辺りは今後改善していきたいです。
まとめ
今回は、弊社のデザインシステムに関する取り組みをご紹介しました。リソースがない中でも工夫すれば始められないことはないので、初期フェーズからデザインに投資したいと思っているチームの参考になると嬉しいです。
整備しきるまでは長い道のりですが、コラボや会話促進といった+αの価値も出せているので、地道に改善していきたいと思います。 デザインシステムの相談相手いないのでほしい。。。。
Gaudiyの技術選定は、こちらの記事をご参考ください〜
