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

合意形成が加速する!プラットフォーム化するデザインプロセス

Akira Motomura
March 26, 2025
1

 合意形成が加速する!プラットフォーム化するデザインプロセス

本資料は、「合意形成が加速する!プラットフォーム化するデザインプロセス**」と題されたプレゼンテーションです。

デザインに関わる人が増え、職種も多様化する中で、サービスデザインの広がりと、現状をより好ましい状態に変えるデザイン活動の重要性を説いています。 Figmaを活用した参加型のデザインプロセスを紹介し、構想から実現、発表までの各段階におけるツール(FigJam, Figma Design, DevMode, Figma Slides)を示しています。

デザイン・イネーブルメントやデザインシステムの構築・運用、デザインとエンジニアリングの連携についても触れており、組織規模に応じたデザインシステムの段階や導入メリット、具体的な支援事例を紹介しています。 最終的に、デザインプロセスのプラットフォーム化による合意形成の加速を提唱しています。

Akira Motomura

March 26, 2025
Tweet

More Decks by Akira Motomura

Transcript

  1. 自己紹介 2 2025.03.18 Tue. Akira Motomura アメリカでコミュニケーションデザインを学び、 サンフランシスコのデザインファームにて、主と してIoTサービス・ソフトウェアサービス等のデ ザインプロジェクトに従事。

    帰国後、株式会社ゆめみにサービスデザイナーと して入社。現在は、クライアント企業のデジタル 戦略に関わるプロジェクト推進やデザイン人材育 成、組織導入支援を行うとともに、ゆめみのデザ イン事業の責任者を担当。 本村 章(モトムラ アキラ) 株式会社ゆめみ 執行役員 / シニア・サービスデザイナー HCD-Net認定人間中心設計専門家 立命館大学デザイン科学研究所客員研究員
  2. デザイナー という職種の多様化 UIデザイナー UXデザイナー グラフィックデザイナー ビジュアルデザイナー インタラクションデザイナー サービスデザイナー デジタルプロダクトデザイナー Webデザイナー

    UXリサーチャー アートディレクター クリエイティブディレクター プロダクトデザイナー デザインエンジニア BXデザイナー デザインストラテジスト ビジネスデザイナー デザインプログラムマネージャー and many more 2025.03.18 Tue. Akira Motomura Part 1 5
  3. サービスデザインの定義 から見える活動の広さ 2025.03.18 Tue. Akira Motomura Part 1 7 顧客体験のみならず、

    その体験を継続的に実現するための 組織と仕組みをデザインし、 新たな価値を創出する
  4. 組織のデザインプロセス 2025.03.18 Tue. Akira Motomura Part 2 15 組織全体で、最適化された 公式の仕組みを確立する

    自分がやりたいようにやる チーム単位で、 共同作業しやすい工夫をする Lv.3 現在の状態 より好ましい 状態
  5. 2025.03.18 Tue. Akira Motomura Part 3 23 デザイン・イネーブルメント 組織全体で、最適化された 公式の仕組みを確立する

    自分がやりたいようにやる チーム単位で、 共同作業しやすい工夫をする 現在の状態 より好ましい 状態
  6. 2025.03.18 Tue. Akira Motomura Part 3 24 Figmaが使えるようになる NEXT STAGEさま

    新サービスのUIデザイン制作と内製デザイナー育成を両軸で推進。ご担当者様・ゆめみ担当者による特別座談会 https://yumemi.co.jp/next-stage_designtalent_training
  7. 2025.03.18 Tue. Akira Motomura Part 3 26 実践を通じて、できるようになる NTT東日本さま デザインを組織の強みにする、UXUIスキル向上プログラムを提供。

    ご担当者様・ゆめみ担当者による特別座談会 https://yumemi.co.jp/ntthigashinihon_designtalent_training 池田泉州銀行さま バンキングアプリの改善を通したデザイン活用の推進・浸透を内製的アプローチで支援 https://yumemi.co.jp/sihd-bk_uxui_shaping_review
  8. 2025.03.18 Tue. Akira Motomura Part 3 27 デザイン・システム 組織全体で、最適化された 公式の仕組みを確立する

    自分がやりたいようにやる チーム単位で、 共同作業しやすい工夫をする 現在の状態 より好ましい 状態
  9. 2025.03.18 Tue. Akira Motomura Part 3 28 チーム・組織に「今」必要な デザイン・システムを見極める 最低限のデザインシステム

    表層のデザインシステム 統制化されたデザインシステム プラットフォームごとの デザインシステム クロスプラットフォームの デザインシステム 最低限必要なデザイン要素を体系化し、 1つの製品のUIを設計するデザインシステム 1つの製品の「表層」を統一的に設計する デザインシステム(実装とは直接連携していない) デザイナーとエンジニア共通化された デザインシステム デザインと実装 が連携し 、1つの製品を1つの プラッ トフォーム 上で統一的に設計するデザインシステム 複数の プラットフォームを1つのデザインシステムに よって実 現する 概要 費用:デザインチームの 作業効率化 デ リバリー :制作速度の 向上 費用:さ らなるデザインチームの 作業効率化 デ リバリー :さ らなる 制作速度の 向上 費用:開発・ メンテナンス コス トの 削減 デ リバリー :制作および開発速度の 向上 費用:さ らなる 開発・ メンテナンス コス トの 削減 デ リバリー :さ らなる 制作および開発速度の 向上 費用:プラットフォーム 単位の 開発コス トの 削減 デ リバリー :さ らなる 制作および開発速度の 向上 導入メリット
  10. 2025.03.18 Tue. Akira Motomura Part 3 29 標準的だが、 個社ごとに最適化したアプローチ Ph1

    調査・計画フェーズ zm 調x m 調査計画の策s ”m 既存アセットの調査・分• ‰m ステークホルダー洗い出し及びインタビュ… um ロードマップ策s m デザインシステムのスコープ定d ”m デザインシステムの公開方針の策s ‰m ロードマップの具体化 Ph2 構築フェーズ zm デザインシステムの基盤構³ m デザイン原則・用語集の策s ”m ツールの環境設s ‰m デザイントークンの設 ·m スタイルガイドラインの設 ¯m コンポーネントガイドラインの設 um デザインシステムの限定的な適¢ m 対象サービスへのデザインシステムの適¢ ”m デザインシステムのアップデー¸ ‰m 画面仕様書の策定(必要に応じ§ Ÿm 運用フローの整‚ m 運用体制の検Ë ”m 運用・改善フローの策定 Ph3 運用フェーズ zm ロードマップに基づく運用・改ç um デザインシステムの認知・浸透獲得
  11. 2025.03.18 Tue. Akira Motomura Part 3 30 デザインシステムの認知と理解を広げる 01 目標と効果を示す

    業界標準・競合他社と比較する デザインシステム適用/未適用のサービスを比較する デザインシステムの現在地や目標状態を示す 例: デザインシステムを活用している企業と自社の状態の比較 デザインシステムが適応されたサービスとそうではないサ ービスとで、どのような違いがあるか比較表示する 02 現状を認め、企業ごとの プロセスにフィットさせる 業界標準と比較して現状を否定するのではなく、 自社に合った形を模索し、関係者の具体的な課題が 解決されるようにプロセスを整える 例: 業界で 有名な 取り組みは 何を目的に、どのように 行われて いるのか ?自 分達の現状の リソースや 能力だとどのように 実現する ことがで きるか ? 03 社外に デザインリソース や 活動を 公開する 社 内の コミュニケーシ ョン だけではなく、ビ ジョンや目 指 す 基準を示した コンテン ツを 外部に 公開する 例: 外部に 公開されたデザインシステムの ウェブサイ ト デザインシステムに関するプ レス リリー ス デザインシステムに関する 登壇
  12. 2025.03.18 Tue. Akira Motomura Part 3 31 デザインシステムと運用体制 目的 規模

    更新頻度 利用者 外部公開 複数プロダクトへの適応 複数プロダクトへの適応 個別プロダクトへの適応 大 中 ー(プロジェクトごと) 多 中 ー(一回のみ作成) 自社のプロダクトチーム 外部パートナー 自社のプロダクトチーム 外部パートナー 外注チーム自身 必要 デザインシステムそのものがプロダクトであり、自社のプ ロダクト開発チームやプロダクト自体の利用者が常に最新 情報にアクセス・参照できる必要がある 投資の規模も大きい 基本的にはクローズドで問題ないが、認知が極端に低かっ たり、社外に向けてデザインに投資している姿勢を見せた りするため必要な場合がある 外部パートナーへの作業リソースとしても機能する 外注チームが、自 らの作業 効率化のため だけに利用するた め、 公開の必要 性がない 場合に よる 不要 内製チーム ハイブリットチーム 外 注チーム
  13. 2025.03.18 Tue. Akira Motomura Part 3 32 ハイブリットチームによる支援実績 島津製作所さま XDからFigmaへの移行を支援~より開発者体験の高いデザ

    インシステムの構築・内製化をサポート~ https://yumemi.co.jp/shimadzu_designsystem AdobeXD上で管理していた膨大な数のコンポーネントをFigmaへ移行するに あたって、Figmaでどんなことができるのか具体的なイメージもあまりない 状況で相談させていただきました。
 私達の利用状況や独自のルールなどを踏まえて、Figmaの機能を活用した作 成・管理方法を提案いただいたことで、利便性の高いデザインシステムを構 築できたと感じています。 JCBさま ゼロからデザインシステムを構築し、 成長し 続ける 仕組みづくり も。 ご担当者 様・ ゆめみ担当者による 特別座談 会 https://yumemi.co.jp/jcb_designsystem 通常、デザインシステムで は、 すでに プロダクトがある状 態からシステム化 をしていきますが、 私た ちは本当に ゼロベースで 共通認識を 持っていません でした 。 それな ら一番「JCBらし い」何かし らの 共通認識を アウトプットとしてま ず 作 って 語ろうとい うことで、 ビジ ュアルデザイン やUIコンポーネントのサン プルを 作成しました。 ゼロから 始めるからこ そ、 ビジ ュアルを 通して 共通認 識を 持てるよ うにしていったんです。 J Pデジタルさま 「デザインシステム 」が 40 万人の 従業員と 共に つくるDXの 起点に。 ご担当者 様・ ゆめみ担当者による 特別座談 会 https:// www.yumemi.co.jp/jp -digita l_designsystem もともと 日本郵政グルー プに はデザイ ナーがいなかったので、 「誰かが作 っ た ものを 受け入れるし かな い」という先入観があったと 思います。でも、 根 本的には「良くした い」という思いを 皆さんす ごく持っています。 何とかし たい けれど、ど うしたらいいかが わからないとい う感じだったのです 。 ゆめみさん はその 現状にも 向き 合って くださり、 さま ざまな 制約の 中でど う すれば価値を 最大化できるの かを 一緒に考えて くれました 。大き くて 複雑な 組織の 中に、 わかり やすさ や楽しさを 作ってい くことが 難しかったですが、 結果的に 今回の プロジ ェクト は間違いな く成功したと 言えると 思います。
  14. デザイン・エンジニアリング 2025.03.18 Tue. Akira Motomura Part 3 33 組織全体で、最適化された 公式の仕組みを確立する

    自分がやりたいようにやる チーム単位で、 共同作業しやすい工夫をする 現在の状態 より好ましい 状態
  15. デザイン・トークン 2025.03.18 Tue. Akira Motomura Part 3 34 value EA10AC

    100% token pink / 400 code background: ( ) var --pink-400, #EA10AC button
  16. デザイン・トークンの設計 2025.03.18 Tue. Akira Motomura Part 3 35 value EA10AC

    100% primitive tokens pink / 400 参照専用で デザインシステム内に存在する 全てのプロパティとバリュー値 直接デザインに 適応されることはない どのようにトークンがデザインに 適用されるべきか文脈を説明する 特的のコンポーネントに対して、 具体的に使用方法を説明する より規模が大きい デザインシステムで活用される プロジェクト、プロダクト、組織の規模に合わせて、柔軟に設計 semantic tokens surface / primary component-specific tokens button / primary-d efaul t b utton
  17. ルールとワークフロー作りは、 共同で行う 2025.03.18 Tue. Akira Motomura Part 3 36 デザイナー

    デザインとコードで共通しているものの認識を合わせる デザインファイル上で必要なもの、コードのみで必要なものは区別ができるようにする 定義したことは、言語化する エンジニア
  18. 2025.03.18 Tue. Akira Motomura Part 3 37 ? 合意 !

    ! ? ルールとワークフローは、 合意されてはじめて意味がある
  19. Thank you;) 2025.03.18 Tue. Akira Motomura 40 Website https:/ /designservicecanvas.yumemi.co.jp/

    X(Twitter) https:/ /x.com/akira_motomura note https:/ /note.com/akiramotomura LinkedIn https:/ /www.linkedin.com/in/akiramotomura/