Interaction Design and Prototyping

Interaction design is the discipline concerned with shaping the behaviour of an interactive product — what it does in response to what a person does. Where visual design is largely concerned with how an interface looks and information architecture with how content is organised, interaction design asks a sequence of behavioural questions: What can the user do here? What happens when they do it? How do they know it worked? What happens when it does not work? A well-designed interaction is essentially a well-designed conversation, in which the system's responses are timely, intelligible, and predictable enough that the user can form reliable expectations about what will happen next. Prototyping is the practical craft through which interaction designers externalise these conversations, test them cheaply, and communicate them to the people who will build and fund the product. The two subjects are inseparable in practice: interaction design proposes behaviour, and prototyping is how that proposed behaviour becomes inspectable before a single production line of code is committed.

Core principles of interaction design. Interaction design begins with the recognition that a product is not a static artefact but a system of responses. A "Save" button is not merely a rectangle with a label; it is a promise about state change, about where data will go, about what feedback the user will receive, and about what will happen if the network fails mid-operation. Designing that promise — and ensuring the system keeps it — is interaction design. Four principles, drawn largely from Donald Norman's work and refined across decades of practice, structure most of this work.

• Visibility means that the controls relevant to a user's current goal are perceivable, and that the current state of the system is apparent. A car dashboard makes fuel level, speed, and warning conditions continuously visible; by contrast, a hidden gesture-only menu in an app makes an entire branch of functionality invisible to anyone who has not been told it exists. Visibility also covers status: a file-sync application that shows a small cloud icon with a checkmark communicates "everything is backed up" without requiring the user to go looking.
• Feedback is the system's acknowledgement that an action has been registered and what its consequence was. Feedback operates on several timescales. Sub-100-millisecond feedback (a button depressing, a row highlighting) confirms that input was received; one-second feedback (a spinner, a progress bar) maintains the sense of continuity; and completion feedback (a toast message, "Message sent", an updated list) confirms the outcome. The absence of feedback produces the classic failure mode of repeated clicking: the user, uncertain whether the first press registered, presses again and inadvertently submits the order twice.
• Consistency reduces learning cost by ensuring that similar things behave similarly. Internal consistency means that within the product, the same gesture always produces the same class of result — if swiping left deletes an email, it should not archive a contact. External consistency means conforming to the conventions of the wider platform and of competitor products, so that knowledge transfers in. Consistency is not an absolute good: a deliberate inconsistency is justified when two situations genuinely differ and the user must be prevented from conflating them (a destructive action styled differently from a benign one, for instance).
• Affordance, in Gibson's original sense, refers to the action possibilities a thing offers to a particular actor; in Norman's revised interface vocabulary, the useful term for designers is signifier — the perceptible cue that advertises the affordance. A raised, shaded rectangle signifies "pressable"; blue underlined text signifies "clickable"; a scrollbar's partial thumb signifies "there is more content below". The flat-design movement of the 2010s stripped many such signifiers and created measurable discoverability problems, which is why contemporary design systems have partially reintroduced shadow, elevation, and border cues around interactive elements.

Two further commitments sit alongside these principles. The first is that good interaction design anticipates user goals and minimises the effort needed to reach them. Effort can be counted literally: number of taps, distance of pointer travel, number of fields to fill, number of decisions to make, and amount of information the user must hold in memory between steps. A booking flow that pre-fills the departure city from the user's last search, defaults the date to tomorrow, and remembers passenger details has not changed what the system can do — it has changed how much work the user must do to get the common case done. Sensible defaults, recognition over recall (offering a list to choose from rather than demanding a remembered string), and progressive commitment (letting a user explore before forcing them to register) are all expressions of this commitment.

The second is the balance between aesthetic appeal and functional clarity. These are not opposed by default: research on the "aesthetic–usability effect" indicates that people perceive attractive interfaces as easier to use and are more tolerant of minor problems in them. But aesthetics become harmful when they consume the perceptual budget that clarity requires — low-contrast grey-on-white text that fails accessibility thresholds, decorative icons without labels whose meaning no one guesses correctly, or an animated transition so long that it becomes a tax on every navigation. The working rule is that visual decisions should be evaluated by whether they help the user perceive structure, state, and available action; ornament that does none of these must earn its place on other grounds, such as brand expression, and must never obstruct the task.

Desktop interaction design. The desktop remains the environment of sustained, precision, multi-document work: writing, coding, spreadsheet modelling, video editing, case management. Its interaction vocabulary matured over forty years, and most of its power comes from the fact that users arrive already fluent in it.

• Established GUI conventions. Menu bars give a complete, scannable inventory of application capability, which is why complex professional applications still rely on them: a menu is a self-documenting command set. Toolbars surface the small subset of commands used most frequently; context menus (right-click) deliver object-specific commands at the point of attention; dialogs collect parameters for a single operation; and status bars report ambient state. Window management — resizing, tiling, minimising, tabbing — lets users construct their own workspace, comparing two documents side by side in a way a phone cannot support. Because these conventions are shared, a new application that uses them correctly inherits a large portion of its learnability for free. A reference manager that puts "Export…" under a File menu, supports Ctrl/Cmd+F for find, and offers right-click on a reference entry requires almost no instruction for the basics.
• Varied screen sizes and resolutions. Desktop no longer means a single fixed canvas. A design may be rendered on a 13-inch laptop at 1280×800 logical pixels and on a 32-inch 4K display at 200% scaling, and the same window may be dragged between them. Layout integrity therefore depends on resolution-independent thinking: relative units and fluid grids rather than pixel-fixed positions, vector or multi-resolution raster assets so icons stay crisp at high DPI, minimum and maximum content widths so that text columns remain in the comfortable 45–90 character range rather than stretching to an unreadable 200 characters on a wide monitor, and resilient behaviour when a window is deliberately made narrow. Panels that collapse into a drawer below a certain width, tables that allow horizontal scrolling of secondary columns while freezing the identifying column, and toolbars that overflow into a "More" chevron are standard techniques.
• Desktop-specific interaction patterns. Three capabilities distinguish the desktop. Keyboard shortcuts and keyboard navigation create an expert pathway that bypasses the pointing device entirely; for a user entering a hundred records a day, the difference between tabbing through a form and reaching for the mouse is measured in hours per week. Shortcuts should be discoverable (shown next to the menu item that performs the same command), conventional (Ctrl/Cmd+S for save, Ctrl/Cmd+Z for undo), and never in conflict with the operating system's reserved combinations. Drag-and-drop exploits the precision of a mouse to express "move this there" directly, and demands careful feedback design: a drag image that follows the cursor, drop targets that highlight on hover, a cursor that changes to indicate copy versus move versus forbidden, and an undo path for the inevitable mis-drop. Multi-window and multi-monitor navigation supports comparison and reference tasks; applications that support detachable panels, multiple document windows, and "open in new window" allow users to externalise working memory onto the screen rather than holding it in their heads.
• Platform guidelines. Apple's Human Interface Guidelines and Microsoft's Fluent/Windows design guidance differ in concrete, user-visible ways — the position of the menu bar, the ordering of OK/Cancel in dialogs, the modifier key used for shortcuts, the conventions for preferences versus settings, the behaviour of closing the last window. Honouring the host platform's conventions means a user's existing habits continue to work. Cross-platform frameworks make it tempting to ship one identical interface everywhere; the cost is a product that feels subtly foreign on every platform. A pragmatic compromise is to keep the application's own domain logic and layout consistent across platforms while adapting the "edges" that touch the OS: keyboard modifiers, file dialogs, window chrome, notification behaviour, and system-level typography.

Mobile interaction design. Mobile is not a shrunken desktop. The input device changes from a one-pixel-precise cursor to a soft, occluding fingertip; the display shrinks by an order of magnitude in area; the user is frequently moving, distracted, one-handed, and on an unreliable network. Each of these facts generates design obligations.

• Touch input and gestures. A fingertip's contact area is roughly 8–10 mm across, which is why platform guidance specifies minimum targets of about 44×44 points on iOS and 48×48 density-independent pixels on Android, with adequate spacing between adjacent targets so that an imprecise tap does not trigger the wrong one. The finger also occludes what it touches, so confirmation feedback must appear outside the contact area — hence the magnified character bubble above the key on a phone keyboard, and tooltips that appear above rather than below the touch point. Gestures (swipe, pinch, long-press, drag, edge-swipe) are efficient but invisible: they carry no signifier at all. The safe pattern is to treat gestures as accelerators layered on top of a visible control — swipe-to-delete is acceptable because a delete option also exists in an edit mode; pinch-to-zoom is acceptable because it is a near-universal convention. A function available only through an undisclosed gesture is, for most users, a function that does not exist. Gestures must also avoid colliding with system gestures such as the Android back swipe or the iOS home indicator swipe.
• Small screens and progressive disclosure. With perhaps one-tenth the visible area of a laptop, mobile design is fundamentally an exercise in prioritisation: deciding what the primary task is and giving it the screen, while moving secondary functions one layer deeper. Progressive disclosure is the formal name for this technique — present the few options most users need first, and provide a clear route to advanced options for those who need them. Practical expressions include accordions and expandable sections, "Show more" links on long descriptions, a summary card that opens a detail view, settings split into "Basic" and "Advanced", and multi-step wizards that ask a few questions per screen rather than presenting a thirty-field form. Navigation patterns follow the same logic: a bottom tab bar is appropriate for three to five top-level destinations, while a hamburger drawer hides everything behind a single icon and consistently reduces engagement with the items inside it — a reasonable trade for rarely used destinations, a poor one for the product's core features.
• Mobile context. Orientation changes mean a layout must survive rotation without losing state — a half-completed form that empties on rotation is a well-known defect class. Network variability means designs must have explicit states for offline, slow, retrying, and failed; optimistic UI (showing the message as sent immediately while the request completes in the background, with a clear failure indicator if it does not) preserves responsiveness. Device capabilities open genuinely new interactions — camera-based scanning instead of typed entry, biometric authentication instead of passwords, and location awareness that can pre-fill a pickup address or sort results by proximity. Location, camera, and notification permissions should be requested in context, at the moment the benefit is evident, rather than in a barrage at first launch. Finally, environmental context matters: screens are used in bright sunlight (contrast), while walking (larger targets, forgiving touch), and in short bursts (fast resume to the exact prior state).
• Thumb reachability and ergonomics. Studies of one-handed phone use (notably Steven Hoober's observational work) show that a majority of interactions are one-thumbed, and that the thumb sweeps a comfortable arc across the lower and centre portion of the screen, with the top opposite corner the hardest to reach. As devices grew taller, this made the traditional top-anchored navigation bar ergonomically awkward, which is why bottom sheets, bottom tab bars, bottom-anchored primary buttons, floating action buttons in the lower right, and OS-level "reachability" modes have become standard. The design heuristic that follows: place frequent and primary actions in the lower third; place infrequent, destructive, or confirmation-requiring actions further away, where accidental contact is less likely. Reachability must also be reconciled with accessibility — supporting system text scaling, maintaining contrast, labelling controls for screen readers, and never relying on colour alone to convey state.

Prototyping strategies and fidelity levels. A prototype is a deliberately incomplete manifestation of a design, built to answer a specific question. Because it is incomplete, every prototype makes a choice about what to simulate faithfully and what to fake. Fidelity is usually discussed as a single axis, but it is more accurate to think of several independent dimensions: visual fidelity (how finished it looks), functional fidelity (how much of the behaviour actually works), content fidelity (real data versus lorem ipsum), and breadth versus depth (many screens shallowly, or one flow completely).

Low-fidelity prototypes earn their place through speed and disposability. Six paper variants of a checkout screen can be sketched in the time it takes to style one in a design tool, and because nobody is invested in a pencil drawing, the team can discard five without friction. Their roughness is an asset: an unfinished-looking artefact invites structural criticism ("why is payment before shipping?") rather than cosmetic criticism ("can that blue be darker?"). They are the correct instrument in the divergent phase, when the question is still which concept to pursue.

High-fidelity prototypes close the perceptual gap with the real product. Because they look and respond like software, participants in a usability test behave much as they would with the shipped system, which makes measurements of task success, error rate, and time-on-task far more trustworthy. They are indispensable when the design question concerns detail — whether a particular icon is understood, whether an animation communicates a hierarchy relationship, whether a form's inline validation feels helpful or nagging — and when the artefact must double as a specification for developers or as a demonstration to investors or clients.

Mid-fidelity prototypes are the workhorse of most teams. Built in a digital tool with correct layout, real labels, plausible data, and working links between screens, they allow genuine task-based testing while remaining cheap enough to change overnight. Deliberately holding back visual polish — greyscale, a single typeface, placeholder imagery — keeps reviewer attention on flow and structure.

The governing rule is that fidelity should follow the question and the phase, not the team's enthusiasm. Early, when uncertainty is about concept and scope, low fidelity maximises the number of ideas explored per unit of effort. In the middle, when uncertainty is about structure and task flow, mid fidelity gives testable behaviour at reasonable cost. Late, when uncertainty is about detail, polish, and handover, high fidelity pays for itself. A useful corollary concerns audience: engineers and designers read wireframes fluently, but many non-specialist stakeholders and some end users cannot abstract from a grey box to a product and will judge a low-fidelity artefact as evidence of a poor product. For those audiences, raise visual fidelity — or frame expectations explicitly before the session begins.

Prototyping as a communication tool. Beyond testing, prototypes are the lingua franca of a product team. A specification sentence such as "the system shall allow the user to filter results" is read differently by every person who encounters it; a clickable screen showing a filter panel, its default state, its applied-filter chips, and its empty-results message leaves far less room for divergent interpretation. Making the abstract concrete changes the quality of feedback: stakeholders stop offering vague approval and start saying useful things like "our regional managers will need to filter by two branches at once" — a requirement that would likely have surfaced during development, at ten times the cost.

• Early sharing creates alignment. When a prototype circulates before engineering begins, the product manager, developers, content writers, support staff, and legal reviewers can all interrogate the same artefact. Developers spot the states nobody designed (what does this screen look like for a user with zero orders?); support staff spot the scenario that generates tickets; content specialists notice that the error message is incomprehensible. Resolving these on a prototype takes hours; resolving them in a release candidate takes a sprint.
• Annotation carries what visuals cannot. A static screen cannot express timing, conditionality, or failure. Annotated prototypes attach notes to elements and flows describing: component states (default, hover, focus, pressed, disabled, loading, error, success); validation rules and the exact wording of messages; empty states, first-run states, and maximum-content states; transition and animation specifications; accessibility requirements such as focus order, alternative text, and screen-reader labels; and edge cases — expired sessions, offline submission, permission denial, duplicate records, a name 120 characters long. Annotations are what turn a prototype from an illustration into a buildable description of behaviour.
• Iterative review reduces late-stage cost. The economics are well documented: the cost of correcting a defect rises by roughly an order of magnitude at each stage it survives — concept, design, implementation, release. Repeated short reviews with real users and decision-makers catch misconceptions while the only thing to rework is the prototype. A practical cadence is a short review at the end of each design cycle, with a small number of participants, focused on one or two explicit questions rather than open-ended "what do you think?" solicitation.

Iterative design through prototyping. Iteration is not simply "doing it again"; it is a disciplined loop of design → prototype → evaluate → interpret → revise, in which each pass is informed by evidence from the previous one. A first-round prototype might reveal that users never notice the filter control; the second round moves and re-labels it and tests whether discovery improves; the third round finds that discovery is fixed but users do not understand how to clear a filter, and addresses that. Over several cycles the design converges on something that works, and — equally valuable — the team accumulates an evidence-based understanding of its users.

• Rapid prototyping lowers the cost of being wrong. When an alternative can be produced in an afternoon, the team is willing to try the risky idea, and willing to abandon it when evidence goes against it. The psychological effect is as important as the economic one: teams that have invested six weeks in a direction defend it; teams that have invested six hours in each of four directions choose dispassionately among them. Parallel prototyping — building several alternatives simultaneously rather than refining one serially — has been shown to produce better outcomes and more critical feedback, partly because critique of one option among many is not experienced as personal criticism.
• Structure iterations around explicit hypotheses. Unfocused testing yields unfocused results. A productive cycle begins with a written statement of what is believed and how it will be checked: "We believe that moving the primary action to the bottom of the screen will allow one-handed users to complete checkout without repositioning the phone; we will know this is true if at least eight of ten participants complete the task one-handed and time-on-task falls relative to the previous build." A hypothesis of this form specifies the change, the expected user behaviour, and the observable criterion, which prevents the common failure of declaring a design successful because participants said they liked it.
• Document changes and rationale between versions. Teams that cannot remember why a decision was made will re-litigate it. A lightweight version history — a changelog page in the prototype file, or a short entry per version recording what changed, why it changed, what evidence prompted it, and what was explicitly rejected — preserves design rationale. For example: "v4 → v5: replaced the hamburger drawer with a four-item bottom tab bar. Rationale: in round 2 testing, 7/10 participants failed to locate 'Saved items'; drawer discovery was the cause. Rejected alternative: keeping the drawer but adding a badge — judged insufficient because the problem was discovery, not salience." Such records shorten onboarding for new team members, give developers the reasoning behind unusual choices, and protect the team from re-introducing a pattern that evidence has already ruled out.
• Knowing when to stop. Iteration has diminishing returns. Reasonable stopping conditions include: the hypotheses for this cycle have been answered; task success and error rates have plateaued across two consecutive rounds; the remaining issues are cosmetic or can be resolved post-launch with analytics; or the cost of another cycle exceeds the expected value of what it would uncover. Stopping should be a deliberate decision recorded alongside the known outstanding risks, not an accident of the calendar.

Tools and techniques for prototyping. The right technique depends on the question being asked, the time available, and how much of the system can realistically be faked. Most teams use several in combination across a project.

• Paper prototyping. Hand-drawn screens on paper or index cards, with movable pieces — a sticky note for a dropdown, a cut-out rectangle for a modal, a strip of paper slid up a "screen" to simulate scrolling. In a walkthrough, one team member acts as the "computer", swapping sheets in response to where the participant taps with a finger, while another facilitates and a third takes notes. The method is extraordinarily cheap, requires no tool skills, and is excellent for testing information architecture, task sequence, and terminology. Its limits are equally clear: it cannot test timing, animation, legibility, gesture precision, or anything dependent on real data volume. It is also effective as a collaborative technique — design studio or "six-up" sketching sessions, in which every participant sketches multiple concepts in a fixed number of minutes and the group critiques them, surface far more of the design space than a single designer working alone.
• Digital prototyping tools. Tools such as Figma, Adobe XD, Sketch with InVision, Axure RP, ProtoPie, and Framer produce clickable artefacts that can be opened on a real device. Their characteristic capabilities include reusable components and design systems (change the button once, it changes everywhere), variants and interactive states, auto-layout for responsive behaviour, overlays and transitions, and in the more advanced tools, variables, conditional logic, and form input that behaves like the real thing. Axure and ProtoPie, for instance, can hold state — a prototype shopping cart that genuinely accumulates items and recalculates a total — which allows far more realistic testing than a linear click-through where every path leads to the same hard-coded screen. Modern tools are also collaborative: multiple designers edit simultaneously, stakeholders comment directly on the canvas, and developers inspect spacing, colour tokens, and asset exports from the same file, which removes an entire category of handover error. The main cautions are the temptation to over-polish before the concept is validated, the fact that a prototype's "happy path" can conceal unhandled states, and the risk that a highly convincing prototype causes stakeholders to underestimate remaining engineering effort.
• Storyboarding. Borrowed from film, a storyboard is a short sequence of panels showing a person, in a context, with a motivation, encountering the product and reaching an outcome. Where a prototype shows the screens, a storyboard shows the situation: a delivery driver double-parked in rain, one-handed, with three minutes to confirm a drop-off. This reframes design questions usefully — glove-compatible targets, loud-environment feedback, offline tolerance — that screen-level work tends to ignore. Storyboards also communicate value to non-designers, support the framing of research scenarios and test tasks, and pair naturally with personas and journey maps. They are quick (stick figures are entirely adequate) and are best produced before or alongside the first prototypes rather than after.
• Wizard of Oz prototyping. Named for the man behind the curtain, this technique has a hidden human operator generate the system's responses while the participant believes they are interacting with working software. It is the method of choice when the underlying technology is expensive, unbuilt, or probabilistic: conversational agents and chatbots, speech recognition, recommendation engines, machine-learning classification, and complex automation. A team designing a voice-controlled appliance can, for the price of a microphone and a confederate in the next room, discover what phrasings people actually use, what they expect the system to remember between turns, and how they recover when it misunderstands — findings that directly shape the grammar, prompts, and error-handling of the real system before any model is trained. Running one well requires preparation: a clear protocol so the operator responds consistently (including deliberately simulating realistic error rates, since a flawless "system" produces misleadingly positive results), a plausible cover story, rehearsed response latency, and an ethical debrief in which participants are told how the session worked. Related techniques include the "Pinocchio" or hollow prototype (a non-functional physical mock-up used to study form, handling, and placement) and concierge testing, in which the service is delivered manually to real customers to validate demand before automation.

Brought together, these ideas describe a single working method. Interaction design supplies the principles — visibility, feedback, consistency, signified affordance, economy of user effort — and the platform-specific knowledge needed to apply them well on a precise, multi-window desktop or on a small, touch-driven, context-sensitive mobile device. Prototyping supplies the means of making proposed behaviour visible at a fidelity matched to the current question, communicating it unambiguously to users, stakeholders and developers, and revising it through hypothesis-driven cycles whose rationale is recorded. The practical discipline lies in choosing deliberately: this fidelity, this technique, this audience, to answer this question, at this point in the project.

Alignment with Learning Outcomes

• MO1 — Not directly addressed. The topic does not enumerate memory types or their capacities, although its treatment of recognition over recall, sensible defaults, and progressive disclosure reflects the interface consequences of limited working memory.
• MO2 — Partially supported. The discussion of visibility, feedback, consistency, signifiers, and the use of prototypes to expose mismatched expectations shows how a user's expectations about system behaviour can diverge from actual behaviour and produce systematic errors, but the topic does not formally analyse mental models.
• MO3 — Indirectly supported. The topic does not teach Hierarchical Task Analysis, but it shows how an understanding of a user's goal and its constituent steps feeds interface decisions such as effort minimisation, progressive disclosure, navigation structure, and the task flows represented in a prototype.
• MO4 — Partially supported. Coverage of fidelity selection, hypothesis-driven iteration cycles, task-based prototype testing and Wizard of Oz studies gives the context for choosing an evaluation approach, though the explicit comparison of expert-driven inspection methods with user testing sits outside this topic.
• MO5 — Directly addressed. The topic defines low-, mid- and high-fidelity prototyping, explains how to select a fidelity level for a given question, surveys paper, digital, storyboard and Wizard of Oz techniques, and sets out the desktop and mobile interaction design principles a prototype should embody.