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

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

特にデザイナーとエンジニアの間でUIパーツの呼び方や状態定義が揃っておらず、ハンドオフのたびに認識合わせが発生していた。

その後、EC業務を題材とした個人開発プロジェクトでも、実運用から抽出した業務上の課題をもとに、商品・在庫管理まわりのUI設計と、Figma上の設計と実装の分断という共通課題に直面した。現在は、デザインシステム／コンポーネント整理から、React / React Ariaを用いた実装への展開を進めている。

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

個人開発フェーズでは、デザイントークンがFigmaとコードで二重管理になりがちで、変更のたびに手動同期のコストと実装品質のばらつきという制約があった。加えて、Figma上の設計だけで完結させず、実際の実装環境で確認・修正できる循環をつくる必要があった。

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

前職フェーズ:

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

個人開発フェーズ（進行中）:

• ECの実運用から業務上の課題を抽出し、商品・在庫管理に関するUIの情報設計を進めている。
• デザインシステム／コンポーネントを整理し、Figma上の設計にとどまらず実装環境での確認・修正へ展開している。
• React / React Ariaを用いたコンポーネント実装を進め、設計意図がコード上で再現できるかを検証している。
• 従来の Figma → ドキュメント → 実装 → ローカル確認 → UXフィードバック → 再実装 の流れを維持しつつ、業務課題から実装までの接続を確認している。

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

個人開発フェーズ: Figmaのルールを実装に反映し、再現性を向上。コンポーネントカタログ化により状態確認と再利用のしやすさを改善した。現在は、実運用由来の業務課題を起点に、情報設計からコンポーネント実装までの接続を検証している段階にある。