6. Wireframing, Prototyping and Design Tools

Introduction and Context

User-interface design rarely moves directly from an idea to finished code. Between a business requirement and a working product lies a sequence of representations through which a team explores, communicates, tests, and refines a proposed experience. Wireframes and prototypes are central to this sequence. They make ideas visible before substantial development effort is committed.

A wireframe is a structural representation of an interface. It shows the arrangement of content, navigation, controls, and important states without attempting to reproduce the final visual style. A prototype is an interactive or partly interactive representation that allows users and stakeholders to experience a proposed flow. The distinction is not absolute: a wireframe may be interactive, and a prototype may be visually simple. What matters is the purpose of the artefact, its level of fidelity, and the questions it is intended to answer.

For a postgraduate full-stack developer, these practices are important because interface decisions affect information architecture, component design, accessibility, responsive behaviour, testing effort, and implementation cost. Effective prototyping is therefore not merely a graphic-design activity. It is a collaborative design and engineering practice that reduces ambiguity and provides evidence for decisions.

This chapter examines the movement from sketches to high-fidelity prototypes, the selection of appropriate tools and methods, the documentation of design rationale, stakeholder review, and the handoff of design knowledge to developers. It also considers limitations, governance, ethical responsibilities, and emerging applications of automation and artificial intelligence.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Distinguish sketches, wireframes, mock-ups, and prototypes by purpose and fidelity.

2. Select a suitable prototyping method for a particular design question, risk, or project stage.

3. Create responsive, accessible, and interaction-aware wireframes.

4. Plan and conduct structured stakeholder and usability reviews.

5. Document assumptions, alternatives, decisions, and unresolved issues.

6. Use contemporary design tools while understanding their limitations.

7. Prepare a design handoff that supports accurate and maintainable implementation.

8. Critically evaluate ethical, organisational, and technical risks in prototyping practice.

From Idea to Testable Representation

Design representations are temporary models of a product. Their value lies not in visual polish but in the learning they enable. A rough sketch can reveal that a navigation model is confusing; a clickable prototype can expose an incomplete checkout flow; a high-fidelity prototype can demonstrate whether a visual hierarchy supports a brand objective. Each representation should therefore be matched to a question.

A useful progression begins with divergent exploration. Designers generate several possible structures rather than immediately refining the first attractive idea. This is followed by convergence, in which alternatives are compared against user needs, business constraints, technical feasibility, and accessibility requirements. Prototyping makes the chosen or competing alternatives concrete enough to inspect and challenge.

The common levels of representation are as follows:

• Sketch: A quick, inexpensive drawing used to explore ideas, layouts, or flows. It is intentionally incomplete and easy to discard.
• Low-fidelity wireframe: A simplified digital or hand-produced structure showing content regions, hierarchy, controls, and navigation.
• Mid-fidelity wireframe: A more precise representation with realistic dimensions, labels, states, and sometimes responsive variations, but limited visual styling.
• Mock-up: A largely static visual design that communicates appearance, typography, colour, imagery, and branding.
• High-fidelity prototype: An interactive representation that approximates the visual and behavioural experience of the intended product.

Fidelity refers to how closely an artefact represents the proposed product. It has several dimensions. Visual fidelity concerns colour, typography, imagery, and spacing. Functional fidelity concerns the realism of interactions and system responses. Content fidelity concerns whether actual or realistic content is used. Data fidelity concerns the realism of data, validation, loading, and error conditions. A prototype may have high visual fidelity but low functional fidelity, or the reverse. Treating fidelity as a single scale can therefore lead to poor decisions.

The appropriate question is not, “How polished should this prototype be?” but, “What degree of realism is necessary to answer the present question?” A high-fidelity prototype is wasteful when the information architecture is still uncertain. Conversely, a very rough wireframe may be inadequate when testing form completion, visual hierarchy, or stakeholder understanding of a regulated workflow.

Wireframing as Structural Reasoning

Wireframing externalises the structure of an interface. It helps a team reason about what must be present, what can be omitted, and how elements relate. A good wireframe communicates hierarchy rather than decoration. It should make clear the primary task, the relationship between sections, the expected sequence of actions, and the response to important user decisions.

Wireframes commonly represent:

• page or screen regions;
• headings and content hierarchy;
• navigation and wayfinding;
• primary and secondary actions;
• forms, input requirements, and validation locations;
• empty, loading, success, and error states;
• responsive changes across viewport sizes;
• annotations about behaviour, accessibility, or technical dependencies.

Placeholder content must be used carefully. A box labelled “text” may hide problems caused by a long heading, translated content, an unusually large price, or a user-generated comment. Where content length affects layout or decision-making, realistic content should be introduced early. Similarly, a single ideal image does not test the behaviour of missing, cropped, or slow-loading media.

Wireframes should represent more than the happy path. For example, a registration flow should consider invalid email addresses, duplicate accounts, password requirements, interrupted sessions, and accessible error communication. A dashboard should consider no data, partial data, permission restrictions, and delayed data. Failure to represent these states often transfers design decisions silently to developers, producing inconsistent experiences.

Responsive Wireframing

Responsive design is not simply the production of a desktop design and a smaller mobile version. It is the definition of rules by which content and interaction adapt to changing conditions. Wireframes should therefore express relationships and behaviour, such as:

• whether a two-column layout becomes one column;
• which controls remain visible and which move into an overflow menu;
• whether a table scrolls, transforms into cards, or prioritises columns;
• how navigation changes at a breakpoint;
• how touch targets, text wrapping, and form controls behave;
• what happens when the viewport is narrow but the content is long.

Breakpoints should be derived from content and interaction needs rather than from a device list alone. A wireframe specification can describe a fluid layout, minimum and maximum widths, wrapping rules, and the point at which a structural change occurs. This approach gives developers principles rather than a collection of disconnected screenshots.

Accessibility in Wireframes

Accessibility must be considered before visual styling is complete. Wireframes can identify heading order, keyboard focus sequence, labels, instructions, error placement, alternative text requirements, and the relationship between inputs and messages. They can also flag interactions that depend only on hover, drag, colour, or precise motor control.

A wireframe need not reproduce every accessibility implementation detail, but it should make accessibility-relevant decisions visible. For example, an error message should be shown near the relevant field and in a summary when appropriate; a modal should show focus entry and exit behaviour; a chart should indicate how information will be conveyed to users who cannot perceive colour or graphical form.

Prototyping Methods and Their Appropriate Use

Different prototyping methods answer different questions. Method selection should be based on uncertainty, risk, audience, time, and the cost of change.

Paper and Collaborative Sketching

Paper prototypes are useful during early exploration, workshops, and participatory design. A facilitator can change screens manually as a participant points, taps, or speaks. The method is inexpensive and communicates that the design is provisional. It is particularly effective for comparing navigation structures and broad task flows.

Its limitations include weak representation of scrolling, responsive behaviour, timing, visual hierarchy, and realistic content. Participants may also hesitate to criticise a paper design if they believe it represents a personal effort. The facilitator should explain that the prototype, not the participant, is being tested.

Click-Through Prototypes

A click-through prototype links screens or regions to simulate a task. It is appropriate for testing navigation, sequence, labels, and basic interaction logic. It can be created quickly from wireframes and is often sufficient for stakeholder reviews.

Click-through prototypes can create a false impression of completeness. A clickable button may lead to a screen without demonstrating what happens during loading, validation, cancellation, or failure. Important unsupported behaviours should be labelled rather than silently implied.

High-Fidelity Interaction Prototypes

High-fidelity prototypes use realistic content, visual styling, transitions, responsive layouts, and more detailed states. They are useful when evaluating comprehension, brand expression, form behaviour, animation, perceived performance, or complex stakeholder requirements. They can also support demonstrations and implementation planning.

Their risk is premature commitment. Stakeholders may focus on colour and typography while fundamental problems remain. High-fidelity work also tends to be expensive to revise, especially when it includes many screens and states. Teams should not treat polish as evidence of validity.

Coded Prototypes

A coded prototype is built with HTML, CSS, JavaScript, a component framework, or a small experimental application. It is appropriate when feasibility, performance, real responsive behaviour, browser constraints, device APIs, or complex interaction logic are central questions. For a full-stack development programme, coded prototyping is especially valuable where the design depends on actual data, authentication, asynchronous operations, or reusable components.

A coded prototype must be clearly distinguished from production code. If it is likely to evolve into the product, quality practices should be introduced early. If it is disposable, the team should avoid allowing prototype shortcuts to become permanent architecture. A lightweight coded experiment may answer a technical question more reliably than a visually precise design-tool simulation.

Wizard-of-Oz and Service Prototypes

In a Wizard-of-Oz prototype, a human secretly performs functions that are not yet automated. For example, a service representative may manually generate recommendations while the participant believes an automated system is responding. This method is useful for evaluating value, language, and workflow before investing in backend automation. It requires transparency at the appropriate stage and must not expose participants to misleading or consequential decisions.

Service prototypes extend beyond the screen to include staff actions, notifications, policies, and physical or organisational touchpoints. They are useful when a digital interface depends on human support, approval, fulfilment, or escalation.

Design Tools as Collaborative Environments

A design tool is not merely a place to draw screens. It is an environment for creating, inspecting, commenting on, versioning, presenting, and handing over design knowledge. Contemporary tools commonly provide vector editing, reusable components, constraints, prototyping links, design tokens, collaborative comments, asset inspection, and developer-oriented specifications.

Tool selection should follow the work rather than personal preference. Relevant criteria include:

• suitability for the fidelity and interaction being tested;
• support for responsive constraints and reusable components;
• accessibility of the tool and its exported artefacts;
• collaboration, permissions, version history, and review features;
• support for realistic data, variables, and states;
• integration with code repositories, issue trackers, and documentation;
• export quality and inspectability for developers;
• handling of confidential or personal information;
• cost, licensing, training, and organisational continuity.

A shared design file needs an information architecture of its own. Pages or sections may separate exploration, approved flows, components, research evidence, and archived alternatives. Frames should have meaningful names, related screens should be grouped, and status should be visible. Unlabelled duplicates create uncertainty about which design is authoritative.

Components, Patterns, and Tokens

Reusable components reduce inconsistency and accelerate iteration. A component may define a button, input, navigation item, card, dialog, or larger composition. Variants represent meaningful states such as default, hover, focus, disabled, loading, error, or selected. Components should be designed around behaviour and content conditions, not only appearance.

A pattern library records recurring solutions, while a design system connects principles, components, tokens, content guidance, accessibility rules, and implementation. Tokens represent decisions such as colour roles, spacing scales, typography levels, border radii, and motion preferences. They improve consistency and make broad changes more manageable.

However, component reuse should not become a rigid constraint. A component that does not support a genuine content or interaction requirement may force users into an unsuitable pattern. Teams should distinguish between a reusable standard and a justified exception, documenting the reason for the latter.

Documenting Design Rationale

A design artefact without rationale is difficult to evaluate and maintain. Design rationale records why a decision was made, what evidence informed it, which alternatives were considered, and what remains uncertain. It protects teams from repeatedly reopening settled decisions while allowing new evidence to change them.

A concise decision record may contain:

• Decision: the selected design approach;
• Context: the user, business, technical, or regulatory problem;
• Options considered: credible alternatives rather than straw-man choices;
• Evidence: research findings, analytics, accessibility review, technical tests, or stakeholder requirements;
• Trade-offs: benefits, costs, risks, and groups affected;
• Status: proposed, accepted, rejected, or requiring validation;
• Owner and date: who made or approved the decision;
• Review trigger: what new evidence would justify reconsideration.

Annotations should be specific. “Make responsive” is not a useful instruction. “At widths below the content threshold, move filters into a disclosure panel; preserve the active-filter summary above results” communicates behaviour. Similarly, “accessible” is not a sufficient annotation; the design should identify focus order, label relationships, keyboard operation, and message behaviour where relevant.

Stakeholder Reviews and Usability Evaluation

Stakeholder review and user evaluation serve different purposes. Stakeholders assess organisational goals, operational constraints, legal obligations, feasibility, and alignment with strategy. Users reveal whether the proposed experience is understandable, efficient, and appropriate in context. Neither group can substitute for the other.

A productive review begins with explicit objectives. A session might ask whether users can locate an account statement, whether a policy officer can approve an exception, or whether developers understand the responsive rule. It should not ask participants to judge everything simultaneously.

A review process can include the following sequence:

1. State the purpose, scope, fidelity, and known limitations of the prototype.

2. Provide a realistic scenario and task rather than describing the intended solution.

3. Observe behaviour and reasoning before explaining the design.

4. Record evidence separately from opinions and proposed solutions.

5. Classify findings by severity, frequency, confidence, and affected users.

6. Decide whether to fix, investigate, accept, or defer each issue.

7. Update the prototype, rationale, requirements, and backlog.

During usability evaluation, neutral prompts are preferable to leading questions. “What would you do next?” is more informative than “Would you click this button?” A facilitator should avoid rescuing participants too quickly. At the same time, the session must not become an examination; the prototype is being tested, not the participant.

Remote reviews introduce additional considerations, including screen-sharing quality, privacy, participant fatigue, and the difference between observing a participant’s device and observing a prototype in a design tool. A prototype should be tested at realistic viewport sizes and, when possible, with keyboard and assistive technologies rather than only through a designer’s presentation mode.

The Design-to-Development Handoff

Handoff is not a single export event. It is a transfer of understanding that should occur continuously through collaboration. Developers should be involved early when technical feasibility, data structures, browser behaviour, or component architecture may influence the design.

A useful handoff package includes:

• the approved user and system flows;
• responsive layouts and behavioural rules;
• component definitions and states;
• content, assets, and licensing information;
• interaction specifications, including focus, loading, validation, and error states;
• accessibility requirements and test expectations;
• design tokens or style references;
• assumptions, dependencies, open questions, and known deviations;
• links to relevant research, decisions, and acceptance criteria.

Developers need to know what is essential and what is illustrative. For example, a transition may be decorative, whereas a confirmation message may be essential to task completion. Requirements should be expressed in implementation-neutral language where possible, but technical constraints should be acknowledged where they affect the experience.

Designers and developers should agree on a process for resolving discrepancies. A coded implementation may reveal that a proposed animation harms performance or that a table cannot remain usable at a narrow width. Such findings are design evidence, not simply implementation failure. The team should revise the design rationale and acceptance criteria rather than silently diverging from the approved prototype.

Illustrative Case Study: Redesigning a University Fee-Payment Portal

Background

A fictional university plans to redesign its fee-payment portal. Students currently report difficulty understanding outstanding balances, locating payment options, and recovering from failed transactions. The university also needs a responsive interface because many students use mobile devices. Finance staff require a clear record of payment status, while the development team must integrate an existing payment service.

Situation and Problem

The initial request is framed as “create a modern payment dashboard.” This statement is too vague to guide design. Early interviews and support-ticket analysis identify several uncertainties: students confuse total fees with the amount currently due; international students need different payment methods; failed transactions are not always distinguishable from delayed confirmation; and some students use keyboard navigation or screen readers.

Analysis

The team maps the end-to-end journey from viewing an account balance to receiving confirmation. It identifies high-risk points: interpreting financial information, selecting a payment method, entering sensitive data, and understanding transaction status. Rather than immediately creating a polished dashboard, the team produces paper sketches of three information structures: a balance-first view, a task-oriented payment view, and a combined account timeline.

A review with students and finance staff shows that the balance-first structure is preferred only when the amount due is clearly separated from the total annual fee. The team also discovers that a visual status indicator alone is insufficient; users need plain-language explanations and a reference number.

Approach and Solution

The team creates low-fidelity wireframes for desktop and mobile. The mobile version does not simply shrink the desktop layout: payment actions remain prominent, secondary fee details move into expandable sections, and the transaction history becomes a vertically ordered list. Error and pending states are represented explicitly.

A mid-fidelity clickable prototype tests the following tasks: finding the amount due, selecting an international payment method, cancelling a payment, and interpreting a pending transaction. A separate coded prototype tests the payment-service response, including delayed confirmation and retry behaviour. Accessibility checks examine heading order, keyboard focus, field labels, and error announcements.

The design rationale records why the amount currently due is visually prioritised, why the payment button is not shown as successful until confirmation is received, and why a pending state offers a clear next step rather than an immediate retry. Finance staff review the operational implications, while developers inspect component states and responsive rules.

Outcome

The resulting design is not accepted because it looks modern; it is accepted because the major uncertainties have been reduced. Students can distinguish current obligations from historical information, and staff can explain transaction states consistently. The handoff includes component states, content rules, accessibility requirements, and test cases for delayed and failed responses. Several visual details remain open for later refinement because they do not affect the core payment risk.

Learning Points

The case demonstrates that prototyping should focus on uncertainty and consequence. It also shows why realistic content and failure states matter, why responsive design requires behavioural rules, and why a coded experiment may be necessary when external service behaviour affects the interface. Most importantly, the prototype functions as a shared reasoning object among students, finance staff, designers, and developers.

Challenges, Risks, and Common Mistakes

One frequent mistake is producing too many screens without identifying the question each screen is intended to answer. This creates activity without learning. A related problem is prototype theatre: a polished demonstration gives the impression of progress while unresolved assumptions remain hidden.

Another risk is false precision. Exact spacing, colour, and animation can imply that decisions are final when they are still exploratory. Conversely, excessive abstraction can conceal content, accessibility, or technical problems. The remedy is to state the prototype’s purpose and limitations explicitly.

Teams also commonly prototype only the ideal path. This leads to incomplete requirements and inconsistent implementation of errors, permissions, empty states, and interrupted sessions. Other mistakes include using unrealistic placeholder text, omitting responsive behaviour, failing to test keyboard use, maintaining multiple contradictory versions, and treating stakeholder preference as evidence of user success.

Tool dependence presents organisational risk. A team may lose access to files through licensing changes, staff turnover, or poor permission management. Confidential data placed in cloud tools may create privacy and contractual issues. Exported assets may also carry licensing restrictions. Version history, access control, data minimisation, and archival procedures should therefore be part of design governance.

Ethical and Professional Considerations

Prototypes can influence investment decisions, policy choices, and perceptions of feasibility. Designers should not present an untested concept as validated evidence. Participants must understand the purpose of research, the handling of recordings, and any limits of confidentiality. Sensitive financial, health, educational, or personal data should not be copied into prototypes unless necessary and appropriately protected; synthetic or anonymised data is usually preferable.

Designers have a professional duty to consider people who are absent from stakeholder meetings, including users with disabilities, limited connectivity, low digital confidence, language differences, and constrained devices. A prototype that works only in a controlled demonstration may reproduce exclusion at scale.

Artificial intelligence can assist with generating alternative layouts, summarising comments, producing sample content, checking consistency, or translating design tokens into code. These uses require human review. AI-generated suggestions may encode bias, violate confidentiality, invent requirements, or produce inaccessible interactions. Teams should record when automation materially influences a design decision and should not use generated output as a substitute for user research or accountable professional judgement.

Emerging Practice

Design and development tools are increasingly converging. Variables, design tokens, component libraries, code connections, and shared repositories can reduce the distance between design and implementation. Browser-based testing and automated checks can expose contrast, label, focus, and responsive issues earlier, although automated checks cannot establish overall usability or inclusion.

Generative systems are also changing the speed of exploration. They can produce multiple layout hypotheses or transform structured requirements into preliminary screens. The important professional skill is shifting from drawing every possibility to framing the right problem, evaluating alternatives, protecting user interests, and maintaining traceability from evidence to decision.

Future-facing teams will therefore treat prototypes as versioned, inspectable models rather than disposable pictures. A mature workflow connects research findings, design decisions, component specifications, code, test evidence, and later product analytics. This creates a feedback loop in which the implemented product can challenge assumptions made during prototyping.

Best Practices for Professional Work

Effective wireframing and prototyping can be guided by several principles:

• Begin with a question, risk, or decision, not with a preferred tool.
• Choose the lowest fidelity that can answer the question reliably.
• Increase fidelity selectively where realism affects behaviour or judgement.
• Use realistic content and represent loading, empty, permission, success, and failure states.
• Treat responsive behaviour and accessibility as structural requirements.
• Involve developers, content specialists, operations staff, and affected users early.
• Keep alternatives and decisions traceable, with owners and review triggers.
• Maintain a clear source of truth and archive obsolete versions.
• Distinguish evidence, interpretation, preference, and unresolved assumption.
• Handoff behaviour, states, constraints, and rationale—not only visual files.
• Validate important interactions in the browser and with relevant assistive technologies.
• Use automation to support professional judgement, never to conceal uncertainty or remove accountability.

Chapter Summary

Wireframes and prototypes are progressive representations used to explore, communicate, evaluate, and implement digital experiences. Sketches and low-fidelity wireframes support rapid structural reasoning, while high-fidelity and coded prototypes address questions about visual hierarchy, behaviour, responsive layout, performance, and technical feasibility. Fidelity should be selected according to the question being investigated rather than treated as a measure of design quality.

Professional practice requires modelling realistic content and non-ideal states, documenting rationale, incorporating accessibility, and treating responsive behaviour as a set of rules rather than a collection of device screenshots. Design tools support collaboration, components, tokens, versioning, and developer inspection, but tool features do not replace sound judgement. Stakeholder reviews, usability evaluation, and developer collaboration should be structured around explicit objectives and evidence.

A successful handoff communicates flows, states, constraints, assets, accessibility expectations, decisions, and open issues. Ethical practice requires honest claims about validation, protection of sensitive data, inclusive consideration, and responsible use of automation and AI. The central professional principle is to prototype in order to learn, and to preserve that learning throughout implementation.

Key Terms

Wireframe: A structural representation of an interface showing hierarchy, layout, content regions, and controls.

Prototype: A representation of a proposed product or service used to explore or evaluate experience and behaviour.

Fidelity: The degree to which a representation resembles the intended product in visual, functional, content, or data characteristics.

Sketch: A rapid, low-cost drawing used to explore an idea.

Mock-up: A mainly static representation of visual appearance and branding.

Click-through prototype: An interactive sequence of linked screens used to simulate navigation and task flow.

Coded prototype: A prototype implemented with software technologies to test realistic behaviour or feasibility.

Responsive design: An approach in which layout and interaction adapt to viewport, content, and device conditions.

Breakpoint: A condition at which a responsive layout changes its structure or behaviour.

Design rationale: A record of the context, evidence, alternatives, trade-offs, and reasoning behind a design decision.

Component: A reusable interface element defined by appearance, behaviour, content, and states.

Design system: A coordinated collection of principles, tokens, components, patterns, guidance, and implementation references.

Design token: A named value representing a reusable design decision, such as a colour role or spacing unit.

State: A condition of an interface element or system, such as loading, focused, disabled, empty, or error.

Stakeholder review: A structured assessment by people responsible for organisational, operational, technical, or strategic concerns.

Usability evaluation: An investigation of how effectively and understandably representative users perform tasks.

Handoff: The continuing transfer of design intent, specifications, assets, constraints, and rationale to implementation teams.

Wizard-of-Oz prototype: A prototype in which a human performs an apparently automated function to test a proposed experience.

Fidelity mismatch: A situation in which one dimension of realism, such as visual appearance, is high while another, such as functional behaviour, remains low.

Review Questions

Short Answer Questions

1. How does a wireframe differ from a mock-up?

2. What is meant by functional fidelity?

3. Why should responsive wireframes express rules rather than only screen sizes?

4. Identify four interface states that should commonly be represented in a prototype.

5. What information should a design-rationale record contain?

Long Answer Questions

1. Explain how a design team should progress from sketches to a high-fidelity or coded prototype. Relate the choice of fidelity to uncertainty and risk.

2. Discuss the role of components, variants, design tokens, and design systems in collaborative prototyping and developer handoff.

3. Describe a structured process for conducting a stakeholder review and a usability evaluation. Explain why the two activities should not be treated as identical.

4. Analyse the requirements of an effective design-to-development handoff, including responsive behaviour, accessibility, assets, states, and open issues.

5. Examine the ethical and professional responsibilities involved in using cloud-based design tools and artificial intelligence in prototyping.

Analytical / Application Questions

1. A team has produced a visually polished mobile banking prototype, but it shows only successful transfers. Identify the risks and propose a revised prototyping plan.

2. A product must support a complex data table on desktop and mobile. Explain how you would investigate alternative responsive behaviours using wireframes, user evaluation, and a coded prototype.

3. A stakeholder insists on adopting a design because it “looks more modern,” although users have not tested it. Explain how you would structure the decision, what evidence you would seek, and how you would document the outcome.

22. Multiple Choice Questions with Answers

Question 1

A team is uncertain whether users understand the relationship between an annual fee and the amount currently due. Which prototype is most appropriate as an initial investigation?

A. A fully animated production-like prototype with final branding

B. Several low-fidelity wireframes comparing alternative information structures

C. A coded payment integration with real student data

D. A final design-system documentation page

Correct Answer: B. Several low-fidelity wireframes comparing alternative information structures

Question 2

Which statement best describes fidelity in prototyping?

A. It is a single scale determined only by visual polish

B. It refers only to how closely the prototype matches the final colour palette

C. It includes dimensions such as visual, functional, content, and data realism

D. It is the number of screens included in a prototype

Correct Answer: C. It includes dimensions such as visual, functional, content, and data realism

Question 3

A mobile layout changes from two columns to one because the content can no longer be read comfortably. This is an example of a breakpoint based primarily on:

A. A fixed list of popular devices

B. Content and interaction requirements

C. The number of designers on the project

D. The file size of the prototype

Correct Answer: B. Content and interaction requirements

Question 4

Which practice most directly improves the usefulness of a developer handoff?

A. Providing only screenshots of the ideal path

B. Removing annotations so developers can interpret the design freely

C. Documenting states, responsive rules, accessibility requirements, and open questions

D. Exporting every layer as a separate image

Correct Answer: C. Documenting states, responsive rules, accessibility requirements, and open questions

Question 5

During a usability session, which facilitator prompt is least leading?

A. Would you click the blue button now?

B. You can use the menu to find your statement.

C. What would you do next?

D. Do you agree that this layout is clearer?

Correct Answer: C. What would you do next?

Question 6

A prototype uses realistic colours and typography but all buttons lead to static screens and no error states are represented. It has relatively high:

A. Visual fidelity but low functional and state fidelity

B. Functional fidelity but low visual fidelity

C. Data fidelity but no visual fidelity

D. Accessibility fidelity by definition

Correct Answer: A. Visual fidelity but low functional and state fidelity

Question 7

What is the principal purpose of a design-rationale record?

A. To prevent any future change to the design

B. To document the evidence, alternatives, trade-offs, and reasoning behind a decision

C. To replace usability testing with stakeholder approval

D. To list only the names of design-tool features used

Correct Answer: B. To document the evidence, alternatives, trade-offs, and reasoning behind a decision

Question 8

A team wants to test whether a proposed recommendation service is valuable before building its automation. Which method may be most suitable?

A. Wizard-of-Oz prototyping

B. Deleting all user research

C. A colour-contrast checker alone

D. A static asset export

Correct Answer: A. Wizard-of-Oz prototyping

Question 9

Which situation represents prototype theatre?

A. A rough sketch is used to compare navigation alternatives

B. A coded experiment tests browser performance

C. A polished demonstration conceals unresolved assumptions and gives a false impression of validation

D. A component library records loading and error variants

Correct Answer: C. A polished demonstration conceals unresolved assumptions and gives a false impression of validation

Question 10

Why should AI-generated interface suggestions be reviewed by accountable professionals?

A. AI output is always too slow to use in design tools

B. Generated suggestions may encode bias, expose confidential information, or produce inaccessible interactions

C. AI cannot generate any visual alternatives

D. Review is unnecessary when a prototype looks attractive

Correct Answer: B. Generated suggestions may encode bias, expose confidential information, or produce inaccessible interactions