§ Diagnostic

/uxreview

Review the UX substrate specifically.

What it does

A review of the UX substrate — information architecture, system feedback, forms, empty states, error recovery, cognitive load, progressive disclosure, interaction contracts, and state completeness. The layer that determines whether an interface actually works for the person using it, regardless of how it looks.

/uxreview exists because UX is consistently the layer that AI-generated interfaces get wrong while visual design gets the attention. An interface can look polished and still fail every UX fundamental — navigation that mirrors internal structure instead of user tasks, feedback that’s missing or unclear, forms that interrogate instead of guide, empty states that abandon new users, errors that describe failures instead of fixes. A dedicated state-completeness audit runs on every review.

Output

/uxreview · Stillpoint practices + signup

UX review

Reviewed UX fundamentals across Stillpoint’s practices section and signup form. Information architecture is sound; copy is mostly conversational; the practices grid is well-curated. The most significant issues are state-completeness gaps in the signup form and an unclear hero CTA hierarchy.

7 UX issues · 0 critical · 4 significant · 2 polish · 1 opportunity

State completeness audit

3 missing states found across the signup form and personalization banner. State-completeness findings are highlighted in accent within the severity tiers below.

Significant (4)

State completeness (2)

  • Signup form missing error state

    If the visitor submits an invalid email or the network fails, there's no error feedback — the form looks the same after submit as before. Users will assume submission worked and won't know to retry.

    Fix: Add inline validation + visible error state with retry guidance. Run /fortify.

  • Signup form missing success state

    After submission there's no confirmation that the email was received. The form simply renders the same "Get Started" button it did before — visitors who submit successfully have no acknowledgment.

    Fix: Add success state — quiet confirmation matching Stillpoint's voice. Run /fortify.

Forms and input

  • Signup input lacks client-side validation

    The email field accepts any input. Users typing an obviously incomplete address (no @, no domain) get no feedback until — at best — the back-end rejects on submit. A small live validation cue would catch errors at the source.

    Fix: Add inline validation feedback (helper text, focus state on incomplete input). Run /fortify.

Information architecture

  • Hero CTAs unclear in priority

    The hero pairs "Get Started" (primary button) with "How it works ↓" (tertiary button). Both compete for attention; the relationship between "begin" and "explain first" is unclear. A visitor unsure which action serves them might hesitate.

    Fix: Direct the call: single CTA, or clearly subordinated secondary action. Run /decide.

Polish (2)

State completeness (1)

  • Personalization banner has no fallback

    The banner /decide produced renders a hardcoded recommendation. If no time-of-day signal is available — or no recommendation lands — the banner has no quiet fallback. The space could go silent unhelpfully.

    Fix: Add a quiet fallback state (or hide the banner when no recommendation is available). Run /fortify.

Interaction contracts

  • Practice cards lack interactivity affordance

    Cards have a quiet hover border-color shift but no lift, no shadow change, and no cursor change to indicate they're clickable (if they are). Users have to guess whether the cards do anything when tapped.

    Fix: Add subtle elevation shift + cursor:pointer on hover to signal interactivity. Run /refine.

Opportunity (1)

Information architecture

  • Practices grid undersells natural ordering

    The three featured practices have an inherent time-of-day sequence — Morning, Mid-day, Evening. The current three-equal-cards layout treats them as parallel rather than as a daily rhythm. A tiered or sequential treatment could carry the structure visitors will already understand.

    Fix: Optional — surface morning/mid-day/evening as a journey rather than as three equal cards. Run /decide.

Coverage map

Surfaces audited, gaps marked

  • Signup formMissing error, success, and client-side validation states. Run /fortify.
  • Personalization bannerMissing fallback state when no recommendation is available. Run /fortify.
  • Practice cardsNo interactivity affordance on hover. Run /refine.
  • Hero CTA groupTwo same-weight CTAs compete for attention. Run /decide.

End of output

/uxreview surfaces UX failures regardless of how the interface looks. The state-completeness audit runs on every review — it's the layer where polished-looking surfaces most often fail silently.

When to use it

  • Visual design is generally solid but something feels wrong about how the interface works.
  • You want UX-specific analysis, not full-system review.
  • Preparing to ship and want to verify UX fundamentals are in place — especially state coverage.
  • An interface has grown through feature accumulation and needs a usability check.
  • You’re asking “is this usable,” “will people understand this,” “what’s confusing about this.”

How to use it

/uxreview

By default /uxreview reviews the full project’s UX substrate. Pass a scope (page, area, flow) to focus the review while still considering how that scope integrates with surrounding flows. State completeness is audited as a dedicated pass on every review — it’s the layer where AI-generated interfaces most consistently fail silently.

  • /uxreview onboarding
  • /uxreview checkout-flow

Anti-patterns it addresses

  • Confusing UX with visual. “The button looks generic” is a visual finding (handled by /survey or /refine); “the button’s disabled state is indistinguishable from its default state” is a UX finding — the user can’t tell whether they can act on it.
  • Over-reporting state completeness as instance findings when the gap is systemic. If every list is missing an empty state, that’s one finding (“empty states missing across all lists”), not forty.
  • Inflated reviews on UX-solid interfaces. A clean UX substrate gets a short review; padding to look thorough degrades credibility.
  • Findings that don’t ground in user impact. “This state lacks feedback” is weaker than “users encountering this state won’t know whether their action registered.” The user-impact framing keeps findings concrete.
  • Missing the state-completeness audit. The check is mandatory on every /uxreview — it’s the most common UX gap in AI-generated interfaces and the place a polished-looking surface most often fails silently.

See also