Upgrade to Pro — share decks privately, control downloads, hide ads and more …

実践ゼロから作らないデザインシステム SaaS × デザインシステム × プロダクトデザイン ...

実践ゼロから作らないデザインシステム SaaS × デザインシステム × プロダクトデザイン / Practice: A design system that isn't created from scratch

2025/03/04
ScaleUP Design Meetup - スケールするデザインシステムの作り方と育て方
https://layerx.connpass.com/event/343472/

実践ゼロから作らないデザインシステム
SaaS × デザインシステム × プロダクトデザイン

髙橋 伸弥
プロダクトデザイナー

株式会社カミナシ

March 04, 2025
Tweet

More Decks by 株式会社カミナシ

Other Decks in Design

Transcript

  1. 実践ゼロから作らないデザインシステム 1. カミナシのデザインシステムの歴史と今 (ここは半年前入社である私の解釈が多く含まれ正確でない可能性があります) 2. toB SaaS × デザインシステム ×

    プロダクトデザイン 〜SaaS 企業で求められるデザインシステム/デザイナーの働き〜 3. デザインシステムを運用するにあたって向き合うべきこと 4. カミナシのデザインシステム今後拡張していこうとしているアイデア 5. できることなら皆さんと一緒に楽しく働きたい! 今回私がお伝えすること
  2. カミナシのデザインシステムの歴史と今 2024年8月から、新製品を3つドドッとリリース 1 2025年2月 2025年1月 2024年8月 カミナシ 従業員 カミナシ 教育

    カミナシ 設備保全 現場従業員への教育〜育成業務を 完結できる教育管理システム 設備保全業務を一気通貫で管理、 ダウンタイムを最小化するシステム 現場従業員と本部とのやりとりを 完結できるサービス
  3. カミナシのデザインシステムの歴史と今 • UI コンポーネント群の適用に問題があった ◦ 実装汎用性と事業即効性、求める機能周りのバランスが取りづらかった ◦ 技術的に複雑なことをやっている既存プロダクトチームにとって導入コストが高い ▪ 導入コストをプロダクトチームが払いにくい

    ◦ 新規事業が立ち上がるタイミングで実績が作れていなかった ▪ コンポーネントの網羅性 ▪ デザインシステム側実装の styled-component と Next.js との食い合わせ他 • その他様々な事情によりデザインシステム(UI コンポーネント)の用途がなくなり一旦凍 結 中止の理由※あくまで私の解釈
  4. カミナシのデザインシステムの歴史と今 顛末(このスライドはほぼ一瞬写すだけ) • 過去在籍した会社での経験/pj 期間 2-3ヶ月程度/3〜4名/toC向け • 事業部、将来的には全社で利用可能な共通コンポーネント類として設計、実装をしていた ◦ ランタイム動作パフォーマンス厨でもあるので、余計な仕様は排除をした軽量ライブラリ

    • 停止理由は組織の方針変更に伴い、別のミッションへの異動のため • プロダクトに適用しながらの動作確認を進めていたが、運用ができなくなるため、 パッケージ化されつつあったコンポーネント群は全て revert ◦ 「既存画面へのレスポンシブ対応分」や「ログイン画面のリニューアル」など、一部画面へ は適用(汎用ライブラリとしてはなく、特定ページ用コンポーネントとして実装) • バリアブルやコンポーネント、デザイン原則類が定義された Figma ファイルなどを残してきました 私もデザインシステムの構築経験→停止経験があります
  5. カミナシのデザインシステムの歴史と今 原則・ルールレイヤーを深化 ミッション・ビジョン・バリュー 会社が提供するプロダクトの 振る舞いや佇まいの基本原則 プロダクト単位で目指す課題解決戦略 個々の体験 ブランドガイドライン 共有 Figma

    ライブラリ (ローカルバリアブルやコンポーネント規定)、 共有デザインデータ プロダクトごとのデザイン原則・ ガイドライン・コンポーネント規定/実装 ユーザビリティ ガイドライン アクセシビリティ ガイドライン ライティング ガイドライン デザイン原則 全体 個別
  6. カミナシのデザインシステムの歴史と今 node パッケージ提供ではなくテーマを提供する形に import { ThemeProvider, createTheme } from "@mui/material/styles";

    const theme = createTheme({ palette: { primary: { main: "#4caf50", // 緑色 }, secondary: { main: "#9e9e9e", // 灰色 }, }, typography: { fontFamily: "serif", }, components: { MuiButton: { styleOverrides: { root: { borderRadius: "8px", // ボタンの角を丸く }, }, }, }, }); バリアブルを読み込む (createTheme() でテーマ化) バリアブルをデータ化 (JSON に書き出す) Figma の LocalVariable で デザイントークンを定義 <ThemeProvider theme={theme}> <h1>コンテンツ</h1> </ThemeProvider> バリアブルを実装に反映 (ThemeProvider で適用)
  7. カミナシのデザインシステムの歴史と今 異なるプロダクトでもそれなりに体験(操作感)が揃っている (ように見える) AntDesign を UI ライブラリに 使用しているプロダクト MUI を

    UI ライブラリに使用し ているプロダクト 技術環境が異なっていても適用しやすい抽象的なデザインシステムの形に
  8. カミナシのデザインシステムの歴史と今 • プロダクトごとに細かいズレがあり一貫性・網羅ができていない ◦ 規定されていない箇所 ◦ サイドバーの幅や背景色、アイコンのウェイト • ブランドカラーをそのまま UI

    カラーにしたことによる問題 ◦ ボタン色やリンク色をブランドカラーにしていたが、WCAG の基準とな るコントラスト比が保てていない • etc… 課題 デザイン標準化するぞい
  9. カミナシのデザインシステムの歴史と今 原則・ルールレイヤーの深化具合 ミッション・ビジョン・バリュー 会社が提供するプロダクトの 振る舞いや佇まいの基本原則 プロダクト単位で目指す課題解決戦略 個々の体験 ブランドガイドライン 共有 Figma

    ライブラリ (ローカルバリアブルやコンポーネント規定/実装)、 共有デザインデータ プロダクトごとのデザイン原則・ ガイドライン・コンポーネント規定/実装 ユーザビリティ ガイドライン アクセシビリティ ガイドライン ライティング ガイドライン デザイン原則 全体 個別 🔺 🔺 ✅ 🔺 ✅ ✅ 🔺
  10. カミナシのデザインシステムの歴史と今 原則・ルールレイヤーの深化具合 ミッション・ビジョン・バリュー 会社が提供するプロダクトの 振る舞いや佇まいの基本原則 プロダクト単位で目指す課題解決戦略 個々の体験 ブランドガイドライン 共有 Figma

    ライブラリ (ローカルバリアブルやコンポーネント規定/実装)、 共有デザインデータ プロダクトごとのデザイン原則・ ガイドライン・コンポーネント規定/実装 ユーザビリティ ガイドライン アクセシビリティ ガイドライン ライティング ガイドライン デザイン原則 全体 個別 🔺 🔺 ✅ 🔺 ✅ ✅ 🔺 プロダクトデザイナー みんなで取り組む
  11. toB SaaS × デザインシステム × プロダクトデザイン • to B 向けの

    SaaS を提供する会社 ◦ ノンデスクワーカー向け ◦ ホリゾンタル ◦ ドメイン知識が複雑 • シリーズ B 調達ぐらいのスタートアップ ◦ 早く作って早く価値検証し、企業価値 を伸ばしていかなければならない カミナシ社の事業性質 https://corp.kaminashi.jp/culture/mission5Q
  12. toB SaaS × デザインシステム × プロダクトデザイン SaaS の購買プロセスモデル(例) SaaSは「購入・導入」までのプロセスが長い 単なる認知度ではなく、「このSaaSを信頼できるか?」が決め手

    1. 認知(Awareness) → 課題に気づき、候補となるSaaSを調査 2. 検討(Consideration) → 各SaaSの機能・価格・評判を比較 3. 評価(Evaluation) → 無料トライアル・デモを試す 4. 購入・導入(Purchase) → 社内で意思決定し、契約 5. 継続利用(Retention & Expansion) → 長期的な関係性を構築 Awareness Consideration Evaluation Purchase Retention & Expansion
  13. toB SaaS × デザインシステム × プロダクトデザイン 衝動的感情よりも信頼性など、長期的感情かつ機能の充実度合いなどが大事 toB SaaS と

    toC 商品の購買行動の違い 購買決定の要因 機能・価格・信頼・導入のしやすさ 購買サイクル 継続利用の影響 認知度・広告・衝動 短期的(数秒〜数日) 買い替えしやすい 消費財 (toC) SaaS (toB) 長期的(数週間〜数ヶ月) 乗り換えコストが高い (データ移行・学習コスト)
  14. toB SaaS × デザインシステム × プロダクトデザイン SaaSでは 「知ってもらうこと(認知度)」よりも、「信頼されること(パーセ プション・エクイティ)」の方が重要 SaaS

    プロダクトのブランド戦略: 認知度よりも信頼度の方が重要 ブランド認知度 ブランド・ パーセプション ブランド・ エクイティ どれだけ知られているか 顧客がどう感じるか このサービスを使いたいと思うか ブランドの価値や信頼性 信頼できるブランドか 検討してもらえる状態になる 第一想起になっている 口コミなど ブランド認知部分が大きい 消費財 (toC) SaaS (toB) カスタマーサクセス できているか 品質・体験の良さ 使い続けてもらえるかが大きい
  15. toB SaaS × デザインシステム × プロダクトデザイン カミナシのデザイナーのしごと(デザイナーだけの仕事じゃないけど) 現場訪 問 ディスカバリ

    ヒア リン グ 観察 インサ イト言 語化 体験 整理 仮説 モック アップ 作成 実装のため のデザイン データ作成 商談 記録 製品説明 他チーム とのすり 合わせ デザインシステムは この辺りに効く VoC 分析 デリバリ
  16. toB SaaS × デザインシステム × プロダクトデザイン 重要 • 当然、顧客が快適に使えるもの •

    機能が豊富で、デザイナーや 開発チームの仕事の効率を上げてくれるもの そうでもない • 個性・意匠性 toB SaaS において、デザインシステムに求められるもの 利用者体験
  17. カミナシのデザインシステム今後拡張していこうとしているアイデア Material-UI の設定値内でやることにこだわってるわけではなく 現場の UX を重視して、変更・拡張・工夫することも 例:「文字やボタンのサイズが足りてない」  → input フィールドのラベルは小さく読みにくいため、別でラベルを置く

     → 標準バリアントで指定できるもの以上はカスタムバリアントで特別に大きく ※Material-UI では実現できない画面(やコンポーネント)は専用に作っています 汎用のもの (Material-UI) に完全に従うわけではない
  18. カミナシのデザインシステム今後拡張していこうとしているアイデア テーマ部分を深化させるイメージ 原則 デザイン思想 ルール スタイル、Figma のバリアブル 抽象 具体 テーマ

    テーマ実装データ、 Figma のコンポーネントバリアブル コンポーネント UIパーツの実装、node のパッケージ ちょうどいい デザイン システム
  19. カミナシのデザインシステム今後拡張していこうとしているアイデア • Material Design の見た目が当たっていない MUI コンポーネント群 ◦ @mui/base パッケージに含まれる

    ▪ <Button> → <ButtonUnstyled> に置き換える ◦ MUI の豊富な機能(イベント処理、アクセシビリティ、状態管理など) が使える ◦ Tailwind で見た目のカスタマイズがしやすい Tailwind を被せられる Unstyled コンポーネント(deprecated) <ButtonUnstyled type="submit" className="w-full bg-indigo-600 text-white py-2 px-4 …"> Sign in </ButtonUnstyled>
  20. カミナシのデザインシステム今後拡張していこうとしているアイデア • Material Design の見た目が当たっていない MUI コンポーネント群 ◦ @mui/base パッケージに含まれる

    ▪ <Button> → <ButtonUnstyled> に置き換える ◦ MUI の豊富な機能(イベント処理、アクセシビリティ、状態管理など) が使える ◦ Tailwind で見た目のカスタマイズがしやすい Tailwind を被せられる Unstyled コンポーネント(deprecated) <ButtonUnstyled type="submit" className="w-full bg-indigo-600 text-white py-2 px-4 …"> Sign in </ButtonUnstyled> 廃止 [Deprecated] → Base UI として独立
  21. カミナシのデザインシステム今後拡張していこうとしているアイデア • スタイルを持たない UI コンポーネントを提供するライブラリの総称 • Base UI (beta) ◦

    MUI と Radix 他の開発者が作り始めている ◦ Tailwind も使いやすい • しかし... ◦ 元々課題だったスタイルの管理、一貫性の維持は? ◦ API も MUI と互換性はないため移行コストががが ヘッドレス UI ライブラリ使っちゃう?
  22. カミナシのデザインシステム今後拡張していこうとしているアイデア • スタイルを持たない UI コンポーネントを提供するライブラリの総称 • Base UI (beta) ◦

    MUI と Radix 他の開発者が作り始めている ◦ Tailwind も使いやすい • しかし... ◦ 元々課題だったスタイルの管理、一貫性の維持は? ◦ API も MUI と互換性はないため移行コストががが ヘッドレス UI ライブラリ使っちゃう? 引き続きチームで 模索していきます
  23. 実践ゼロから作らないデザインシステム • カミナシでは現在『名付けられたデザインシステム』はありません • ホリゾンタル SaaS としてプロダクトの一貫性やユーザビリティ、アクセシビリティを担 保しながらも、重要な部分の仕事に集中するために、巨人の肩に乗っている ◦ デザイントークン、テーマなど改造して汎用的なところは従ったり、

    現場の声のヒアリングなどから Material-UI に完全に従わない部分もある • 作るデザインシステム自体の目的や方針は明確にしておいた方がいい ◦ オートクチュールでやる場合は運用するための覚悟が必要だよ • とはいえ将来的にここで言ってることは全然違うことをやってる可能性は全然あるよ まとめ
  24. Appendix Material-UI は Google 社の Material Design をベースに作られた UI ライブラリ。Google

    公式ではない、独 立したオープンソースプロジェクト。MUI は Material-UI を開発する会社の名前(Material-UI 共同開発者 Oliver Tassinari さん創業)。 React 環境で Material Design を使用できるようにと、Material Design ガイドラインの React 実装として 2014年に開発開始され、2018年に v1 がリリース。Material Design 自体は 2014 年 6 月に Google I/O conference で一貫性のある世界を作るため、ユーザーの操作を補助するガイドラインとして発表。様々な デバイスでアプリを触るときに統一感のある操作になることを期待。 MIT ライセンスで公開されており、無料で利用できる(Free Forever と記載)。実験的で先進的な機能を 持つコンポーネントは Material-UI X (MUI X) として分けている。プレミアム機能/MIT ライセンスでな く、無料では使えない。 Material Design? Material-UI ? MUI? Material-UI X?
  25. Appendix React 向け UI ライブラリの中でも人気 material-ui 94.9k stars 2 days

    ago 1.4M users ant-design 93.8k stars yesterday 696k users chakra-ui 38.6k stars 2 days ago 361k users daisyui 35.6k stars 2 weeks ago 367k users headlessui 26.8k stars 2 days ago 6.6k users react-bootstrap 22.5k stars 2 weeks ago 計測値なし GitHub のレポジトリから 2025.2 時点
  26. Appendix import { ThemeProvider, createTheme } from "@mui/material/styles"; const theme

    = createTheme({ palette: { primary: { main: "#4caf50", // 緑色 }, secondary: { main: "#9e9e9e", // 灰色 }, }, typography: { fontFamily: "serif", }, components: { MuiButton: { styleOverrides: { root: { borderRadius: "8px", // ボタンの角を丸く }, }, }, }, }); バリアブルを実装(Material-UI)に流し込む バリアブルを読み込む (createTheme() でテーマ化) バリアブルをデータ化 (JSON に書き出す) Figma の LocalVariable で デザイントークンを定義 <ThemeProvider theme={theme}> <h1>コンテンツ</h1> </ThemeProvider> バリアブルを実装に反映 (ThemeProvider で適用)