Supported Workflows

Overview

Supported Workflows explains where Muse fits into UXit today.

Muse is strongest when the work is still messy: too much client input, a half-formed feature, an unclear UX problem, or an evaluation that needs structure before review can start. It opens inside the workflow and helps translate that rough context into the next useful layer of UXit structure.

Requirements

Requirements are where Muse has one of its highest-impact uses. A lot of product planning starts as loose conversation: a client call, a voice note, a backlog dump, or a half-written feature idea. Muse helps turn that into requirement cards that can actually be reviewed.

Use Muse here when you need to move from broad scope to organized product capability.

Before Muse
└── We need a pizza app where people can pick pizzas, change toppings, checkout,
    recover if payment fails, and know the order went through.

After Muse
├── Pizza menu browsing
│   └── Users can find pizzas with descriptions, imagery, prices, and dietary labels.
├── Order customization
│   └── Users can choose size, crust, toppings, and quantity without losing progress.
├── Cart review
│   └── Users can confirm items, prices, and changes before payment.
├── Checkout recovery
│   └── Users can understand and fix checkout errors without rebuilding the cart.
└── Order confirmation
    └── Users know the order was placed and what happens next.

When approved, selected requirement drafts are added to the Requirements board. From there, you can keep refining the requirement, add Use Cases, and write Acceptance Criteria.

Use Cases

Use Cases are part of the Requirements workflow.

Muse helps when a requirement is too broad to evaluate directly. It can suggest the user scenarios hidden inside the requirement so the team can review real behavior instead of vague capability names.

This matters because a requirement like "pizza ordering" is not one experience. It is a set of moments where different things can succeed or fail.

Requirement: Pizza ordering process
├── Browse available pizzas
│   └── User compares options before choosing.
├── Customize toppings and size
│   └── User changes the order to match what they want.
├── Review cart before payment
│   └── User checks price, quantity, and modifications.
├── Recover from checkout errors
│   └── User fixes a payment or address problem without losing the cart.
└── Receive order confirmation
    └── User knows the order was accepted.

Use the requirement and Use Case drawer to review, edit, and finalize the Use Cases after Muse helps expose the structure.

Acceptance Criteria

Acceptance Criteria are also supported through requirement planning.

Muse can help turn a scenario into checks that are easier to test, discuss, and mark complete. This is useful when the team agrees on the user goal but the definition of "done" is still vague.

Good Acceptance Criteria make the work concrete. They also reduce interpretation gaps between design, development, QA, clients, and stakeholders.

Use Case: Recover from checkout errors
├── Error clarity
│   └── User sees a plain-language error message next to the affected field.
├── Cart preservation
│   └── User can fix payment or address details without losing selected items.
├── Retry path
│   └── User can submit the corrected checkout form again.
└── Order safety
    └── System does not place the order until payment succeeds.

Keep the final criteria specific and testable before adding them to UXit. Muse can get the team out of blank-page mode, but the final criteria should still match the real product decision.

Guidelines

Open Guidelines, then click Muse.

Guidelines are where Muse helps translate UX judgment into repeatable evaluation conditions. This is valuable because a good evaluation is not just "look at the design and say what feels wrong." It needs consistent checks that different runs can reuse.

Use Muse here when you need to turn UX principles, accessibility concerns, product standards, or client expectations into conditions evaluators can answer.

Before Muse
└── We need to evaluate checkout clarity, error recovery, and whether users know what step they are on.

After Muse
├── Navigation
│   └── Users can identify the current checkout step and the next action.
├── Recovery
│   └── Errors explain what went wrong and how to fix it.
├── Cart Confidence
│   └── Users can review item details before payment.
└── Confirmation
    └── The final state clearly confirms the order was placed.

When approved, selected guideline conditions are added to the Guideline Set.

Best Practices

• Open Muse from the surface you are working in.
• Use Requirements for product scope, Use Cases, and Acceptance Criteria direction.
• Use Guidelines for evaluation standards and conditions.
• Give Muse enough context: user goal, product area, audience, constraint, or screenshot.
• Keep draft approval separate from final sign-off.