
Layers Interaction Flow
Breadboard user flows—places, affordances, failures, and edge cases—before locking visual UI or code structure.
Install
npx skills add https://github.com/jamiemill/layers-skills --skill layers-interaction-flowWhat is this skill?
- Library-of-techniques model (not a rigid script); assumes `/layers-intro` is already loaded
- Forces named destinations for every affordance so “Submit → where?” decisions are explicit
- Treats failure paths, validation errors, and empty states as required breadboard steps
- Sits between conceptual model (what exists) and surface layer (how it looks)
- Anchors each flow to a job story: specific user, situation, and job before diagramming
Adoption & trust: 581 installs on skills.sh; 155 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
Recommended Skills
Web Design Guidelinesvercel-labs/agent-skills
Lark Whiteboardlarksuite/cli
Ui Ux Pro Maxnextlevelbuilder/ui-ux-pro-max-skill
Sleek Design Mobile Appssleekdotdesign/agent-skills
Impeccablepbakaus/impeccable
Design Taste Frontendleonxlnx/taste-skill
Journey fit
Primary fit
Canonical shelf is Validate because interaction flow mapping de-risks scope before you invest in Build surface work or Ship-ready UX. Scope subphase is where you decide what happens in each step of a job story without committing to pixels or components.
Common Questions / FAQ
Is Layers Interaction Flow safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Layers Interaction Flow
# /layers-interaction-flow *Assumes `/layers-intro` has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.* The interaction structure and flow layer defines how a person interacts with the product: the places they navigate, the affordances available, the content presented, and the flow between states. It sits above the conceptual model (which defines *what exists*) and below the surface (which defines *how it looks*). A breadboard is always for a particular user in a particular situation doing a particular job. Know which job story before you start. --- ## The decisions this layer makes - The distinct places this flow moves through - What the user can do in each place, and where each action leads - What content each place needs to show - What happens on failure paths, empty states, and edge cases - Whether the flow is as simple as it can be while still serving the job If the conceptual model beneath isn't stable, flows built on it often need redoing — check that first. --- ## Disciplines — what keeps a flow honest - **Every affordance has a named destination.** "Submit → where?" If you can't name it, it's an unmade decision. - **Edges are required steps, not afterthoughts.** Breadboard the failure paths (validation, server error, disconnection, timeout, concurrent edit), the empty and loading states, the post-action state, and the cancel path. Each gap is an unmade design decision — name it. - **No broken objects.** For each conceptual-model object in this flow, its attributes and actions should be available together — not scattered across screens with no cross-linking. - **No isolated objects.** Each model relationship should be visible and navigable in the flow, or there should be a deliberate decision that it needn't be. - **Vocabulary matches the model's ubiquitous language.** - **Naming places is a design decision** — descriptive and user-meaningful ("Referral dashboard", not "Page 3"). - **Keep it minimal.** More than 5–6 places for a single job story is a signal to look for what can be collapsed. --- ## Breadboard notation ``` Place name - affordance → destination place - affordance → destination place [ content shown in this place ] ``` --- ## Techniques Breadboarding is the default; the rest serve particular situations. | Technique | Use it when | |---|---| | **Breadboarding** (Ryan Singer / Shape Up) | Default. Text notation that forces interaction logic to be settled before visual design makes changes expensive. | | **Walk the flow as the user** | Narrate: "I'm a user who [situation]. I arrive at [place], I see [content], I want to [motivation], so I [affordance]…" Walk the happy path, then every edge. The fastest way to find unmade decisions. | | **User story mapping** (Jeff Patton) | Complex product, many user types, incremental planning. Activities → tasks → stories across a timeline. | | **Task analysis** | Redesigning an existing flow — decompose the current task to find where friction, errors, and workarounds concentrate. | | **Service blueprinting** | Flow spans channels or involves backstage operations (staff, systems, third parties). | | **Critical User Journeys** | Deciding which flow to work on — the minimal path to core value (high-traffic, high-revenue, metric-critical). | | **Flow diagram** (`graph LR`) | Orientation only — flow through time reads left to right. The text breadboard stays the primary artefact; the diagram loses conditional detail. | --- ## Working with the designer Settle which job story the flow serves, where the user starts, and what success looks like. If redesigning, describe the current flow first — it reveals decisions already made, many of them unintentionally. Then name the places, map affordances and destinations,