Objects stay continuously visible, actions are reversible, and feedback is immediate

What it is

Direct manipulation rests on three supporting conditions: the target object and its relevant state stay continuously visible; actions can be undone or restored; every input produces immediate, interpretable feedback. Together they make a user feel they are manipulating the object itself, rather than submitting a command to a system. These are not three independently checkable bonus items — they are three legs holding up the same experience. Remove any one, and no matter how well the other two are done, what the user gets is no longer "directly manipulating an object" but degrades into "issuing a command to the system through a layer of indirection."

Why it happens

These three conditions are each indispensable because they each guard a different stage of the "action-result" loop. Continuous visibility guards the start of the loop — a user must first be able to treat an interface element as a stably existing work object and plan spatial relationships around it (where is it, what surrounds it); if the object flickers in and out of view or its state is unstable, the user cannot even be certain what they are supposed to be manipulating. Immediate feedback guards the middle of the loop — after every input, the user needs to see instantly what changed, and that feedback itself constitutes the evidence for the causal perception that "my action genuinely acted on the object"; the later feedback arrives, the weaker that causal perception becomes. Reversibility guards the loop's tolerance for error — it lowers the cost of the act of "trying" so much that a user does not need to fully work out the outcome in their head before acting; they can act first, see what happens, and undo if wrong. This act-and-see exploration is exactly direct manipulation's biggest advantage over command syntax. The three interlock: visibility tells the user what there is to act on, feedback tells them whether the action took effect, reversibility gives them the courage to act despite uncertainty — remove any one link, and the experience the other two hold up is diminished.

Where it stops holding

An object on screen is, after all, not a physical object in the real world — it has no genuine weight or inertia, and visibility does not happen on its own; it has to be actively maintained through design means — highlighting the selected state, snap guides during a drag, clear hierarchy, and appropriate context — all of which compensate for a screen object's lack of the physical presence it would have in reality. Immediate feedback also does not mean using an eye-catching animation to grab attention: if an object gets obscured by the finger or cursor itself during a drag and cannot be seen, or if network latency in a remote collaboration scenario delays feedback, then even if feedback is technically dispatched quickly, what the user actually experiences is still delay and uncertainty. Reversibility is the condition most often implemented incompletely — many designs merely roll back what is displayed on screen, while the underlying data it was linked to, downstream effects it triggered, and notifications sent to other people never actually roll back with it. This kind of "looks undone but isn't cleanly undone underneath" situation is more likely to create confusing data inconsistency down the line than simply not supporting undo at all.

Applying it

• In canvas, list, and relationship-diagram interfaces where direct manipulation dominates, always keep the object itself, the current selection state, related dependencies, and applicable constraints visible, rather than requiring users to fill in this information from memory.
• Core actions like dragging, resizing, sorting, and connecting should all provide a preview of the effect, snapping hints, the ability to cancel the current action at any point, and the ability to undo it even after completion.
• Show feedback near the input point where the user's gaze is currently resting: target highlighting, current position, quantities involved, whether a conflict exists, and whether this action has genuinely been committed successfully.
• How to check: fully test the "action-feedback-undo-redo" chain, confirming that the state shown on screen after undo and redo remains fully consistent with what is actually stored underneath, not just that the picture looks right.

Related

• Same group: B4.10.2 Actions substitute for command syntax · B4.10.3 Direct manipulation struggles to express abstraction and bulk operations · B4.10.4 Direct manipulation and automation conflict over control
• Nearby: B2.01 Affordances · B2.06 Feedback
• Search terms: direct manipulation · continuous visibility · immediate feedback · action-result loop