Skip to content

Interaction Technique

Couple user action, input sensing, software interpretation, state change, and perceptible feedback into a repeatable way of accomplishing one elementary interactive task.

Version
v2 · 2026-09-19 · History
Domain-specific #
2086
Domain group
Professional & Organizational Practice
Origin domain
Human-Computer Interaction (HCI)
Subdomain
Interaction Techniques → Human-Computer Interaction (HCI)
Aliases
User interface technique, Input technique

Core Idea

An interaction technique is the task-level coupling by which a person acts on a computer system and receives enough feedback to accomplish an elementary interactive task. It joins an intended task, one or more physical actions, sensing through input devices, software interpretation, a change or query in application state, and perceptible output. Clicking a toolbar control, dragging an object, choosing from a marking menu, steering a pointer, pinching to zoom, speaking a command, or selecting an object with a ray in virtual reality are techniques when each defines a repeatable action–interpretation–feedback relation.

The technique is neither hardware alone nor a command alone. A mouse is an input device; “drag an object by holding the primary button while moving the mouse, with continuous visual displacement and release to drop” is an interaction technique. Likewise, “delete” is a function; a keyboard shortcut, menu selection, gesture, and spoken instruction can be distinct techniques for invoking it. Contemporary HCI texts therefore define an interaction technique as a programmatic coupling of input and output processing for an elementary task.[1]

This level matters because the same task can be realized through competing techniques and the same device can support many techniques. Designers can compare mappings, feedback, performance, error exposure, accessibility, and learning cost without confusing those properties with the application goal. Instrumental interaction further shows how techniques can be modeled as instruments mediating between users and domain objects, generalizing direct manipulation beyond conventional windows, icons, menus, and pointers.[2]

How would you explain it like I'm…

Press, Slide, See It Move

An interaction technique is a way you tell a computer to do something and see that it worked. Like dragging a picture on a tablet: you press, slide your finger, and the picture follows you, then you let go to drop it. The tablet is just the gadget; the press-slide-let-go move with the picture following is the technique.

Action-and-Feedback Recipes

An interaction technique is a repeatable way of doing one small job on a computer, like moving, picking, or zooming. It includes what you do with your body, how the device senses it, how the software understands it, what changes, and what you see or hear back. A mouse is a device, not a technique, and 'delete' is a command, not a technique. But deleting with a keyboard shortcut, a menu, a swipe, or by saying it out loud are four different techniques for the same command. Designers compare techniques to see which is faster, easier to learn, or less error-prone.

Input–Output Task Coupling

In human-computer interaction, an interaction technique is the repeatable coupling between a user's physical action, the system's interpretation of it, and the feedback that lets the user complete an elementary task. It sits between hardware and function. A mouse is an input device, and 'delete' is a command, but 'drag with the button held, see the object move, release to drop' is a technique. One task can be done with many techniques: shortcut, menu, gesture, or voice. One device can also support many techniques. Defining techniques at this level lets designers compare their speed, errors, accessibility, and learning cost separately from what the application is for. Examples range from clicking a toolbar button to pinch-zooming or pointing a ray at objects in virtual reality.

 

An interaction technique is the task-level coupling through which a user acts on a system and receives sufficient feedback to complete an elementary interactive task. It binds an intended task, one or more physical actions, sensing by input devices, software interpretation, a resulting change or query in application state, and perceptible output into a repeatable action–interpretation–feedback relation. Examples include clicking a toolbar control, dragging an object, using a marking menu, pinch-to-zoom, spoken commands, and ray-casting selection in virtual reality. The technique is distinct from the device (a mouse) and from the function (delete), since one function can be reached by several techniques and one device can host many. HCI texts accordingly describe it as a programmatic coupling of input and output processing for an elementary task. This level of description supports comparison of competing techniques on mapping, feedback, performance, error exposure, accessibility, and learnability. Instrumental interaction extends the idea by modeling techniques as instruments mediating between users and domain objects, generalizing direct manipulation beyond standard WIMP interfaces.

Structural Signature

  • elementary interactive task — a bounded goal such as select, point, navigate, enter text, manipulate, invoke, or specify a value;
  • domain object or command — the application-level referent on which the task operates;
  • user intention — the state or operation the user seeks;
  • action vocabulary — clicks, movements, gestures, keystrokes, speech, gaze, posture, or meaningful combinations;
  • input transduction — devices and sensing software turn physical activity into events or measurements;
  • interpretive mapping — software maps sensed action, current state, and mode to a command or parameter;
  • state transition — the target object, view, selection, or system state changes, or a query is performed;
  • feedback loop — visual, auditory, haptic, or other output makes recognition, progress, completion, and error perceptible;
  • operating conditions — device availability, posture, environment, mode, latency, accuracy, and accessibility assumptions bound performance;
  • learned control relation — users develop expectations connecting actions to consequences;
  • evaluation criteria — time, accuracy, workload, discoverability, learnability, transfer, comfort, and recovery support comparison.

The invariant is a repeatable task-level sensorimotor and semantic loop: action is interpreted as a particular operation, the operation affects interface state, and feedback closes the loop.

What It Is Not

  • Not an input device. A touchscreen supplies sensing; tap-to-select, long-press-to-open, and pinch-to-zoom are different techniques using it.
  • Not a widget. A slider is a control representation that commonly packages a technique, but the technique is the mapping among motion, value, constraint, and feedback.
  • Not a task. “Select an object” states what must be done; ray casting, clicking, gaze dwell, and voice naming state how interaction realizes it.
  • Not a complete interface. An interface composes many techniques with content, visual organization, navigation, and application logic.
  • Not direct manipulation generally. Direct manipulation is an interaction style whose techniques expose objects and provide rapid incremental feedback; techniques also include command, speech, menu, and mediated forms.
  • Not a usability property. A technique can be slow, inaccessible, or hard to learn and still be a technique. Usability evaluates its fit.
  • Not an implementation detail alone. Two implementations are the same technique only if their task-relevant action, mapping, and feedback structure are materially the same.

Scope of Application

The construct is native to human–computer interaction, computer graphics, interaction design, visualization, virtual and augmented reality, mobile interaction, accessibility engineering, and input-device research. It is especially useful where researchers propose or compare ways of pointing, selecting, navigating, positioning, entering symbols, choosing commands, or manipulating objects.

Scope is set by the elementary task and the human–system control loop. A technique may span hardware and software and may be implemented across many products. It may also be specialized to a device, body capability, environment, or application domain. A speech technique for issuing vehicle commands remains an HCI technique even though automotive safety constrains its design.

The abstraction should not be stretched to any method involving human action. A surgical maneuver or conversational repair is not an interaction technique in this sense unless specified as a mapping through an interactive computing system. Cross-domain analogies should be routed to coordination, interface, feedback, or mapping.

Clarity

To identify an interaction technique, ask five questions. What elementary task is supported? What action can the user deliberately perform? How is that action sensed and interpreted? What state or object does the interpretation affect? What feedback lets the user predict, monitor, and correct the result? If one role is missing, the candidate may instead be a device, command, presentation, task description, or isolated algorithm.

Granularity is important. “Use a computer” is too broad. “Move the pointer” may identify a control mapping, while “acquire a target by moving the pointer and clicking” identifies a pointing-and-selection technique. A detailed event handler may be too implementation-specific unless its details alter the observable action–effect relation. The useful unit supports one recognizable task and admits meaningful alternatives.

The definition permits multimodal and adaptive techniques. Input need not be one event, and mappings need not be fixed. A technique using gaze to nominate a target and speech to specify an operation still has an action vocabulary, interpretation rule, target state, and feedback loop. Adaptation belongs to the technique when it materially changes that mapping under declared conditions.

Manages Complexity

Interaction systems combine device physics, event streams, software state, user intention, perception, motor control, and learning. Treating each product as an indivisible interface makes comparison and reuse difficult. The interaction-technique abstraction compresses this complexity into a functional unit with explicit roles. Researchers can hold a task constant, vary a technique, and measure performance. Designers can hold a device constant and explore alternative mappings or hold a technique concept constant across device implementations.

This decomposition supports libraries and design spaces. A team can inventory techniques by task, modality, degrees of freedom, feedback, and control relation. It can locate gaps, incompatible transitions, overloaded actions, hidden modes, or inaccessible assumptions. It also exposes integration costs: locally efficient techniques can conflict when their gestures, modes, or feedback conventions overlap in a full interface.

It further separates invention from evaluation. A novel input–output coupling can be described structurally before superiority claims are made. Performance, learning, and accessibility remain empirical questions evaluated against representative users, tasks, environments, and baselines.

Abstract Reasoning

The structure licenses several inferences:

  1. Device substitution does not guarantee technique preservation. If a new sensor changes action vocabulary, precision, latency, or feedback, the human control relation may change even when the command is unchanged.
  2. Task equivalence enables comparison. Competing techniques can be compared fairly only when they support the same operational task under comparable conditions.
  3. Feedback is constitutive. Removing feedback can break the closed-loop technique by preventing correction or confirmation.
  4. Mode dependence predicts error. When identical actions map to different effects under poorly perceived modes, mode errors become likely.
  5. Performance and learning can trade off. A high-throughput expert technique may have larger acquisition cost than a visible, slower alternative.
  6. Composition creates interference. Techniques that work separately may compete for gestures, screen space, attention, or state when combined.
  7. Accessibility follows role substitution. If one physical action is unavailable, a function can remain accessible through another technique that preserves task and feedback roles with a different modality.

These are structural expectations, not universal rankings. Which technique is better depends on users, tasks, frequency, error cost, hardware, environment, and learning horizon.

Knowledge Transfer

Within HCI, the abstraction transfers across desktop, mobile, wearable, tangible, immersive, automotive, assistive, and ubiquitous systems. Task labels and actions vary, but the action–sensing–interpretation–state–feedback loop remains recognizable. Taxonomies developed for pointing or manipulation can guide a new platform while still requiring platform-specific evaluation.

Transfer is strongest when the elementary task persists. A selection technique can migrate from mouse to pen or gaze, with its control-display relation and confirmation adapted. Transfer is weaker when only a metaphor survives—for example, calling a social procedure a “user interaction technique.” The portable residue is then coordination, protocol, mapping, control, or feedback.

The construct also supports transfer between research and product work. A paper can report a technique independently of one application, while a product team can instantiate it and test local constraints. What transfers is the structured coupling, not an unconditional performance claim.

Examples

  • Mouse drag-and-drop. Press, movement, and release form the action sequence; hit testing interprets it; continuous motion and drop highlighting supply feedback.
  • Marking menu selection. A directional stroke invokes a command. Novices can reveal a menu while experts execute from learned motor patterns.
  • Pinch-to-zoom. Two-touch distance change maps to view scale with continuous visual feedback.
  • Gaze dwell selection. Gaze nominates a target and sustained fixation confirms it. Dwell duration trades false activation against speed.
  • Ray casting in immersive systems. A tracked controller defines a ray, intersection nominates an object, a trigger confirms, and highlighting communicates the candidate.
  • Speech command with confirmation. Recognition maps an utterance to a function and output exposes the interpretation before costly execution.

Each example instantiates one task through a specified action, mapping, state effect, and feedback loop. Merely naming its device omits the core.

Structural Tensions

  • Discoverability vs. efficiency. Visible menus teach available actions; hidden gestures and shortcuts can be faster once learned.
  • Directness vs. mediation. Acting on an object can feel immediate, while instruments, handles, or modes add expressive power at the cost of indirection.
  • Generality vs. task fit. One uniform technique reduces learning, but specialization can exploit task structure.
  • Responsiveness vs. interpretation confidence. Immediate action reduces latency; delayed recognition or confirmation can reduce costly false activation.
  • Precision vs. effort. Gains, snapping, constraints, and clutching redistribute speed, accuracy, and physical workload.
  • Consistency vs. adaptation. Stable mappings support prediction; adaptive mappings may improve local fit while making consequences less predictable.

Structural–Framed Character

The technique's event and feedback structure is observable: actions, sensor values, mappings, state transitions, latency, errors, and completion can be recorded. Yet design requires framed choices. Researchers define the task, recruit a population, select baselines, decide what errors cost, and choose a learning horizon. A technique excellent for expert repeated use may be poor for infrequent public use. Accessibility depends on whose bodies, devices, and environments are treated as normal.

Accordingly, the node is balanced rather than purely structural. It supports precise mechanism description while keeping performance and quality claims indexed to a study or design context.

Structural Core vs. Domain Accent

The structural core is a closed control loop: intention becomes action; sensing and interpretation map action to state; feedback makes the effect available for continued control. Its domain accent is HCI's vocabulary of users, elementary tasks, devices, events, interface objects, interaction styles, motor performance, usability, and empirical comparison.

The core resembles broad feedback and coordination patterns, but importing “interaction technique” outside computing would lose its recognized unit of analysis and evaluation tradition. It therefore remains domain-specific.

This entry is part of Coordination.

  • Coordination — aligns human action, software interpretation, and system response toward a task.
  • Feedback — perceptible output closes the control loop and supports correction.
  • Mapping — binds actions and sensed values to commands or parameters.
  • Interface — the technique operates at a boundary between human and computational states.
  • Control — continuous techniques regulate a displayed variable through a control-display relation.
  • Constraint — snapping, ranges, modes, and admissible gestures restrict transitions.

Coordination is the broader relation the entry falls under; the encyclopedia has no more general interaction-technique abstraction.

Relationships to Other Abstractions

Local relationship map for Interaction TechniqueParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Interaction TechniqueDOMAINPrime abstraction: Coordination — includesCoordinationPRIMEDomain-specific abstraction: Object–Action Interface — is a kind ofObject–ActionInterfaceDOMAIN

Current abstraction Interaction Technique Domain-specific

Parents (1) — outgoing typed relations

  • Interaction Technique includes Coordination Prime

    aligns human action, software interpretation, and system response toward a task.

Children (1) — abstractions linked here by typed relations

  • Object–Action Interface Domain-specific is a kind of Interaction Technique

    Interaction Technique is the broader abstraction this entry instantiates.

Hierarchy paths (5) — routes to 4 parentless roots

Neighborhood in Abstraction Space

Interaction Technique sits in a sparse region of the domain-specific corpus (97th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25

Not to Be Confused With

  • Direct Manipulation — an interaction style containing many techniques but not command, speech, or all mediated interaction.
  • Input Device — physical or virtual sensing apparatus.
  • Interaction Design — the larger practice of shaping behavior across flows, content, and systems.
  • User Interface Pattern — a recurring arrangement that may package several techniques.
  • Affordance — action possibilities or cues, not the complete input–output coupling.
  • Usability — contextual quality of use, not the method evaluated.

References

[1] Antti Oulasvirta, “Interaction techniques,” in Introduction to Human-Computer Interaction, Oxford University Press, 2025, https://academic.oup.com/book/60808/chapter/529001991. registry ↩

[2] Michel Beaudouin-Lafon, “Instrumental Interaction: An Interaction Model for Designing Post-WIMP User Interfaces,” Proceedings of CHI 2000, pp. 446–453, https://www.lri.fr/~mbl/papers/CHI2000/. registry ↩

[3] “Interaction technique,” Wikipedia, frozen revision 1344162248 (2026-03-18), https://en.wikipedia.org/wiki/Interaction_technique. registry