The follow-up to the Quantum UX intro. Readers said QUX sounded too hard to build, so here is the plain-language, 7-step version.
To design a Quantum UX (QUX) project: (1) define the project (you don’t even need a fixed idea, you can start from data/opportunities), (2) define its dimensions (sensory, physical, virtual, psychological), (3) define the Experience Elements (XEl) that carry and exchange data, (4) measure data and train the XEl with machine learning, (5) build an environment where XEl interact, (6) design and develop the product or service, (7) launch and keep measuring. The three ideas people find hardest, multiform/multidimensional design, universal UX and sensorial UX, are simpler than they sound: rules plus data, and measuring effects rather than the thing itself.
Key takeaways
- QUX projects don't require a starting idea; you can begin from data and opportunities, then design.
- Multiform / multidimensional design means experiences with no fixed shape that cross dimensions; you define rules and test them.
- Universal / cultural UX can be automated with simple data rules (if A then yellow, if B then blue) using tools like analytics and optimization.
- Sensorial UX is easy to design but hard to measure; measure it by its effects on other dimensions (like a black hole).
- XEl are elements charged by data that pass energy to other XEl, trained with machine learning to self-generate experiences.
The three concepts people find hardest
| Concept | Plain-language explanation | Difficulty |
|---|---|---|
| Multiform / multidimensional design | Experiences with no fixed shape that span dimensions, so no two users perceive the same thing. You don’t hand-craft each one; you write rules for how elements behave in context, then test. Complex to conceive, simple to operate. | Sounds hard, isn't |
| Universal / cultural UX | The simplest of the three. Use existing data (analytics, optimization tools) and rules to generate conservative or innovative variants, e.g. ‘if A then yellow, if B then blue, if A shares parts of B then green’. Can be as rich (anthropologists, linguists) or as automated as you want. | Easiest |
| Sensorial UX | Easy to design, hard to measure because perception is subjective and shifts over time. Measure it by its effects: a cold shop makes some customers shiver, so you learn the temperature experience without a thermometer, like detecting a black hole by the distortions around it. | Measure by effect |
Sensory experiences live in the quantum dimension: you can’t see them directly, but you can measure them by the effects they have on other entities.
On measuring sensorial UX
The 7 steps (with a deliberately absurd example)
The tutorial uses a joke product, a ‘cupcake with Bluetooth’ that plays a matching song on your Spotify when you bite it, precisely to show the method works even for something impossible. You can start a QUX project with just pen and paper.
Where it's heading
The end state of QUX is products that adapt automatically to what the user needs in the moment, predicting behavior from big data, with experiences increasingly generated by machines rather than hand-designed by humans. For the framework itself, see the Quantum UX and XCI intro, XMI and Universal UX.
In seven steps: define the project, define its dimensions, define the XEl, measure data and train the XEl, build an environment, design and develop the product, then launch and keep measuring.
No. Unlike classic UX, you can start from data and opportunities, find a niche or need, and design the product from there.
Designing experiences with no fixed shape that cross dimensions, so users perceive personalized versions. You define rules for how elements behave in context, then test, rather than hand-crafting each experience.
By its effects on other dimensions rather than directly. A cold shop makes some customers shiver, revealing the temperature experience without a thermometer, much like detecting a black hole by the distortion around it.
ML trains the XEl on measured data so the system improves and generates new experiences automatically, without explicit programming for each case.
Want to build a real, data-driven adaptive experience? Talk to Dorve.
Start a project