Researchを扱う
大量の声やデータを整理し、仮説と論点を発見する。
Experience System — 基礎研究 · v0.1
Experience
System
最高の顧客体験を、個人の経験やセンスではなく、組織が繰り返し生み出せる仕組みへ。
※本稿で紹介する「Experience System」は、鳥越康平が提唱し、現在研究・実践を進めている考え方です。現時点の中心仮説と構造を共有する研究ノートであり、業界標準や完成済みのメソッドを主張するものではありません。
01 / The age of accelerated making
AIによって、「作れること」のコストが下がっている
Researchの整理からUI generation、Prototype、Code、Design QAまで。AIは、プロダクト開発の実行部分を急速に高速化しています。
UIを生成する
要件から複数の画面案、Content、Interactionを短時間で展開する。
PrototypeとCodeをつなぐ
設計と実装の往復を減らし、検証できるものを早くつくる。
ReviewとQAを支える
ルールとの不整合やEdge Caseを、人間とともに探索する。
作る速度が上がるほど、
「何を、なぜ作るか」という判断の品質が差になる。
「何を、なぜ作るか」という判断の品質が差になる。
02 / Machine-readable design knowledge
AIにも、Design Knowledgeが必要になる
AIにブランド、Design System、ComponentのUsage、Visual / Interaction rules、Accessibility、Constraintsを理解させるために、design.mdのような機械可読なDesign Knowledgeを持たせるアプローチが重要になり、広がりつつあります。
これは非常に重要です。AIが毎回ばらばらなUIをつくる問題を減らし、チームが蓄積してきた設計ルールを、人間とAIが同じ前提として参照できるようにします。
Without shared knowledgeAIが毎回、推測から始める
ブランドやComponentの使い方が出力ごとに揺れる。
With design knowledge共通の表現ルールから始める
UIの一貫性、操作性、Accessibilityを強く統制できる。
Research in progress
design.mdという名称や構成自体を業界標準として主張するものではありません。ここでは、AIが参照できる形でDesign Knowledgeを構造化する実践の総称として扱っています。
03 / The missing decision layer
正しいUIルールだけでは、最高のExperienceは決まらない
Design SystemとDesign Knowledgeは、UIの一貫性、操作性、Accessibility、Visual / Interaction rulesを強く統制できます。一方で、「この状況の人に、どんな望ましい体験を生み出すべきか」という上位判断までは、十分に表現しにくい。
たとえば、Buttonの色、Spacing、Component、Interaction、Accessibility、文言ルールを完全に守っていても、初めて100万円を振り込む人が、不安な状態から内容を十分に理解し、確信を持って安心して完了できるかは自動的には決まりません。
Design System only
ルールは同じでも、体験判断は担当者ごとに始まる
- 何を先に伝えるかが揺れる
- 不安への配慮が画面ごとに変わる
- 完了の定義がProduct間で揃わない
With Experience Knowledge
共通の体験原則から、各表現を設計する
- 目指すHuman Stateを共有する
- 必要な働きかけを再利用する
- Web、App、対人サービスを横断する
従来、この判断は優秀なUX Designer、Design Lead、Product責任者の頭の中にありました。誰のためか。今どんな状況か。何を理解してほしいか。どんな状態へ変化させるか。何をあえてしないか。組織が大きくなるほど、この暗黙知を再現できず、Productや担当者ごとにUX品質がぶれます。
DESIGN SYSTEMは表現の一貫性を支える。
EXPERIENCE SYSTEMは、その表現を生み出す判断の一貫性を支える。
EXPERIENCE SYSTEMは、その表現を生み出す判断の一貫性を支える。
04 / The idea of experience.md
「どんなExperienceを生み出すか」を、読めるKnowledgeにする
experience.mdは、企業・ブランド・プロダクトが目指す体験、Human Stateの変化、Experience PrinciplesやPatternsを、人間とAIの双方が参照できるKnowledgeとして構造化する発想です。
ファイル名そのものが目的ではありません。重要なのは、体験に関する上位判断を、個人のセンスから切り離すのではなく、根拠を失わずに共有・検証・更新できる状態へ移すことです。
Business / Product VisionWHY / WHO
Experience System / experience.mdWHAT EXPERIENCE SHOULD HAPPEN?
Product / Scenario / Requirements ContextFOR WHOM, WHEN, UNDER WHAT CONDITIONS?
Design System / design.mdHOW SHOULD IT BE EXPRESSED?
AI AgentGENERATE / REVIEW / DISCOVER / QA
UI / Content / Interaction / Prototype / ProductCHANNEL-SPECIFIC EXPRESSION
Minimum knowledge set / working model
優れた体験を、考え、つくり、検証するためのMDファイル一覧
一つの巨大なMarkdownにすべてを詰め込まず、判断の責務ごとにKnowledgeを分けます。これによりAIも人間も、「体験の方針」「今回の文脈」「満たす条件」「表現方法」「検証結果」を混同せずに参照できます。
experience.mdどんな体験を生み出すか共有するExperience Principles、目指すHuman State、Semantic Experiences、再利用可能なPatterns、避けるべき体験を定義する。
product.mdなぜ、このProductが存在するかBusiness / Product Vision、対象ユーザー、提供価値、成功の定義、Product固有の制約を記述する。
scenario.md誰が、どんな状況で使うかUser、Before Human State、Goal、利用環境、頻度、緊急性、既知の不安やEdge Caseを具体化する。
requirements.md何を満たさなければならないか機能、情報、業務、法務、Accessibility、Privacy、安全性、受入条件を明確にする。
design.mdどう表現し、どう振る舞わせるか情報設計、Content、Interaction、Layout、Component usageとDesign Systemへの接続を定義する。
validation.md体験は本当に生まれたか検証方法、Success / Harm signals、観察結果、未解決点、Libraryへ戻す学びを記録する。
experience.md→product.md→scenario.md→requirements.md→design.md→Prototype / Product→validation.md↺ Experience Libraryへ
上流のファイルほど全社・複数Productで共有し、下流ほど個別のProductやScenarioへ具体化します。experience.mdで組織が大切にする体験判断を定め、scenario.mdで今回のユーザー、状況、Before Human Stateを具体化し、design.mdで必要なUI、Content、Interactionへ表現します。そしてvalidation.mdの結果をExperience Libraryへ戻すことで、次の設計に使える知識へ更新します。
ファイル名と分割方法は固定仕様ではない
組織規模やProductによって、Principles、Content、Research、Constraintsを別ファイルへ分割しても構いません。重要なのは名称を揃えることではなく、各Knowledgeの責務、参照順、Owner、更新方法を明確にすることです。
品質を保証する魔法のファイルではない
Knowledgeを渡せば自動的に最高のUXになる、という意味ではありません。Contextの質、相互の整合性、実ユーザーによる検証、そして人間の判断が必要です。
05 / From a file to a system
experience.md単体から、Experience Systemへ
案件ごとに一つのファイルを書くだけでは、体験知は蓄積されません。Experience Principles、Primitives、Semantic Experiences、Components、検証結果を元帳化し、個別のScenarioへ適用して初めて、組織が育てられるSystemになります。
Experience Systemは、体験判断を再利用可能な単位へ構造化し、Web、App、SaaS、Contact Center、店舗、Supportへ展開するための研究中のアプローチです。
The organizational question
どうすれば、優れた体験判断を案件の成果物だけで終わらせず、次のProduct、次の担当者、次のChannelでも使える組織資産にできるか。
06 / Working hypothesis
体験とは、Human Stateの変化である
現在の中心仮説は、体験を「人の状態が、働きかけによって変化すること」と捉えることです。画面や機能そのものではなく、その前後で人がどう変わったかを見る。
Before Human State不安
迷い
情報不足
迷い
情報不足
Experience InterventionExplain
Guide
Confirm
Reassure
Guide
Confirm
Reassure
After Human State理解
確信
安心
確信
安心
研究上の重要な区別
「安心」はExperience Primitiveではなく、働きかけの結果として生まれるHuman Stateと考えられます。Primitiveは、安心を生み出す Reassure のような働きかけです。この境界は、現在も検証中です。
07 / System architecture
体験知を、再利用と検証ができる構造へ
Human StateはSystemが働きかける前のInputと、結果として観察するOutcomeです。その間に、体験判断のKnowledgeと、Scenarioに適用された具体的なExperience Instanceがあります。
01Experience Principles体験を設計するときに守る、長期的な判断原則。
02Experience PrimitivesRecognize、Explain、Guide、Confirm、Reassureなど、状態へ働きかける最小の介入語彙。
03Semantic Experiences状況と目的を持ったExperience capability。例：High-risk Decision Confidence。
04Experience Components構造、使用条件、制約、Success signalsを持つ再利用可能なExperience Pattern。
05Experience Library原則、語彙、Pattern、適用条件、検証知をVersioningする組織の元帳。
06Experience Instances特定のScenarioとProduct ContextにPatternを適用した体験設計。
07Channel ExpressionUI、Content、Interaction、Human Service、Operationとして具体化された接点。
Design Systemとの1:1対応を目的にしない
この構造はDesign SystemのToken階層を写すためのものではありません。Experience固有の状況、Human State、介入、検証、Channel表現を扱うために必要な境界を、実践から定めていきます。
08 / Case study
銀行アプリで、初めて100万円を振り込む
金額の大きさ、操作の不慣れ、取消できない可能性。これは単なる「確認画面」ではなく、重要な意思決定に確信を持たせる体験です。
Before Human State緊張
不安
間違いへの恐れ
不安
間違いへの恐れ
PrimitiveRecognize
Explain
Confirm
Reassure
Explain
Confirm
Reassure
SemanticHigh-risk Decision Confidence
重要な意思決定に確信を持たせる
ComponentHigh-stakes Confirmation Experience
Instance銀行アプリで100万円の初回振込
そこから導かれるUI / Content / Interaction
振込先名を大きく、識別しやすく表示
銀行・支店・口座番号を再確認
金額を単位と桁区切りつきで明示
振込予定日時を具体的に表示
取消できない条件を実行前に説明
戻って修正できる導線を保持
完了したことと処理状態を区別
受付番号と後から確認する場所を提示
After Human State理解 → 確信 → 安心
09 / Cross-industry reuse
同じ体験構造は、異業種でも再利用できる
UIをそのまま流用するのではなく、人の状態を変える構造を再利用します。だからチャネルや業種が変わっても、判断の共通部分を残せます。
病院の初回精密検査予約
Uncertainty Reduction
First-time Preparation Experience。検査の目的、当日の流れ、準備物、所要時間、次の連絡を明確にし、未知への不安を減らす。
高級家具のオンライン購入
Purchase Confidence
High-consideration Purchase Experience。寸法、素材、設置、納期、返品条件を統合し、長く使う買い物への確信を支える。
10 / Shared ledger
Experience Library = 体験設計の元帳
再利用可能なExperience Componentsを組織で共有し、実践と検証から得た知見を更新し続ける場所です。
体験の原本を共有するCHANNEL-AGNOSTIC
Web、App、Contact Center、店舗では、表現や実装は異なります。それでも「どのHuman Stateに対して、どんな働きかけを行い、どの状態を目指すか」という体験構造は共有できます。
WebAppContact CenterStoreService Operation
Experience Library体験設計の元帳
WebAppSaaSContact CenterStoreSupport
11 / AI as an engine
AIは主役ではなく、組織へ展開するエンジン
AIはExperience System、Product Context、Scenario、Requirements、Design Systemを参照し、Generate / Review / Discover / QAを行います。
人間は、最高のExperienceの定義、優先順位、倫理、採用判断、実ユーザーによる検証、System自体の改善に責任を持ちます。
Generate
Review
Discover
QA
Edge Case探索
現在検証中のWorkflow
この構造は唯一の正解ではありません。どのContextを分離し、どの段階で人が判断し、AIにどこまで委ねるべきかを、実際のプロジェクトを通じて検証しています。
12 / Organizational adoption
一人の優秀さから、組織の再現性へ
個人に依存
優秀な一人のUX判断が、成果物には現れても、判断基準として組織に残らない。
組織で再現
PM、Designer、Engineer、Businessが、共通の判断基準を使って設計・検証・改善する。
Experience KnowledgeDesign SystemGuidelinesAI Skills
個人のセンスを消すのではない。
優れた判断を、組織が使い、検証し、育てられる資産に変える。
優れた判断を、組織が使い、検証し、育てられる資産に変える。
13 / Open Questions
今後の研究課題
Experience Systemを実際のプロダクトや組織で使い、何がどれだけ良くなるのかを、データで確かめていきます。
- プロダクトが変わっても、AIのアウトプット品質を保てるか複数のサービスや画面を横断しても、同じ体験原則から一貫した提案やレビューができるかを検証します。
- 非デザイナーのUI/UX判断は、どれだけ良くなるかPM、エンジニア、営業、事業担当者が使ったときに、判断の質やチームの会話、成果物がどう変わるかを測ります。
- UI/UXプロフェッショナルの知識で、AIの精度はどこまで上がるか経験豊富な専門家の判断理由や事例をExperience Knowledgeとして加え、提案・レビュー・QAの精度向上を比較します。
- 人の感情変化は、コンバージョンや事業成果につながるか不安が安心へ、迷いが確信へ変わることと、申込み、購入、継続利用などの結果とのつながりを計測します。