Case Study 01

BtoB SaaSのデザインシステム/設計プロセス

デザインシステムの構成要素と運用フローを整理した図

オンライン教育・HR領域のBtoB SaaSと、個人開発のECサービスで向き合った、UI構造・命名・状態定義・実装接続の整理に関するケーススタディです。

1. 状況

BtoB SaaS(オンライン教育・HR領域、LMS/HRプロダクト)でのデザイン業務において、UI改善や機能追加を重ねる中で、デザイン判断やコンポーネントの扱いが属人化しやすい状態にあった。

特にデザイナーとエンジニアの間でUIパーツの呼び方や状態定義が揃っておらず、ハンドオフのたびに認識合わせが発生していた。その後、個人開発プロダクト(ECサービス)でも、Figma上の設計と実装の分断という共通の課題に直面し、再現性を検証する機会があった。

2. 制約

前職フェーズでは、デザイナーが利用できるAIツールが限定されており、使用可能だったのは汎用の対話AIのみだった。大規模な作り直しは現実的でなく、既存の運用に馴染む形での整理が求められた。

個人開発フェーズでは、デザイントークンがFigmaとコードで二重管理になりがちで、変更のたびに手動同期のコストと実装品質のばらつきという制約があった。

3. 判断

  • AIを「作業の代替」ではなく、UI構造を客観的に分解し、命名・分類の抜け漏れを確認する壁打ち相手として位置づけた。
  • 命名規則はゼロから独自体系を作らず、一般的な設計思想を参考にしつつ、既存プロダクトで運用しやすい粒度を優先した。
  • デザイントークンはコード生成の起点にするのではなく、CSS設定側に反映し、コンポーネントは定義済みトークンを参照する構造にした。
  • AIコーディングツールは「コードを書かせる」ためでなく、デザイナー自身が実装ファイルにアクセスし意図を反映するための実行環境として使う、と役割を定義した。
Figmaからデザイントークンを経て実装に至るフロー図

4. 実施

  • Figma上のコンポーネント構造を確認し、UIパーツの役割・利用箇所・状態パターンを分解。
  • 共通要素と画面固有要素を分類し、命名規則・バリアント・Propsとして整理、ドキュメントに転記。
  • デザイン方針・トーンを言語化したドキュメントを作成し、実装時の前提として参照できる状態に整備。
  • Figmaでの方針整理からドキュメント記載、実装、ローカル確認、UX視点でのフィードバック、再実装までのサイクルを構築。
  • 主要コンポーネントをカタログ化し、画面単位でなくコンポーネント単位で状態・再利用性を確認できる仕組みを構築。

5. 結果

前職フェーズ: コンポーネント命名規則を整理し、ハンドオフ時の認識差を削減。後任デザイナーが参照できるドキュメント基盤を構築し、状態定義の抜け漏れを防ぐ仕組みを整備することで、デザイン判断の属人化を解消した。

個人開発フェーズ: Figmaのルールを実装に反映し、再現性を向上。コンポーネントカタログ化により状態確認と再利用のしやすさを改善した。AIとの協業ワークフローを確立し、この仕組みは別プロダクトのUI実装にも展開している。

トップへ戻る