Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

実践ゼロから作らないデザインシステム 髙橋伸弥 プロダクトデザイナー（2024.8 カミナシ入社） 早く帰ってモンハンやりたい こんにちは！ @feb19

Slide 3

Slide 3 text

実践ゼロから作らないデザインシステム 今回のイベント趣旨

Slide 4

Slide 4 text

実践ゼロから作らないデザインシステム 1. カミナシのデザインシステムの歴史と今 (ここは半年前入社である私の解釈が多く含まれ正確でない可能性があります) 2. toB SaaS × デザインシステム × プロダクトデザイン 〜SaaS 企業で求められるデザインシステム／デザイナーの働き〜 3. デザインシステムを運用するにあたって向き合うべきこと 4. カミナシのデザインシステム今後拡張していこうとしているアイデア 5. できることなら皆さんと一緒に楽しく働きたい！ 今回私がお伝えすること

Slide 5

Slide 5 text

カミナシのデザインシステムの 歴史と今

Slide 6

Slide 6 text

カミナシのデザインシステムの歴史と今 2024年8月から、新製品を3つドドッとリリース 1 2025年2月 2025年1月 2024年8月 カミナシ 従業員 カミナシ 教育 カミナシ 設備保全 現場従業員への教育〜育成業務を 完結できる教育管理システム 設備保全業務を一気通貫で管理、 ダウンタイムを最小化するシステム 現場従業員と本部とのやりとりを 完結できるサービス

Slide 7

Slide 7 text

カミナシのデザインシステムの歴史と今 別々のメンバー・チームで別々のプロダクトを運用しています

Slide 8

Slide 8 text

カミナシのデザインシステムの歴史と今 別々のメンバー・チームで別々のプロダクトを運用しています ● ユーザーは複数のプロダクトを操作することがある ● 別々のチーム ○ PM/開発メンバー、担当デザイナーはそれぞれのプロダクトで独立 ○ 違う時間軸で開発・運用されている ○ しかしプロダクト間での操作体験の一貫性は重要 ● 何らかの仕組みを用いて、全プロダクトで違和感のない体験を設計できるよ うにしたい

Slide 9

Slide 9 text

カミナシのデザインシステムの歴史と今 正確にはデザインによる競合優位性を獲得すべく経営レベルで推進、そしてプロダクトが増えるから必要だよねという認識 デザインシステムを整備しよう！となった 原則 デザイン思想 ルール スタイル、Figma のバリアブル コンポーネント UIパーツの実装、node のパッケージ 抽象 具体 カミナシの デザイン システム

Slide 10

Slide 10 text

カミナシのデザインシステムの歴史と今 しかし、デザインシステムの適用・プロジェクト中止 原則 デザイン思想 ルール スタイル、Figma のバリアブル コンポーネント UIパーツの実装、node のパッケージ 抽象 具体 カミナシの デザイン システム

Slide 11

Slide 11 text

カミナシのデザインシステムの歴史と今 ● UI コンポーネント群の適用に問題があった ○ 実装汎用性と事業即効性、求める機能周りのバランスが取りづらかった ○ 技術的に複雑なことをやっている既存プロダクトチームにとって導入コストが高い ■ 導入コストをプロダクトチームが払いにくい ○ 新規事業が立ち上がるタイミングで実績が作れていなかった ■ コンポーネントの網羅性 ■ デザインシステム側実装の styled-component と Next.js との食い合わせ他 ● その他様々な事情によりデザインシステム（UI コンポーネント）の用途がなくなり一旦凍 結 中止の理由※あくまで私の解釈

Slide 12

Slide 12 text

カミナシのデザインシステムの歴史と今 顛末（このスライドはほぼ一瞬写すだけ） ● 過去在籍した会社での経験／pj 期間 2-3ヶ月程度／3〜4名／toC向け ● 事業部、将来的には全社で利用可能な共通コンポーネント類として設計、実装をしていた ○ ランタイム動作パフォーマンス厨でもあるので、余計な仕様は排除をした軽量ライブラリ ● 停止理由は組織の方針変更に伴い、別のミッションへの異動のため ● プロダクトに適用しながらの動作確認を進めていたが、運用ができなくなるため、 パッケージ化されつつあったコンポーネント群は全て revert ○ 「既存画面へのレスポンシブ対応分」や「ログイン画面のリニューアル」など、一部画面へ は適用（汎用ライブラリとしてはなく、特定ページ用コンポーネントとして実装） ● バリアブルやコンポーネント、デザイン原則類が定義された Figma ファイルなどを残してきました 私もデザインシステムの構築経験→停止経験があります

Slide 13

Slide 13 text

カミナシのデザインシステムの歴史と今 この付き合い方はデザインシステム未亡人である私が思うに かなり理にかなっていると認識 カミナシはデザインシステムとの付き合い方が変わった デザインシステム未亡人の髙橋さん 理にかなっているわね

Slide 14

Slide 14 text

カミナシのデザインシステムの歴史と今 デザインシステムプロジェクトの時に検討された資産を深化→拠り所 拠り所を深化 原則 デザイン思想 ルール スタイル、Figma のバリアブル コンポーネント UIパーツの実装、node のパッケージ 抽象 具体 こちらに 集中

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

カミナシのデザインシステムの歴史と今 ブランドガイドライン (これは昔からあるやつ) https://corp.kaminashi.jp/presskit

Slide 17

Slide 17 text

カミナシのデザインシステムの歴史と今 カラーに関するバリアブル UI カラー化、Figma で管理 (デザインシステムの作成時に完成) リンクカラー (ex. link/default) カラーパレット (ex. blue/500) 意味付けされたカラー (ex. primary/main) 汎用 特化

Slide 18

Slide 18 text

カミナシのデザインシステムの歴史と今 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 で適用)

Slide 19

Slide 19 text

カミナシのデザインシステムの歴史と今 ● 実装で使用する「Material-UI (MUI)」をベースにデザインする ように ● デザイン原則的に衝突する場合 はデザイン原則を優先しカスタ マイズ コンポーネントは実装側の UI ライブラリを使う https://mui.com/material-ui/

Slide 20

Slide 20 text

カミナシのデザインシステムの歴史と今 共通ライブラリ化した Figma を使ってデザイン

Slide 21

Slide 21 text

カミナシのデザインシステムの歴史と今 異なるプロダクトでもそれなりに体験(操作感)が揃っている (ように見える) AntDesign を UI ライブラリに 使用しているプロダクト MUI を UI ライブラリに使用し ているプロダクト 技術環境が異なっていても適用しやすい抽象的なデザインシステムの形に

Slide 22

Slide 22 text

カミナシのデザインシステムの歴史と今 ● プロダクトごとに細かいズレがあり一貫性・網羅ができていない ○ 規定されていない箇所 ○ サイドバーの幅や背景色、アイコンのウェイト ● ブランドカラーをそのまま UI カラーにしたことによる問題 ○ ボタン色やリンク色をブランドカラーにしていたが、WCAG の基準とな るコントラスト比が保てていない ● etc… 課題 デザイン標準化するぞい

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

toB SaaS × デザインシステム × プロダクトデザイン

Slide 26

Slide 26 text

toB SaaS × デザインシステム × プロダクトデザイン ● to B 向けの SaaS を提供する会社 ○ ノンデスクワーカー向け ○ ホリゾンタル ○ ドメイン知識が複雑 ● シリーズ B 調達ぐらいのスタートアップ ○ 早く作って早く価値検証し、企業価値 を伸ばしていかなければならない カミナシ社の事業性質 https://corp.kaminashi.jp/culture/mission5Q

Slide 27

Slide 27 text

toB SaaS × デザインシステム × プロダクトデザイン SaaS の購買プロセスモデル（例） SaaSは「購入・導入」までのプロセスが長い 単なる認知度ではなく、「このSaaSを信頼できるか？」が決め手 1. 認知（Awareness） → 課題に気づき、候補となるSaaSを調査 2. 検討（Consideration） → 各SaaSの機能・価格・評判を比較 3. 評価（Evaluation） → 無料トライアル・デモを試す 4. 購入・導入（Purchase） → 社内で意思決定し、契約 5. 継続利用（Retention & Expansion） → 長期的な関係性を構築 Awareness Consideration Evaluation Purchase Retention & Expansion

Slide 28

Slide 28 text

toB SaaS × デザインシステム × プロダクトデザイン 衝動的感情よりも信頼性など、長期的感情かつ機能の充実度合いなどが大事 toB SaaS と toC 商品の購買行動の違い 購買決定の要因 機能・価格・信頼・導入のしやすさ 購買サイクル 継続利用の影響 認知度・広告・衝動 短期的（数秒〜数日） 買い替えしやすい 消費財 (toC) SaaS (toB) 長期的（数週間〜数ヶ月） 乗り換えコストが高い （データ移行・学習コスト）

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

toB SaaS × デザインシステム × プロダクトデザイン 「我々は使いやすいシステムを作っていただくという期待をしているわけではな く、より良い仕事を実現するコンサルティングを期待している」 とあるお客様の声 グラフィックや UI の操作性などプロダクトディティールのデザイン もっと効率的で、品質良く仕事ができるようになるワークフローのデザイン

Slide 31

Slide 31 text

toB SaaS × デザインシステム × プロダクトデザイン カミナシのデザイナーのしごと（デザイナーだけの仕事じゃないけど） 現場訪 問 ディスカバリ ヒア リン グ 観察 インサ イト言 語化 体験 整理 仮説 モック アップ 作成 実装のため のデザイン データ作成 商談 記録 製品説明 他チーム とのすり 合わせ デザインシステムは この辺りに効く VoC 分析 デリバリ

Slide 32

Slide 32 text

toB SaaS × デザインシステム × プロダクトデザイン 重要 ● 当然、顧客が快適に使えるもの ● 機能が豊富で、デザイナーや 開発チームの仕事の効率を上げてくれるもの そうでもない ● 個性・意匠性 toB SaaS において、デザインシステムに求められるもの 利用者体験

Slide 33

Slide 33 text

デザインシステムを運用するにあたって 向き合うべきこと

Slide 34

Slide 34 text

デザインシステムを運用するにあたって向き合うべきこと 利用者体験を重視し、汎用的な UI ライブラリ／デザインシステムであるオープン ソースプロジェクトの「Material-UI」に乗っかるという意思決定をした ● ここがプロダクトデザインや Web/UI デザインをやっているとなかなか決定 できない勇気ある決断だと思った 世界的に多くの利用者が様々なサービスで触れてきている 巨人の肩に乗るという発想

Slide 35

Slide 35 text

デザインシステムを運用するにあたって向き合うべきこと デザインシステムはプロダクトを作るためのプロダクト その node パッケージレポジトリの運用は自社のチームで運用できるものか 依存パッケージの脆弱性・セキュリティ対策などメンテナンスは可能か 自社の既存プロダクト／新規プロダクトに適用するためのコストが払えるか そのデザインシステムを保守するチームの成果指標は評価可能か 運用に向きあう

Slide 36

Slide 36 text

デザインシステムを運用するにあたって向き合うべきこと ● 「君の組織もデザインシステムを作ろう」というデザイナー同士やデザイン ツール SaaS のキャンペーンを疑え ● あるツールが中心にありそこで構築するものだとみんな思っている ○ 作られたデザインシステムは組織から剥がしにくい ■ デザインツールが Churn されづらい ■ デザインシステムを利用するユーザー数のアップセル ○ デザインツールの売上を世界中のデザインシステムが支えている デザインのトレンドを疑う

Slide 37

Slide 37 text

デザインシステムを運用するにあたって向き合うべきこと 利用者は自社の特注デザインシステムを使いこなせるようになっても キャリアのプラスにはあまりならない 汎用的なデザインシステムを使えるようになった方が 個人や将来のチャレンジで役に立つことも 似たような特注システムを再発明するとかはできるかもだが・・・ 利用者に向きあう

Slide 38

Slide 38 text

デザインシステムを運用するにあたって向き合うべきこと LLM も汎用的なものならば知っている AI エージェントを使用しない開発は 今、割とあり得なくなってきていませんか？ AI (LLM) に向き合う

Slide 39

Slide 39 text

MUI を使ってユーザー一覧 画面を作ってください 動画が表示できない時用のスライド 1/2

Slide 40

Slide 40 text

ユーザー情報を編集できる ようにしてください 動画が表示できない時用のスライド 2/2

Slide 41

Slide 41 text

カミナシのデザインシステム 今後拡張していこうとしているアイデア

Slide 42

Slide 42 text

カミナシのデザインシステム今後拡張していこうとしているアイデア Material-UI の設定値内でやることにこだわってるわけではなく 現場の UX を重視して、変更・拡張・工夫することも 例：「文字やボタンのサイズが足りてない」 　→ input フィールドのラベルは小さく読みにくいため、別でラベルを置く 　→ 標準バリアントで指定できるもの以上はカスタムバリアントで特別に大きく ※Material-UI では実現できない画面（やコンポーネント）は専用に作っています 汎用のもの (Material-UI) に完全に従うわけではない

Slide 43

Slide 43 text

カミナシのデザインシステム今後拡張していこうとしているアイデア テーマ部分を深化させるイメージ 原則 デザイン思想 ルール スタイル、Figma のバリアブル 抽象 具体 コンポーネント UIパーツの実装、node のパッケージ

Slide 44

Slide 44 text

カミナシのデザインシステム今後拡張していこうとしているアイデア テーマ部分を深化させるイメージ 原則 デザイン思想 ルール スタイル、Figma のバリアブル 抽象 具体 テーマ テーマ実装データ、 Figma のコンポーネントバリアブル コンポーネント UIパーツの実装、node のパッケージ ちょうどいい デザイン システム

Slide 45

Slide 45 text

カミナシのデザインシステム今後拡張していこうとしているアイデア ● Material Design の見た目が当たっていない MUI コンポーネント群 ○ @mui/base パッケージに含まれる ■ → に置き換える ○ MUI の豊富な機能（イベント処理、アクセシビリティ、状態管理など） が使える ○ Tailwind で見た目のカスタマイズがしやすい Tailwind を被せられる Unstyled コンポーネント(deprecated) Sign in

Slide 46

Slide 46 text

カミナシのデザインシステム今後拡張していこうとしているアイデア ● Material Design の見た目が当たっていない MUI コンポーネント群 ○ @mui/base パッケージに含まれる ■ → に置き換える ○ MUI の豊富な機能（イベント処理、アクセシビリティ、状態管理など） が使える ○ Tailwind で見た目のカスタマイズがしやすい Tailwind を被せられる Unstyled コンポーネント(deprecated) Sign in 廃止 [Deprecated] → Base UI として独立

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

実践ゼロから作らないデザインシステム ● カミナシでは現在『名付けられたデザインシステム』はありません ● ホリゾンタル SaaS としてプロダクトの一貫性やユーザビリティ、アクセシビリティを担 保しながらも、重要な部分の仕事に集中するために、巨人の肩に乗っている ○ デザイントークン、テーマなど改造して汎用的なところは従ったり、 現場の声のヒアリングなどから Material-UI に完全に従わない部分もある ● 作るデザインシステム自体の目的や方針は明確にしておいた方がいい ○ オートクチュールでやる場合は運用するための覚悟が必要だよ ● とはいえ将来的にここで言ってることは全然違うことをやってる可能性は全然あるよ まとめ

Slide 51

Slide 51 text

実践ゼロから作らないデザインシステム 他の UI ライブラリ (AntDesign や shadcn/ui) での適用方法もまとめています 元ネタはこちら https://note.com/feb19/n/n668aadedb0cc

Slide 52

Slide 52 text

最後に

Slide 53

Slide 53 text

絶賛採用中です！ ● カミナシの真なる仕事はノンデスクワーカーの才能を解き放つこと ● デザインシステムや様々な製造や現場について深く考えながらプロダクトを 作る仕事です ノンデスクワーカーの活躍を支えるプロダクト作りませんか 今回の内容で怖がられていないか 心配な髙橋さん 気軽に話しましょう！

Slide 54

Slide 54 text

株式会社カミナシ https://kaminashi.jp

Slide 55

Slide 55 text

Appendix

Slide 56

Slide 56 text

Appendix Google Material Design をベースに有志が作成しているオープンソースの UI ライ ブラリ。多彩なフォームが提供できたり、ユーザビリティやアクセシビリティに 配慮されたWebサイトを作ることができます。 Material-UI https://mui.com/material-ui/

Slide 57

Slide 57 text

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?

Slide 58

Slide 58 text

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 時点

Slide 59

Slide 59 text

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 で適用)

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

株式会社カミナシ https://kaminashi.jp