For prototypes on a car-rental site, how would you set fidelity to learn whether customers understand vehicle classes and whether a map-based pick-up search feels fast?
answer
- one question, one prototype
- which dimension does it depend on?
- classes: real content, rough looks
- speed: real timing, real data
- instant screens flatter the idea
basics
~20 sSplit the questions. Vehicle-class comprehension depends on real content, so a greyscale layout with real class data suffices; perceived search speed depends on interaction and timing, so it needs a coded slice with realistic data and delays.
solid answer
~50 sI would not build one polished prototype for both, because they depend on different fidelity dimensions. **Understanding vehicle classes** is a content question: people need real class names, example models, seat and luggage capacity and prices, so **content fidelity** must be high — but the layout can stay greyscale and static, even on paper, with tasks like “pick a car for four adults and three large bags”. **Whether a map search feels fast** is an interaction and timing question: paper cannot show perceived speed, and a linked-screens prototype flatters it because screens change instantly. That needs a **narrow, deep coded slice** — a vertical prototype — with realistic location data, panning and zooming, and **realistic delays**, while everything outside the search stays rough or absent. Each prototype is as cheap as its question allows, and neither result is distorted by fidelity the other needed.
go deeper
Recall that different questions need different prototypes, and that real content matters when the question is about understanding.
Explain which fidelity dimensions each question depends on, and the difference between horizontal and vertical prototypes.
Demonstrate decomposing research questions into fidelity needs, spotting false positives such as instant linked screens, and keeping each prototype disposable.
Decide how prototyping effort is budgeted across a roadmap's open questions, so the riskiest assumptions get the fidelity they need first.
## Start from the questions, not the prototype The tempting move is to build one high-fidelity prototype of the whole booking experience and test everything at once. That is expensive, slow to change, and it distorts both answers: polish attracts surface feedback on one question, while shortcuts in behaviour mislead on the other. The senior move is to **decompose**: for each research question, ask which **fidelity dimensions** it actually depends on, raise only those, and keep everything else cheap. | Dimension | Vehicle-class comprehension | Map search feels fast | |---|---|---| | Visual | Low — greyscale is fine | Low to medium — a real map tile helps | | Content | **High** — real classes, models, capacities, prices | Medium — real location names and density | | Interaction | Low — static or simple links | **High** — pan, zoom, search, select | | Timing | Irrelevant | **High** — realistic response delays | | Breadth | One results page | One flow only | | Depth | Surface | **Deep** — the search works end to end | ## Question 1: do customers understand vehicle classes? This is a **comprehension** question. Class labels such as “compact”, “intermediate” and “full-size” mean little on their own; people choose by whether their passengers and luggage fit and what it costs. - **Content must be real**: actual class names, example models, seat counts, luggage capacity, prices and any restrictions. - **Visuals can stay rough**: a greyscale layout, even a printed page, keeps attention on the information. - **Interaction can be minimal**: a static results page, or a few linked screens for a details view. - **Tasks reveal understanding**: “choose a car for four adults and three large suitcases” shows whether people can map needs to classes; asking “is this clear?” does not. A polished version here would mostly produce opinions about imagery and button colour. ## Question 2: does the map-based pick-up search feel fast? This is a **perception of behaviour** question, and it depends on things low-fidelity prototypes cannot fake well. - **Paper cannot show it**: a person swapping sheets sets the pace, so speed is unmeasurable. - **Linked screens flatter it**: screens change instantly, hiding the real waits for location results, map tiles and availability. A test would overstate how fast the real product feels. - **A narrow, deep coded slice fits**: a **vertical prototype** that implements just the search — real or realistic location data, genuine panning and zooming, the actual result-loading pattern — built as a throwaway. - **Timing must be realistic**: simulate the response times the real services are expected to have, including slower cases, so the feel is honest. - **Everything else stays out**: no booking flow, no styling beyond what makes the map legible. ## Why not one prototype for both? 1. **Cost**: a single prototype high on every dimension costs more than two focused ones. 2. **Contamination**: polish added for one question biases feedback on the other. 3. **Speed of change**: the comprehension prototype may go through several content revisions in a day; the coded slice cannot keep up. 4. **Clarity of findings**: when a focused prototype fails, the team knows which dimension caused it. ## Horizontal and vertical prototypes A **horizontal** prototype is broad and shallow — many features, none working fully — and suits questions about overall navigation and scope. A **vertical** prototype is narrow and deep — one feature working end to end — and suits questions about how that feature behaves. The map search is a vertical question; a first look at the whole site's scope would be horizontal. ## What the senior answer demonstrates - It names the **dimensions** each question depends on rather than picking one fidelity level. - It spots where a cheap prototype would give a **false positive** — instant linked screens making a slow search look fast. - It keeps each prototype **disposable**, so the team learns quickly and no demo gets mistaken for the product. The same decomposition applies whether the car-rental product is a website, a native mobile app or both: on a phone, touch gestures and network variability make the timing dimension matter even more.
- What is a false positive from a low-fidelity prototype, and how do you avoid it?A result that looks good only because the prototype hid a real constraint — linked screens that change instantly make a slow search seem fast, fake data never shows a sold-out class. Avoid it by asking which real constraints the question depends on and simulating those honestly, such as realistic delays and messy data.
- Would you ever test both questions in one prototype?Only when both are low-risk and the dimensions they need happen to coincide, or late in the project when a near-production build exists anyway. Early on, separate focused prototypes are cheaper, change faster and make it clear which dimension caused a problem.
- Should the coded search slice be throwaway or evolutionary?Usually throwaway: its job is to answer whether the approach feels fast enough, and it can cut corners elsewhere. If the direction is validated, the real build starts from production standards, reusing the learning about data loading and interaction rather than the prototype's code.
saying these in an interview costs you the question
- Build one high-fidelity prototype of the whole flow to answer every question.
- A click-through prototype shows how fast the real search will feel.
- Content can stay placeholder until visual design is finished.
- Asking participants whether the vehicle classes are clear tests comprehension.
- Paper prototypes can measure perceived speed if the facilitator moves quickly.