The item the actor wants to change is on screen, and so is the destination that stands for the changed state. Asking for the operation by name — open a menu, pick the field, choose a value — restates what the screen already shows. Drag and drop lets the actor pick the item up and carry it there; the drop performs the operation the destination represents.

The gesture is a spatial proxy for a semantic operation, and the proxy is a designed thing — most meanings have no place until a surface gives them one. Direct-manipulation theory has names for both halves: the fit between the gesture’s form and its meaning is articulatory directness, and a drop target is output serving as input — the rendered lane, list, or view doubles as the way of referring to it.

Forces

• Directness vs. legibility — the drag needs no syntax, but its signifier has to say two things at once: that the item can be picked up, and what dropping it somewhere will accomplish. The first is cheap — a handle, a cursor change; the second is the design work, and it has to hold while the drag is in flight.
• One chunk vs. motor cost — the held button phrases press–move–release into a single unit: while the tension lasts the actor cannot forget they are mid-operation, and with practice the whole gesture becomes something they just do. But the held state is expensive — dragging runs roughly three times the error rate of plain pointing — so the habituated chunk is also the costly one.
• Destination meaning vs. overload — the move is trustworthy only while each destination means one thing. A folder that sometimes copies and sometimes moves, or the trash that deleted files but ejected disks, leaves the actor unable to predict the drop; an overloaded metaphor charges more than it pays.

Solution

Make the operation’s destinations into drop targets, and let where the item lands perform it. Three commitments keep the move honest:

• The write travels with the meaning, not the surface. Dropping a card in a lane writes the grouping attribute — whichever attribute currently groups, along whichever axis the lanes run. Regroup the board or rotate its axis and the same gesture keeps working, because the drop was never about the board.
• A destination that cannot take the write refuses it, audibly. Grouped by a computed attribute — a price band derived from the price — the lane can no longer be written; the same gesture now earns an explanation through the same channel a success would use, never a silent snap-back.
• The drag is an accelerator, never the only path. Every operation a drag performs also exists as a drag-free control that performs the identical write — the card’s move menu, the attribute list’s visibility toggle.

While a drag is in flight the interface is answering one question — what happens if I let go here? — and target design serves that answer: eligible destinations mark themselves on approach, an insertion line names the exact position, and a closed group springs open after a moment’s hover, so the drop can be aimed rather than guessed at.

Variants

Borrowed from Scott and Neil’s Designing Web Interfaces:

• List — reorder within one container; the destination is a position among siblings, usually signalled by an insertion line. This is sorting by hand: the order being written exists nowhere but the actor’s head.
• Object — drop one thing onto or into another to change a relationship: a card into a lane, a file into a folder, a track onto a playlist. The board demo above is this shape; so is surfacing an attribute into a view.
• Module — rearrange the blocks of a layout — dashboard panels, home-screen icons; the destination is a region of the page rather than another object.
• Collection — sweep items into a gathered set that later action operates on, usually alongside selection.
• Action — the drop invokes an operation on the dragged item: a document onto a printer icon, an attachment onto a compose window.

Accessible alternative

WCAG 2.1.1 (level A) requires a keyboard path to every outcome a drag can reach, and SC 2.5.7 Dragging movements (level AA) separately requires a single-pointer path that involves no dragging — a keyboard twin alone fails it. A move menu on the draggable item will satisfy both.

The alternative also earns its keep ergonomically. Dragging is the expensive form of the operation — long distances, small targets, touch, tremor — so the control that names every destination is often the fast path for everyone, not the fallback for some.

Resources & references

• Scott, B., & Neil, T. (2009). Designing Web Interfaces, ch. 2 — the five drag-and-drop patterns (Module, List, Object, Action, Collection) borrowed here as variant names
• NN/g. Drag-and-drop: how to design for ease of use — the two-part signifier problem: grabbable, and to what end
• Apple. Human Interface Guidelines: Drag and drop — one behaviour unified across containers, apps, and devices
• Atlassian. Pragmatic drag and drop: design guidelines and accessibility guidelines — phase-by-phase affordance guidance; alternative controls over arrow-key dragging
• GitHub. Exploring the challenges in creating an accessible sortable list — drag and drop as a “high-risk pattern”; users across abilities preferring the move dialog
• W3C. Understanding SC 2.5.7: Dragging movements and Understanding SC 2.1.1: Keyboard — the two independent twin obligations
• Hutchins, E., Hollan, J., & Norman, D. (1985). Direct manipulation interfaces. Human–Computer Interaction, 1(4) — articulatory directness; inter-referential I/O
• Buxton, W. (1986). Chunking and phrasing and the design of human-computer dialogues. IFIP World Computer Congress — the held tension as the glue that makes the gesture one chunk
• MacKenzie, I. S., Sellen, A., & Buxton, W. (1991). A comparison of input devices in elemental pointing and dragging tasks. CHI 1991 — dragging at roughly three times pointing’s error rate, with lower Fitts’ bandwidth
• Gentner, D., & Nielsen, J. (1996). The Anti-Mac interface — how metaphor cripples as well as carries