Product behavior, addressed.

Make product behavior explicit before it becomes code.

UXDL is a machine-readable behavioral contract between Product, Design, Engineering, QA, and coding agents.

Turn intent into a visual, addressable product specification that people can review and tools can reference.

The interpretation gap

The requirement is rarely the whole behavior.

They say

“Allow users to cancel their subscription.”

They don't say
When does access end?
Can the user undo it?
Who is allowed to cancel?
What if billing is past due?
What should the user see afterward?

Those decisions will exist in the implementation whether the requirement specifies them or not.

UXDL gives the team a place to make the answers explicit first.
Where UXDL fits

The interpretation layer between intent and implementation.

UXDL does not replace product documents, design tools, engineering planning, or coding agents. It makes expected behavior precise enough for people and tools downstream to reference the same thing.

Inputs
PRD or feature request
Prototype or design
Conversation or notes
Research or constraints
UXDLBehavioral contract
ScreenWhere can someone be?
StateWhat condition are they in?
ActionWhat can they or the system do?
RelationWhat happens next?
SliceWhat scope are we reviewing?
Downstream
Engineering planning / SDD
Coding agents through MCP
QA and test targets
Reviewable documentation
How UXDL works

From an idea to behavior your team can rely on.

Step 01

Start with what you have

Open a real UXDL project or begin on the Canvas. Intent and requirement import are the next onboarding path.

Canvas available
Open UXDLDescribe a change · next
Built-in quality checks

The graph can challenge the specification.

UXDL checks more than syntax. The contextual linter flags common product-flow gaps such as missing recovery, destructive actions without guards, dead ends, and missing empty states.

Findings are advisory. Fix them, or accept them with a rationale.

Learn about validation
IssuesAll 4Warnings 3Accepted 1Read-only example
Different jobs, one contract

Use UXDL when behavior needs to become explicit.

One model can be reviewed by people, queried by agents, and used as structured input for testing.

slice.checkout_recovery

Stop rebuilding the same product context in every prompt.

Give a coding agent exact Screens, States, Actions, Relations, and acceptance scope instead of asking it to infer the product.

Screen Action Slice
Public alpha

Built enough to use. Early enough to shape.

Start with the behavior you are about to build. The current editor is local-first; the next onboarding paths are clearly marked while they are built.

Available now
  • Visual Canvas and Document View
  • Screens, States, Actions, Relations, Slices
  • Deterministic and contextual checks
  • Local import, export, and stable addresses
In development
  • Describe intent → candidate UXDL
  • PRD or requirement import
  • Confirmed / inferred review
  • Clarification before acceptance
Try it on real work

Bring the requirement you are about to build.

Write naturally. Review visually. Address precisely.