Work with research
Synthesize large volumes of feedback and data to discover hypotheses and questions.
Experience System — Foundational Research · v0.1
Experience
System
Turn outstanding customer experience from an individual talent into a system an organization can reproduce.
Experience System is a concept proposed by Kohei Torigoe and currently being developed through research and practice. This note shares its central hypothesis and structure as they stand today; it does not claim to be an industry standard or a finished method.
01 / The age of accelerated making
AI is lowering the cost of making
From research synthesis and UI generation to prototypes, code, and design QA, AI is rapidly accelerating the execution side of product development.
Generate UI
Develop multiple screen, content, and interaction options from requirements in a short time.
Connect prototypes and code
Reduce the back-and-forth between design and implementation and create something testable sooner.
Support review and QA
Explore inconsistencies with rules and edge cases together with people.
As making gets faster,
the quality of deciding what to make and why becomes the differentiator.
the quality of deciding what to make and why becomes the differentiator.
02 / Machine-readable design knowledge
AI also needs Design Knowledge
To help AI understand the brand, Design System, component usage, visual and interaction rules, accessibility, and constraints, approaches that provide machine-readable Design Knowledge such asdesign.mdare becoming important and more widely adopted.
This matters. It reduces the problem of AI producing inconsistent UI each time and lets people and AI refer to the same design rules accumulated by the team.
Without shared knowledgeAI starts from assumptions every time
Brand expression and component usage vary from one output to the next.
With design knowledgeStart from shared expression rules
Strongly govern UI consistency, usability, and accessibility.
Research in progress
design.mdis not presented here as an industry-standard name or structure. It is used as a general term for the practice of structuring Design Knowledge in a form AI can reference.
03 / The missing decision layer
Correct UI rules alone do not determine the best experience
A Design System and Design Knowledge can strongly govern UI consistency, usability, accessibility, and visual and interaction rules. But they do not fully express the higher-level decision of what desirable experience should be created for a person in a particular situation.
For example, even if button color, spacing, components, interaction, accessibility, and content rules are followed perfectly, that does not automatically ensure that someone transferring ¥1 million for the first time can move from anxiety to understanding, confidence, and a reassuring completion.
Design System only
The rules are shared, but experience decisions still begin with each individual
- What gets communicated first varies
- The response to anxiety changes from screen to screen
- The definition of completion is inconsistent across products
With Experience Knowledge
Design each expression from shared experience principles
- Share the target Human State
- Reuse the interventions that are needed
- Work across web, apps, and human services
Traditionally, these decisions lived in the heads of strong UX designers, design leads, and product leaders: who the experience is for, their current situation, what they should understand, how their state should change, and what deliberately should not be done. As an organization grows, this tacit knowledge becomes harder to reproduce, and UX quality varies by product and owner.
A DESIGN SYSTEM supports consistency of expression.
An EXPERIENCE SYSTEM supports consistency in the decisions that produce that expression.
An EXPERIENCE SYSTEM supports consistency in the decisions that produce that expression.
04 / The idea of experience.md
Turn the experience we want to create into readable Knowledge
experience.mdis the idea of structuring the experience a company, brand, or product seeks—changes in Human State, Experience Principles, and Patterns—as Knowledge that both people and AI can reference.
The file name itself is not the point. What matters is moving higher-level experience decisions into a state where they can be shared, tested, and updated without losing their rationale—not stripping them away from individual expertise.
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
A set of Markdown files for thinking through, creating, and validating strong experiences
Instead of putting everything into one enormous Markdown file, separate Knowledge by decision responsibility. This lets people and AI reference the experience direction, current context, required conditions, expression, and validation results without conflating them.
experience.mdWhat experience should be createdDefine shared Experience Principles, the target Human State, Semantic Experiences, reusable Patterns, and experiences to avoid.
product.mdWhy this product existsDescribe the business and product vision, target users, value proposition, definition of success, and product-specific constraints.
scenario.mdWho uses it, and in what situationSpecify the user, Before Human State, goal, environment, frequency, urgency, known anxieties, and edge cases.
requirements.mdWhat conditions must be metClarify functional, information, operational, legal, accessibility, privacy, safety, and acceptance requirements.
design.mdHow it should be expressed and behaveDefine information architecture, content, interaction, layout, component usage, and its connection to the Design System.
validation.mdDid the intended experience actually happen?Record validation methods, success and harm signals, observations, unresolved questions, and learnings to return to the Library.
experience.md→product.md→scenario.md→requirements.md→design.md→Prototype / Product→validation.md↺ Back to the Experience Library
Files further upstream are shared across the organization and multiple products; those further downstream become specific to individual products and scenarios.experience.mddefines the experience decisions the organization values;scenario.mdspecifies the user, situation, and Before Human State for the scenario;design.mdexpresses these decisions through the necessary UI, content, and interaction. The results invalidation.mdare then returned to the Experience Library, updating the Knowledge for the next design.
File names and divisions are not fixed specifications
Depending on the organization and product, Principles, Content, Research, and Constraints may be separated into additional files. The important thing is not uniform naming, but clarity about each body of Knowledge, its reference order, owner, and update method.
It is not a magic file that guarantees quality
Providing Knowledge does not automatically produce the best UX. The quality of the context, consistency between its parts, validation with real users, and human judgment all remain necessary.
05 / From a file to a system
From experience.md alone to an Experience System
Writing a single file for each project does not accumulate experience knowledge. It becomes a system the organization can develop only when Experience Principles, Primitives, Semantic Experiences, Components, and validation results are maintained as a ledger and applied to specific scenarios.
Experience System is an approach under research for structuring experience decisions into reusable units and applying them across web, apps, SaaS, contact centers, stores, and support.
The organizational question
How can strong experience decisions extend beyond a project's deliverables and becomean organizational asset that the next product, owner, and channel can use?
06 / Working hypothesis
An experience is a change in Human State
The current central hypothesis defines an experience as a person's state changing through an intervention. The focus is not the screen or feature itself, but how the person changes before and after it.
Before Human StateAnxiety
Uncertainty
Insufficient information
Uncertainty
Insufficient information
Experience InterventionExplain
Guide
Confirm
Reassure
Guide
Confirm
Reassure
After Human StateUnderstanding
Confidence
Reassurance
Confidence
Reassurance
An important distinction in this research
Reassurance is treated not as an Experience Primitive, but as a Human State that results from an intervention. The Primitive is the intervention that creates reassurance, such as Reassure . This boundary is still being tested.
07 / System architecture
Structure experience knowledge for reuse and validation
Human State is both the input before the system intervenes and the outcome observed afterward. Between them are the Knowledge behind experience decisions and a concrete Experience Instance applied to a scenario.
01Experience PrinciplesLong-term decision principles to follow when designing experiences.
02Experience PrimitivesA minimal intervention vocabulary that acts on a state, such as Recognize, Explain, Guide, Confirm, and Reassure.
03Semantic ExperiencesAn experience capability with a situation and purpose, such as High-risk Decision Confidence.
04Experience ComponentsA reusable Experience Pattern with structure, conditions of use, constraints, and success signals.
05Experience LibraryAn organizational ledger that versions principles, vocabulary, patterns, conditions of application, and validation knowledge.
06Experience InstancesAn experience design that applies a Pattern to a specific scenario and product context.
07Channel ExpressionA touchpoint expressed as UI, content, interaction, human service, or operation.
It does not aim for a one-to-one mapping with the Design System
This structure is not intended to mirror a Design System's token hierarchy. Practice will define the boundaries needed to handle experience-specific situations, Human States, interventions, validation, and channel expressions.
08 / Case study
Transferring ¥1 million in a banking app for the first time
The size of the amount, unfamiliarity with the process, and the possibility that it cannot be reversed make this more than a confirmation screen. It is an experience that must build confidence in a high-stakes decision.
Before Human StateTension
Anxiety
Fear of making a mistake
Anxiety
Fear of making a mistake
PrimitiveRecognize
Explain
Confirm
Reassure
Explain
Confirm
Reassure
SemanticHigh-risk Decision Confidence
Build confidence in a high-stakes decision
ComponentHigh-stakes Confirmation Experience
InstanceFirst ¥1 million transfer in a banking app
The resulting UI, content, and interaction
Display the recipient name prominently and distinctly
Let the user recheck the bank, branch, and account number
Show the amount clearly with a currency unit and digit grouping
Show the scheduled transfer date and time precisely
Explain any non-cancellable conditions before execution
Preserve a way to go back and make corrections
Distinguish completion from processing status
Provide a reference number and where to check it later
After Human StateUnderstanding → Confidence → Reassurance
09 / Cross-industry reuse
The same experience structure can be reused across industries
The UI itself is not reused. The reusable element is the structure that changes a person's state, preserving the common part of the decision even when the channel or industry changes.
Booking a first detailed hospital examination
Uncertainty Reduction
A First-time Preparation Experience clarifies the purpose of the examination, the day's flow, what to prepare, expected duration, and next communication, reducing anxiety about the unknown.
Buying high-end furniture online
Purchase Confidence
A High-consideration Purchase Experience brings together dimensions, materials, installation, delivery time, and return conditions to support confidence in a long-term purchase.
10 / Shared ledger
Experience Library = the ledger for experience design
A place where the organization shares reusable Experience Components and continually updates what it learns through practice and validation.
Share the source of the experienceCHANNEL-AGNOSTIC
Expression and implementation differ across web, apps, contact centers, and stores. Even so, the experience structure—which Human State to address, how to intervene, and what state to aim for—can be shared.
WebAppContact CenterStoreService Operation
Experience LibraryExperience design ledger
WebAppSaaSContact CenterStoreSupport
11 / AI as an engine
AI is not the protagonist, but an engine for organizational scale
AI references the Experience System, product context, scenario, requirements, and Design System to generate, review, discover, and perform QA.
People remain responsible for defining the best experience, setting priorities, ethics, adoption decisions, validation with real users, and improving the system itself.
Generate
Review
Discover
QA
Explore edge cases
Workflow under validation
This structure is not the only correct answer. Real projects are being used to test which contexts should be separated, where human judgment should occur, and how much should be delegated to AI.
12 / Organizational adoption
From individual excellence to organizational reproducibility
Dependent on an individual
One person's strong UX judgment may appear in the deliverable, but it does not remain in the organization as decision criteria.
Reproduced by the organization
Product managers, designers, engineers, and business teams design, validate, and improve with shared decision criteria.
Experience KnowledgeDesign SystemGuidelinesAI Skills
The goal is not to erase individual expertise.
It is to turn strong judgment into an asset the organization can use, test, and develop.
It is to turn strong judgment into an asset the organization can use, test, and develop.
13 / Open Questions
Future research questions
The next step is to use Experience System in real products and organizations and measure what improves, and by how much.
- Can AI output quality be maintained across different products?Test whether consistent proposals and reviews can be made from the same experience principles across multiple services and screens.
- How much can UI/UX decisions by non-designers improve?Measure how decision quality, team conversations, and deliverables change when product managers, engineers, salespeople, and business teams use the system.
- How far can professional UI/UX knowledge improve AI accuracy?Add the rationale and cases of experienced professionals as Experience Knowledge and compare improvements in proposals, reviews, and QA.
- Do changes in emotion lead to conversion and business outcomes?Measure the relationship between anxiety becoming reassurance or uncertainty becoming confidence and outcomes such as applications, purchases, and continued use.