# Roadmap

This roadmap sequences the next product moves for UX RULER. `PRODUCT.md` remains the product memory: mission, audience, user need, assumptions, risks, metrics, and UX evaluation. This file exists because the product direction is now decided enough to choose what to do next.

Use this as a learning roadmap, not a feature backlog. Each item should stay tied to a problem, evidence, and signal.

## Direction

UX RULER should help humans and agents make better product decisions inside a repo before they build, by turning mission, audience, user need, evidence, value, metrics, and UX evaluation into compact durable context.

## Now

| Item | Problem Or Evidence | Signal |
|---|---|---|
| Make artifact handoffs explicit. | Recent landing-page measurement work added events and product-map updates, but the response ended as an implementation report instead of naming what to do next. | A future product-file edit closes with what changed, what decision it supports, what is measurable, what is missing, and 2 to 3 next options. |
| Create a roadmap once mission or direction is decided. | User feedback: a decided product direction needs an early visible sequence, not only a product map. | A new repo run creates or updates compact `PRODUCT.md` and `ROADMAP.md` after the mission or direction is chosen. |
| Turn landing-page events into reviewed product evidence. | The page emits install, copy, language, and GitHub-intent events, but the product decision needs a review cadence and decision rule. | Events are reviewed against the landing-page decision: can visitors find the install path and starter prompt? |
| Fill the first story case study. | `/story` now creates a founder-evidence portfolio surface, but each case study intentionally uses mockup scaffolding until the project content is discussed. | One selected project has real narrative, media, evidence, and a clear UX RULER lesson. |

## Next

| Item | Problem Or Evidence | Signal |
|---|---|---|
| Add one applied repo example to the website. | `PRODUCT.md` says UX RULER still risks sounding like theory instead of practical agent tooling. | 5 of 8 target users can explain what UX RULER does and name a real repo or product decision they would use it for. |
| Validate audience scale and reachability. | The primary audience is plausible but still needs evidence beyond the repo and website. | A compact audience-size and channel estimate identifies reachable AI coding-agent product builders and the strongest demand signals. |
| Run 5 to 8 landing-page/user sessions. | The website now explains the process and tracks key actions, but comprehension still needs direct user evidence. | Participants can choose an install path, copy the right command, and describe their first UX RULER use case without extra explanation. |

## Later

| Item | Problem Or Evidence | Signal |
|---|---|---|
| Add a compliant `DESIGN.md` path only when needed. | Standards-backed artifacts can drift if templates are loose. | A `DESIGN.md` template passes the expected format and is used only when a design-system decision needs it. |
| Expand the artifact library only after repeated use. | The repo intentionally avoids a large artifact tree until real decisions, risks, or collaborators need it. | At least 3 real applications show which extra files reduce confusion or improve continuity. |
| Strengthen contribution examples. | Open source users may understand the skill faster through concrete issue, PR, and product-decision examples. | Contributors can map a suggested change to mission, user need, metric, and roadmap item. |

## Review Rule

Review this roadmap when `PRODUCT.md` changes, when a validation signal arrives, or when a roadmap item is completed, deferred, or invalidated.
