Decide how the actor selects what to act on — Selection

Decide once how the actor selects what an action applies to: one item, a set, or a range; whole items, parts of items, or content inside them; whether the selection is kept through sorting, filtering, and paging; and whether the selection control is always visible, shown on hover or focus, or available only in a separate mode. Later steps rely on this selection model. Creating a new item selects nothing, so it skips this step.

Decide where each kind of change is made

Decide this for each kind of change, not once for the whole system. The same system can handle a title edit and a record import in different places.

Combine any of:

• Let the actor change the item where it is shown — Editing in place

  Let the actor edit the item in the same place it is displayed. Each change is saved as it is made, so there is nothing pending to cancel, and undoing a change is handled by the undo step.

• Collect the change in a separate form — Form

  Use a separate form when the fields only make sense together, the input needs more space than the display has, the change applies to a set rather than the item being viewed, or the actor needs to review everything before submitting. The next sub-sequence shapes this form.

• Split the change into dependent steps — Wizard

  Use a wizard only when earlier answers decide which options are available later, and the task is done too rarely for the actor to remember its structure. Make Back return to earlier steps without losing what was entered; the undo step provides this. If the steps do not depend on each other, use a form with sections instead.

Ask only for what is needed

Include a field only if the system needs the value and cannot work it out itself. Each extra field adds effort and makes it more likely that the actor abandons the form.

Choose the input format for each field — Data entry

Accept free-form input where people write the value in different ways and the system can interpret it, and show the interpreted value before it is accepted. Use a structured input where a misreading would cause harm or the format is strict.

Help the actor answer

Two ways of helping the actor fill in the fields. They can be applied in either order, and most designs use both.

In any order:

• Offer a list where the value must come from a fixed set — Bounded choice

  Where the value must come from a set the actor did not define, let them choose from it, and pick a control that suits the size of the set. For a set too large to browse, use search.

• Pre-fill values the system can guess — Good defaults

  Fill in fields with the system's best guess before the actor reaches them. Where the system already knows the value, or takes part in the work itself, the assistance escalation sequence covers the design.

Divide a long form into sections — Sections · optional

Split a long form into a small number of named sections that stay the same each time the form is used. Skip this step for a short form.

Respond to invalid input — Validation

Show the message next to the field, say what is wrong and how to fix it, and keep the message visible until the input is corrected. Confirm valid input as soon as possible and report errors only when the actor leaves the field, but once a field has failed, recheck it as the actor types.

Separate saving from the other actions on the Save button — Saving

Separate storing the work from other actions that are often attached to the Save button, such as creating a version, discarding a draft, or marking work as done, and give each action its own control.

Choose between automatic and manual saving — Saving, its arrangements

Save automatically for open-ended work. Use manual saving where a real constraint or transaction requires a pending state that the actor can review or cancel. Where both are used, show which applies where. In both cases, show the save status: what has been stored and what has not.

Separate publishing from saving — Draft and publish · optional

When work is saved continuously and other people can see it, keep a working copy and add a separate publish action. Publishing marks the point where work is ready for others, and where review, versioning, and notifications can apply. Skip this step if no one else sees the work.

Assess the consequences of each action — Action consequences

Rate each action by how long recovery takes, how much it affects, and whether it triggers further changes, taking into account safeguards already in place, such as pending states and drafts. Call the result the action's risk rating. Publishing to people outside the team is often riskier than deleting.

Match the deletion safeguard to the risk rating — Deletion

Choose the safeguard from the risk rating, using the decision tree on the deletion page: undo alone for items that are easy to recreate, an inline confirmation, a dialog that explains the consequences, or a typed confirmation for deletions that cannot be undone. What a deletion covers is set by the selection model.

Provide undo — Undo

Provide undo for completed deletions, for changes made in place, and for Back in a wizard. An action that can be undone needs less confirmation, so update its risk rating once. Decide how many steps undo can go back and whether undo history is kept after the session ends.