Learning paths
The hub holds the contracts. The Academy teaches you why each one is there.
Eight paths, in the order the argument runs: start from the person, establish the two contracts every feature consumes, take them into the rituals the team already has, then decide what is still worth checking — including with a real person — and only after all of that, hand work to a machine.
In preparation.The curriculum below is settled; the lessons are still being written, and there is nothing to enrol in yet. Every path links to the documentation that covers its ground today.
Told as stories
Interface practice is taught badly as a list of definitions and well as a sequence of decisions someone had to live with. So the lessons carrying astorymark come with a short video in narrative form: a team with a problem, the option they took, what it bought them and what it cost. 22 of the48 lessons are planned that way — the rest are short enough to read.
The curriculum
- FoundationComing soon
User-first
Starting from the person who has to use the thing. What their journey is, what it costs them when it is wrong, and why that belongs upstream of the architecture rather than downstream of it.
- The journey is the first artefact, before the screens and before the schema Includes a storytelling video
- Jobs to be done: what someone is hiring this interface for
- Research that changes a decision, and research that decorates one Includes a storytelling video
- What it costs the user when it goes wrong — and how that sets the budget
- First-class means it can send a story back Includes a storytelling video
Read today: User-first
- FoundationComing soon
The visual contract
A design system is not a folder of pictures. It is an established agreement about what the interface is made of — settled before any feature exists, and consumed by all of them.
- Explicit, agreed, enforced: the three properties, and which one design systems skip Includes a storytelling video
- Established, not per-feature: why a story must never design its own button Includes a storytelling video
- Semantic roles beat raw values: designing the token layer
- Generating tokens instead of retyping them
- States are part of the contract — including empty, loading and denied
- Contrast, focus and target size as build failures rather than audit findings
Read today: Design system
- FoundationComing soon
The technical contract
The core component library is the interface that user-interface code is written against. Props, states and accessible behaviour are its schema — and once they are settled, most screen-level decisions stop being decisions.
- A component API is an API: naming, defaults, and what not to expose Includes a storytelling video
- Core versus product: what belongs in the shared library and what does not Includes a storytelling video
- Stories as fixtures: every state named and reproducible
- Composing beats extending, and how to tell which one you are doing
- Versioning a component without breaking six screens
- The escape hatch problem: when a consumer needs something the contract forbids Includes a storytelling video
Read today: Component library
- CoreComing soon
UX inside the rituals
The designer is a participant, not a supplier — and they bring the established contracts into the room. How UI and UX enter story mapping and example mapping, and what changes when the answer to most questions already exists.
- Story mapping: the map is the journey, so map it with the designer in the room Includes a storytelling video
- The UX row: what a slice of the map has to be usable, not just functional
- Slicing honestly when you know what the library already supplies
- Example mapping: the states nobody writes rules for — empty, slow, denied, offline Includes a storytelling video
- Covered, composable, uncovered: the three answers to a state card Includes a storytelling video
- Raising a change request instead of inventing locally
- Four amigos: why an interface needs a fourth seat Includes a storytelling video
- Design critique as a working session, not an approval gate
Read today: Practices
- AppliedComing soon
Testing the journey, not the pixels
Once the two contracts hold, the visual is largely settled and the risk moves. What is left worth testing is whether a person can still get through — which is the test the contracts cannot give you for free.
- What the contracts already guarantee, and what they cannot Includes a storytelling video
- The journey test: the whole path, in a browser, in the user’s words
- Interaction tests at the component level, where a failure has an address
- Visual regression as a change detector, not a correctness oracle Includes a storytelling video
- Why a large screenshot suite goes quiet: the economics of a flaky diff Includes a storytelling video
- Budgeting a test suite across the levels
Read today: Journey-first
- AppliedComing soon
Usability testing
The level no automation reaches. A journey test proves a path is passable; only a person who did not build it can tell you whether anyone follows it. Five participants, a task, and the discipline to stay quiet.
- Passable is not followable: what the automated levels cannot see Includes a storytelling video
- Five participants, five times a year — and why that beats fifty once
- Give a task, not instructions: writing one that does not give the answer away
- The discipline of staying quiet, and why every rescue deletes a finding Includes a storytelling video
- Testing the recovery, not the happy path
- When a finding is about a shared pattern rather than a screen Includes a storytelling video
- Testing with people who use assistive technology — same method, same day
Read today: Usability testing
- AppliedComing soon
Accessibility by construction
Accessibility fails as a late audit and works as a constraint on the established contracts. What can be automated, what has to be done by hand, and what belongs in the design system rather than in either.
- The audit is too late: what to decide at contract time instead Includes a storytelling video
- Keyboard, focus order and the visible ring nobody may remove
- Names, roles and states — what a component must announce
- What an automated scan catches, and the 60% it does not Includes a storytelling video
- Testing with assistive technology without pretending to be a user of one
Read today: Accessibility tests
- AdvancedComing soon
Semi-automation and AI
Where the machine takes over: syncing tokens, scaffolding a component against its contract, turning a journey into scenarios, sweeping for accessibility violations. AI multiplies whatever discipline it finds, which is why this path is last.
- What to automate, and what has to stay a conversation with a person Includes a storytelling video
- Design tokens from the source of truth to the running app, unattended
- Scaffolding a component from its contract instead of from a blank file
- From a journey map to executable scenarios, with a human deciding Includes a storytelling video
- Reviewing a generated interface without rubber-stamping it
Read today: MCP
You do not have to wait
Everything the first lessons will teach is already written down. The fastest way to see how it fits together is to take the next story your team maps, run one session with the designer in the room, and put the result in front of five people who did not build it.