Muse Modes

Overview

Muse Modes are purpose-built ways to work with the same assistant.

The mode does not change the basic workflow. You still talk in Chat, review in Drafts, and approve only what belongs in UXit. What changes is how Muse behaves: how much it talks, when it asks questions, how it handles ambiguity, what it optimizes for, and when it keeps ideas in chat instead of writing drafts.

In the docs, call them Modes because that is the product concept. They are tuned workflow behaviors, not generic personalities.

Current Modes

The active modes in the current beta are Relaxed, Accessibility, Brainstorm, and Direct.

Relaxed

Relaxed is the default mode for general drafting and planning.

Use it when you want Muse to talk through the problem with you, ask a useful follow-up when the request is unclear, and help shape the draft without rushing the decision.

• Early feature planning
• Turning messy notes into a first draft
• Talking through uncertainty
• Catching obvious conflicts before drafts change

Example prompt:

I need requirements for a pizza ordering flow, but I am not sure how to split checkout, delivery, and account creation.

Example output:

I would split this into five draftable areas:

- Menu browsing
- Order customization
- Cart review
- Checkout recovery
- Order confirmation

One question before drafting: should account creation be required before checkout,
optional during checkout, or offered after the order?

Accessibility

Accessibility focuses on accessibility and usability barriers.

Use it when the problem is about clarity, interaction, readability, keyboard access, feedback, errors, mobile targets, contrast, or whether a user can realistically complete the task. Accessibility can review a screenshot, explain the issue in plain language, suggest a fix, and turn the accepted direction into requirements or guideline conditions.

• Error messages that rely on color alone
• Forms without clear labels
• Tiny mobile controls
• Confusing wizard or stepper flows
• Requirements that need accessibility acceptance criteria

Example prompt:

This checkout error only shows a red border. What should the requirement say so the error is actually usable?

Example output:

Issue

- The checkout error relies on a red border, so some users may miss what failed.

Recommended changes

- Add inline text: "Enter a valid email address, like name@example.com."
- Keep the red border, but pair it with text or an icon.
- Move focus to the first blocking error after submit.

Rationale

- WCAG A: error states need a text-based cue, not color alone.

Draft behavior

- I would keep Drafts empty until you confirm this direction.

Brainstorm

Brainstorm is for idea generation before commitment.

Use it when you are blocked, unsure where to start, or need someone to challenge the shape of the work before it becomes a draft. Brainstorm is intentionally more exploratory than Direct, and it should keep ideas in chat until you confirm what belongs in Drafts.

• Getting unstuck
• Comparing 2 or 3 directions
• Finding missing scenarios
• Stress-testing a rough idea
• Turning a vague feature into possible paths

Example prompt:

The onboarding flow feels weak, but I cannot tell if the problem is education, trust, or too many steps.

Example output:

My read: this is probably not one onboarding problem. It sounds like trust and momentum
are both fighting the user before they see value.

1. Trust-first path
   Explain why each piece of information is needed before asking for it.

2. Value-first path
   Let users see a useful result before asking for the heavier setup details.

3. Progressive setup path
   Split onboarding into required setup now and optional profile details later.

Recommended: start with 2, then use 3 to keep the first session short.
Want any of these moved to Drafts? Pick by number.

Direct

Direct is for fast execution.

Use it when you already know what you want and do not want a long explanation. Direct should draft, revise, or consolidate quickly, with minimal chat.

• Clear drafting requests
• Quick rewrites
• Adding a known missing requirement
• Cleaning up obvious overlap
• Getting usable draft cards without extra discussion

Example prompt:

Draft five requirements for browsing pizzas, customizing toppings, reviewing the cart, recovering from checkout errors, and confirming the order.

Example output:

Drafted 5 requirement cards:

- Pizza menu browsing: Users can compare pizzas with descriptions, prices, and dietary labels.
- Order customization: Users can choose size, crust, toppings, and quantity.
- Cart review: Users can confirm items, prices, and changes before payment.
- Checkout recovery: Users can fix payment or address errors without losing the cart.
- Order confirmation: Users know the order was placed and what happens next.

Planned Modes

Client Ready

Client Ready is planned for stakeholder language.

Use it when work needs to sound clear to a client, executive, founder, or non-technical reviewer. The goal is plain English, clean outcomes, and less internal shorthand.

Rough input
└── Checkout is confusing and users do not know if the order worked.

Client Ready direction
└── Customers need a clear confirmation step so they know their order was placed successfully.

Consolidate

Consolidate is planned for turning messy input into a cleaner structure.

Use it when you have overlapping notes, long voice-dump style context, duplicate ideas, or too many scattered requirements.

Before
├── Cart edits are weird.
├── Checkout errors are confusing.
├── Users ask if the order went through.
└── Confirmation page needs work.

After
├── Cart review and editing
├── Checkout recovery
└── Order confirmation

Research

Research is planned for deeper exploration.

Use it when you need more context before deciding what to build, test, or write. This mode is intended for stronger evidence, patterns, standards, and outside references before the work becomes a draft.

Prompt
└── What should we consider before redesigning mobile ecommerce filters?

Research direction
├── Summarize relevant usability patterns.
├── Compare possible approaches.
├── Call out risks and tradeoffs.
└── Convert the best direction into draftable UXit work.

Rescope

Rescope is planned for changing the size of existing work.

Use it when a plan needs to fit a budget, sprint, release window, or stakeholder constraint. Rescope helps turn too much work into the right amount of work.

Original scope
├── Full account dashboard
├── Advanced filtering
├── Saved reports
├── Export builder
└── Team collaboration

Rescoped MVP
├── Dashboard summary
├── Basic filtering
└── One saved PDF export

Best Practices

• Start with Relaxed when you are unsure.
• Use Direct when the work is already clear.
• Use Brainstorm before drafting when the idea needs pressure-testing.
• Use Accessibility when the issue affects clarity, usability, inclusion, or completion.
• Treat planned modes as upcoming specialist workflows until they are active.