Prototyping

Sketches as experiments rather than miniature specifications

A sketch is a deliberately inexpensive representation of an idea. Its main advantage is not that drawing is fast; it is that a provisional mark is easy to discard. A designer who begins with a carefully aligned interface may become reluctant to question its structure, even when the structure does not support the task. A sketch keeps the cost of disagreement low. Lines can be crossed out, several possibilities can share one page, and a conversation can focus on what a screen should enable rather than which shade of blue to choose. Sketching is therefore a method of inquiry. It turns uncertain assumptions into alternatives that people can inspect and challenge.

Suppose a university library wants students to reserve group-study rooms. Research suggests that students first need to know whether a suitable room exists at the required time, while administrators need to enforce occupancy limits. One sketch might begin with a calendar; another might begin with a list of available rooms; a third might ask for the group size before showing either. The sketches encode competing hypotheses about task order. They should be evaluated by tracing realistic journeys: a student booking for six people, a student needing wheelchair access, and someone whose preferred slot has just been taken. A polished calendar alone cannot answer whether the task sequence is appropriate. The value of multiple sketches is that they expose this question before implementation.

Good sketches annotate behavior, not merely appearance. A rectangle labeled Room result should identify which facts appear there: capacity, location, access features, and availability. An arrow to a confirmation screen should explain what happens when a reservation fails because another user took the slot. A dashed line can indicate a proposed transition rather than an implemented one. Designers should mark unknowns with explicit questions such as Can the system hold a slot during checkout? or Is authentication required before searching? Without these notes, a reviewer may mistake an unexamined assumption for a design decision. This is especially risky when sketches are passed to engineers who were absent from the original conversation.

Divergence, comparison, and convergence

Early divergence means producing meaningfully different structures, not drawing the same layout with different icons. To encourage genuine variation, constrain each alternative to a different interaction strategy. For a room-booking interface, compare a search-first flow, a calendar-first flow, and a guided question flow. Evaluate each against the same task scenarios. Record where a user would encounter the most important information, how many decisions are required before a meaningful result, and whether a failed path offers recovery. A sketch with fewer screens is not necessarily simpler: a single dense screen can impose more simultaneous interpretation than a short guided sequence.

When reviewing sketches, separate observation from interpretation. An observation is the reviewer did not notice the accessibility filter until prompted. An interpretation is the filter may be poorly positioned or labeled. A proposed intervention is move the filter above results and describe it as step-free access. These statements have different evidential status. If the team records only the intervention, it loses the reason for the change and cannot later judge whether the proposed solution worked. Encourage reviewers to point at specific moments in a task instead of voting for the prettiest screen. The preference for a familiar-looking design may reflect past experience rather than suitability for a new problem.

Paper prototypes can simulate interaction without software. Give the participant a goal and let them point to a control; the facilitator replaces the page with the next state. The facilitator must follow a prepared transition script, not invent a helpful response whenever the participant struggles. Otherwise the test measures the facilitator's ability to rescue the design. Include error pages, empty results, and confirmation states in the paper set. Keep a record of which transitions required improvisation, because those are gaps in the prototype rather than evidence that the workflow is robust. If a participant asks what a label means, ask what they expect before explaining it. The expectation is part of the result.

Sketching can support accessibility discussions but does not establish accessibility. A drawing cannot prove keyboard order, screen-reader semantics, contrast, or dynamic focus management. It can reveal that a process relies on dragging, that error messages appear far from their fields, or that essential instructions are conveyed by color alone. Annotate these risks and plan a later executable test. In a group session, offer alternatives to drawing, such as written scenarios, verbal descriptions, or rearrangeable cards. A person's ability to sketch attractively is unrelated to the value of their understanding of a task.

Deciding when to leave the sketch stage

A sketch has served its purpose when the team can state which uncertainties remain and which can be investigated with a more structured representation. Do not require unanimous aesthetic approval. Instead, identify the next decision: Is the content hierarchy intelligible? Does the process need a backtracking path? Does the user expect to choose a room before a date? If these questions can be explored with paper, there may be no reason to implement a clickable interface yet. If the unresolved question concerns focus movement after an asynchronous error, paper is inadequate and a functional prototype becomes necessary.

A useful sketch review ends with a decision log. For each alternative, record its defining assumption, evidence supporting or contradicting it, unresolved risk, and the cheapest next test. Keep discarded sketches when they explain why an option was rejected; a later change in policy or user needs may make that option relevant again. Avoid treating the first selected sketch as the final product architecture. The design process is a sequence of increasingly informative representations, not a competition to select a single picture and defend it forever.

Wireframes organize content and task structure

A wireframe is a more explicit representation of a screen's information hierarchy, navigation, and control placement. It normally uses simplified typography and visual treatment so reviewers can focus on what information is available and what the user can do with it. Unlike an exploratory sketch, a wireframe should have enough structure that two reviewers can discuss the same interface state. It need not look like the eventual brand. Its central purpose is to make decisions about content and relationships inspectable before expensive visual and technical commitments are made.

Return to the room-booking example. A useful results wireframe should answer the user's likely questions: Which rooms fit my group? Which are available? What accessibility features do they offer? How do I reserve one? The screen can display cards, rows, or a calendar, but the information should have a documented priority. If room capacity appears only after clicking through to a details page, a student may waste time opening unsuitable rooms. If the accessibility information is hidden in a tooltip, a keyboard or touch user may miss it. A wireframe review can detect these issues by asking participants to locate specific facts without explaining where the designer placed them.

A wireframe should represent real content shapes. Placeholder text of identical length hides problems caused by long course names, multilingual labels, dates, and error messages. Use realistic examples: a building name that wraps, a room with no available slots, a reservation that spans a time-zone boundary, and a student who has not signed in. If the interface will be translated, test with labels of different lengths and scripts. A wireframe that fits only the shortest English wording has not established a resilient layout. Realistic content also reveals where the system needs truncation rules, sorting explanations, or a way to inspect full information.

From information architecture to interaction states

Information architecture determines how concepts are grouped and named. Wireframes express part of that architecture visually, but the relationship is not one-to-one. A navigation label such as My bookings implies a conceptual category that should contain current, canceled, and past reservations in an understandable way. A wireframe that shows only the current state may conceal the complexity of that category. Create state variants for empty lists, pending reservations, failures, and canceled bookings. Then ask whether the same labels remain accurate in every state. A navigation scheme that works only for the ideal case is not ready for implementation.

The layout must also distinguish an action from its explanation. For instance, Reserve room is an action; Available until 18:00 is status; Reservations are held for ten minutes is policy. Presenting these as similar-looking text creates ambiguity. Group status with the relevant room, place the primary action where it is discoverable, and put policy information where it can influence a decision. However, visual adjacency is not enough for accessibility: the eventual markup must preserve meaningful reading order and programmatic relationships. A wireframe should annotate the intended reading sequence and labels, particularly where the desktop grid will collapse to a single column on a phone.

Responsive wireframes are not simply scaled-down desktop images. A two-column search-and-results layout may need to become a sequential interaction on a narrow screen. Decide which information must remain visible, which can be summarized, and how the user returns to modify filters. A hidden filter drawer can preserve screen space, but it must communicate when filters are active and make it easy to clear them. If a student changes the date and the results update, the interface should announce the change in a way that does not unexpectedly steal keyboard focus. The wireframe can identify the required behavior, even though an executable prototype is needed to verify it.

Fidelity and false confidence

Visual fidelity and behavioral fidelity are independent. A high-resolution image can depict beautiful controls that do nothing. A plain HTML page can support realistic keyboard interaction, validation, and navigation. Choosing fidelity means deciding which properties must be accurate to answer the current research question. If the question is whether users understand a category name, a grayscale wireframe with representative content may suffice. If the question is whether a custom calendar can be used with a screen reader, a static wireframe cannot answer it. Increasing fidelity everywhere is often a poor use of time because it adds detail without reducing the uncertainty that matters.

Wireframes are also vulnerable to stakeholder overinterpretation. A reviewer may approve a screen because its hierarchy seems sensible, then assume that all error handling and permissions are resolved. Use visible annotations: provisional copy, backend behavior unverified, keyboard interaction to be tested, or sample data. The goal is not to excuse missing work but to communicate what the representation can and cannot demonstrate. A sign-off should specify the decision being approved. Approval of information order does not imply approval of technical feasibility, accessibility conformance, or production readiness.

A practical wireframe review protocol

Prepare three task cards and several states before the review. Ask a participant to locate an available room, inspect access details, and recover from a failed reservation. Observe where they expect information to appear and which labels they interpret incorrectly. Avoid coaching. After each task, ask what they believe the system would do next; this uncovers mismatches between the visible interface and the expected service behavior. If the participant cannot interact with a static wireframe, let them describe the intended action and have a facilitator follow a fixed script. Record every point where the script lacks a state.

After the session, group findings by underlying cause. Several confusing screens may share one terminology problem. A failed booking and a canceled booking may both lack clear status labels. Addressing the common cause can be more valuable than adding isolated instructions. Update the wireframe and annotate which finding motivated each change. Maintain a list of unanswered questions that require live code, real users, or service-policy decisions. The deliverable is not a flawless set of boxes; it is a clearer model of the service and a smaller set of risks.

A prototype is an executable claim about behavior

An interactive prototype lets someone perform a sequence of actions and observe responses. It may be a linked set of screens, a small application, or a simulated service operated by a facilitator. The important property is not the tool used but the behavior being represented. A prototype makes a claim such as when a user changes the date, the availability results update without losing their group-size choice. That claim can be examined through interaction. A screenshot cannot demonstrate it. An elaborate application may also fail to demonstrate it if its sample data always returns the same result.

Prototype boundaries must be explicit. A team may connect screens with hard-coded navigation while simulating a successful booking without a real reservation database. This can be appropriate for studying navigation and comprehension, but it cannot establish that concurrent bookings are safe. Mark fake data and simulated responses. If the prototype shows a payment success screen without processing payment, warn participants that the transaction is not real. A participant's willingness to click through a simulated checkout is not evidence that the payment service is reliable or trusted in production. The research question determines which parts of the system must behave realistically.

A useful interaction specification identifies states, events, guards, and visible feedback. For a booking form, states might include editing, validating, requesting, confirmed, and failed. An event such as clicking Reserve triggers a transition only when required fields are valid. A guard checks that a time and room have been selected. The prototype should reveal a failure state if the simulated service rejects the reservation. A retry should preserve the user's inputs unless there is a justified reason not to. Without these details, a prototype often becomes a happy-path slideshow that conceals the moments where real users need help.

Choosing the smallest behaviorally sufficient prototype

Start with the hypothesis. If users are confused by the order of questions, linked screens may be enough. If the concern is input validation, a lightweight HTML form can show focus, errors, and recovery. If the concern is voice interaction, a facilitator may play the role of a speech recognizer in a Wizard-of-Oz study, using a consistent script. In each case the prototype must expose the uncertainty under investigation. Building a production-grade authentication system merely to compare two labels is wasteful; using static pictures to evaluate keyboard operation is invalid. Fidelity should follow the risk, not the designer's preferred software.

A Wizard-of-Oz prototype is particularly useful when the proposed system relies on behavior that is expensive to implement. Imagine a study-planning assistant that recommends revision sessions. A researcher could provide scripted responses behind a chat interface while a participant tries to arrange a timetable. This reveals what information the participant expects and which explanations they need. It does not validate recommendation accuracy, model safety, latency, or operational cost. The facilitator should follow a defined response policy and document exceptions. Otherwise the hidden operator may unintentionally provide capabilities that no actual system could deliver.

For each interactive control, specify input methods beyond a mouse click. A keyboard user must be able to reach and activate controls in a sensible order. A form should have associated labels and a visible focus indicator. Dynamic updates should be communicated without unexpectedly moving focus. A modal should have a clear title, an escape route where appropriate, and focus behavior that can be tested. A prototype that merely looks accessible does not demonstrate these properties. The W3C guidance on accessibility evaluation emphasizes both early checks and evaluation with users, because automated or visual inspection alone misses important barriers.

State-space growth and test selection

Interactive flows can become complex as decisions accumulate. In a deliberately simplified model, suppose there are n independent binary choices and every combination is reachable. Then the number of possible configurations is 2^n. With seven choices there are 128 configurations; with ten there are 1,024. This count is an upper bound for that simplified structure, not a forecast of real user journeys. Real choices may be constrained, repeated, or dependent on earlier actions. The model illustrates why checking only the happy path is inadequate as interactions grow.

The answer is not to test every theoretical combination blindly. Select paths that cover important states and transitions: first use, empty data, invalid input, slow response, permission denied, successful completion, and recoverable failure. Include combinations that could cause harm, such as a user submitting twice after a timeout. Pairwise selection can help reduce combinations when interactions are largely independent, but it is not a substitute for risk analysis. If one combination could delete an assignment, test that path directly regardless of whether a combinatorial algorithm includes it. Document the coverage rationale so reviewers understand what remains untested.

Simulated performance and honest feedback

A prototype can display a spinner, progress bar, or success message, but its timing may not resemble production. A fixed two-second delay teaches participants what waiting looks like; it does not establish actual server performance. For studies where waiting behavior matters, vary delays according to an explicit test plan and tell the team which values were simulated. Likewise, a confirmation should reflect the simulated state correctly. Showing Saved immediately after a button click can teach a dangerous interaction pattern if the real service requires a server acknowledgment. Prefer labels such as Sending, Awaiting confirmation, and Confirmed that distinguish action initiation from completion.

Prototype analytics should be interpreted cautiously. A click log can show that a participant selected a particular control; it cannot establish why they selected it. A successful path may have been accidental, guided by prior exposure, or dependent on the facilitator. Record both interaction traces and brief post-task explanations. Protect participant privacy by collecting only the information needed for the study and by making recording practices clear. Prototype environments often have weaker security than production systems, so never ask participants to enter real passwords, payment details, or sensitive personal data into an untrusted demo.

Iteration is a learning loop with explicit decisions

Design iteration is not the repeated polishing of a screen until everyone likes it. It is a cycle of identifying uncertainty, constructing a representation, gathering evidence, interpreting the result, and choosing what to change. A productive cycle begins with a falsifiable question. Will students notice the step-free-access filter before selecting a room? is testable. Can we make the interface more intuitive? is too vague to guide a study. Define an observable task, what would count as a problem, and which design alternatives are plausible before running the next round.

Consider a room-booking prototype with two candidate result layouts. Version A shows access features under each room name; Version B places them in a collapsed details panel. The team hypothesizes that A will reduce the number of unnecessary room-detail openings for students who need step-free access. A small formative study can explore that mechanism by recording the first action and the number of irrelevant rooms opened. It should not be described as proof that A will improve outcomes for all users. Participant characteristics, task wording, prior experience, and facilitator behavior may influence the observation. A credible iteration report states the conditions under which the result was seen.

When a design changes, preserve the link to evidence. A decision record can include the problem observed, proposed cause, change made, expected effect, and next test. If a participant overlooked a filter, the cause might be placement, terminology, contrast, or a mismatch with the task model. Moving the filter and changing its wording simultaneously may improve the experience, but it prevents the team from knowing which change mattered. In exploratory design this may be acceptable; in a controlled comparison it is a confound. Choose the degree of experimental control that matches the decision being made.

Planning effort without pretending to predict discovery

A simple planning model can make iteration costs visible. Suppose a team spends 120 minutes establishing a reusable prototype, then 85 minutes per revision and 35 minutes reviewing that revision. Every third revision also requires a 30-minute stakeholder synchronization. For n revisions, a toy estimate is T(n)=120+120n+30 ceil(n/3) minutes. At six revisions the estimate is 900 minutes, or 15 hours. These values are illustrative budget assumptions, not measured averages or guarantees. Real work includes recruitment, accessibility accommodations, setup, writing, rework, and organizational delay. The model is useful for comparing scenarios only if its omissions are stated.

A team can also model the opportunity cost of over-polishing. If a new icon treatment takes three hours but the unresolved risk is that users cannot recover from failed bookings, those hours may have lower expected value than building an error-state prototype. A prioritization discussion should consider consequence and uncertainty, not only the number of complaints. A rare but irreversible mistake deserves attention even when a more common cosmetic issue attracts more comments. Use severity, exposure, and reversibility as separate dimensions rather than multiplying arbitrary scores and presenting the product as objective truth.

Evidence quality and research ethics

Formative tests can reveal where a prototype breaks down, but a small convenience sample does not support population-wide claims. If two participants fail to find a control, record the failures and investigate them. Do not claim that a fixed percentage of all students will fail. If comparing two designs, consider counterbalancing order so learning from the first task does not automatically benefit the second. Keep task instructions equivalent. Avoid presenting the design hypothesis to participants in a way that leads them to search for the expected answer. Observe behavior first; ask for explanations afterward.

Accessibility testing should not be deferred until the final polish. Involve people with different access needs at appropriate stages and combine their observations with technical checks. A participant using a screen reader may reveal that the reading order contradicts the visible grouping; a keyboard user may discover that a filter drawer traps focus. A quick automated check may identify missing labels but cannot prove the workflow is usable. Conversely, one successful session with a disabled participant does not establish standards conformance or universal accessibility. Different methods answer different questions, and an iteration plan should use them together.

Research participants should know when a service is a prototype and what data is recorded. In a university setting, students may feel pressured to participate if a teacher recruits them directly. Offer a meaningful option to decline and avoid collecting grades or personal schedules when invented test data would suffice. Store observations with limited access and a defined retention plan. A prototype of a counseling service should never invite real sensitive disclosures merely to test its navigation. Design evidence is valuable only when collected in a way that respects the people providing it.

Knowing when to stop a cycle

An iteration can stop when the specific decision is sufficiently informed for the next investment, not when all conceivable issues have disappeared. For a low-risk content label, a few observed task attempts and a clear terminology rationale may justify proceeding to a functional prototype. For a high-stakes application or a destructive action, stronger evidence and deeper technical testing are necessary. Explicitly document residual risks. A team that cannot state what remains unknown is likely to confuse the appearance of progress with actual reduction of uncertainty.

End each cycle with a concise record: the question tested, prototype version, participant or review conditions, observed behaviors, changes selected, rejected alternatives, and the next unresolved decision. Archive the old prototype and the evidence so later teams can understand why a choice was made. Avoid erasing inconvenient findings from the record simply because a new design looks better. The purpose of iteration is to improve the relationship between a system and its users through testable reasoning. Repeated change without a learning record is motion, not evidence of improvement.