Prototyping and iterative testing notes — Unit 4

Prototyping is the iterative generation of artifacts intended to answer questions that get you closer to your final solution. It is the process of getting ideas out of your head and into the physical world.

⇒1.1 The Philosophy

'Build to think.' A prototype is not just a way to validate an idea; the physical act of building the prototype creates new ideas and reveals constraints you couldn't see in your head.

Fidelity refers to how closely the prototype matches the final, polished product.

• Low-Fidelity (Lo-Fi): Cardboard, paper sketches, post-it notes, tape. Very cheap, very fast. Used in the early stages to test broad concepts.
• High-Fidelity (Hi-Fi): Interactive digital mockups (Figma), 3D-printed models, coded UI. Expensive, slow. Used in late stages to test specific usability details.

The Golden Rule: Spend as little time and money as possible to build a prototype that answers your specific assumption. Do not build a Hi-Fi prototype to test a Lo-Fi assumption.

Beginners often rush to build high-fidelity digital prototypes because they look professional. This is a massive mistake.

⇒3.1 The Sunk Cost Fallacy

If you spend 3 weeks coding a beautiful app, you fall in love with it. When a user says 'I don't like this', you will get defensive and argue with them. If you spent 5 minutes drawing it on a napkin, you will happily throw the napkin in the trash and draw a new one.

⇒3.2 User Intimidation

If you show a user a highly polished, beautiful prototype, they will focus on the colors and fonts, and they won't want to hurt your feelings by saying the core idea is bad. If you show them a rough paper sketch, they know it's a work-in-progress and will give you brutal, honest feedback.

The standard way to prototype mobile apps or websites in Design Thinking.

⇒4.1 The Method

• Draw a phone frame on a piece of paper.
• Draw the UI elements (buttons, images) on small, separate pieces of post-it notes.
• Place the post-its on the phone frame.
• When the user 'taps' a paper button with their finger, the designer manually swaps the paper screen to the next state, acting as the 'computer'.

This tests the user flow (information architecture) perfectly without writing a single line of code.

Used to test highly complex technological systems (like AI, Voice Recognition, or complex algorithms) without actually building the technology.

⇒5.1 How it works

The user interacts with an interface that looks fully functional and automated. However, behind the curtain, a human is manually doing the work.

Example: In the 1980s, IBM wanted to test if people would use a speech-to-text typewriter. Instead of spending millions inventing voice recognition software, they put users in a room with a microphone and a screen. In the next room, a fast typist listened to the microphone and typed the words onto the user's screen. IBM learned the real user behaviors instantly.

Similar to Wizard of Oz, but the user knows a human is doing the work.

⇒6.1 The Application

Used to test service-based or highly personalized app concepts.

Example: You want to build an AI app that curates personalized weekly meal plans based on grocery store discounts. Instead of building the AI, you personally text 10 users every Sunday with a hand-crafted meal plan and ask if they like it. You act as the concierge to prove the value proposition exists.

Used for hardware, industrial design, and physical spaces.

⇒7.1 Materials

Cardboard, duct tape, foam core, pipe cleaners, and Lego are the staples of a design studio.

⇒7.2 Example: The Palm Pilot

Before manufacturing the first Palm Pilot, the inventor carved a block of wood to the exact dimensions of the device. He carried this block of wood in his pocket for a month, taking it out to pretend to use it, just to see if the form-factor was comfortable and socially acceptable. A zero-dollar prototype.

Testing is the mode where you solicit feedback about the prototypes you have created from your users. It is the most critical learning phase.

⇒8.1 Rule #1: Show, Don't Tell

Put the prototype in the user's hands. Do not explain how it works. Do not defend it. Say, 'Here is a prototype, please try to complete [Task X]', and then step back and shut up.

If they click the wrong button, let them fail. Watch their frustration. If you step in and say 'Oh, you need to click the blue button', you have ruined the test.

The gold standard technique for usability testing.

⇒9.1 The Process

As the user interacts with your prototype, you force them to narrate their internal monologue out loud. (e.g., 'Okay, I'm looking for the checkout button... I assume it's in the top right... no, it's not there... maybe under this menu?').

This reveals why a design failed, not just that it failed. It exposes the user's mental model and expectations.

During testing, you will receive chaotic, rapid-fire feedback. Use a 4-quadrant grid to organize notes in real-time.

• Top Left (+): What worked? (Things the user liked or found intuitive).
• Top Right (Δ): What needs to change? (Criticisms, failures, confusion).
• Bottom Left (?): Questions. (Questions the user asked, or questions the team now has).
• Bottom Right (Lightbulb): New Ideas. (Spontaneous new features or concepts sparked during the test).

A quantitative testing method used heavily in digital design once the product is live or in high-fidelity.

⇒11.1 How it works

You create two versions of a design (Version A has a red checkout button, Version B has a green checkout button). You route 50% of your live traffic to A, and 50% to B.

You measure which version results in higher conversions (purchases). This relies on statistically significant data, completely removing human opinion from the decision.

Before testing with real users, a UX expert evaluates the prototype against a set of established usability principles (Heuristics).

⇒12.1 Jakob Nielsen's Top 3 Heuristics

• Visibility of System Status: The user should always know what is going on (e.g., loading spinners).
• Match Between System and Real World: Use words and concepts familiar to the user, not engineering jargon.
• User Control and Freedom: Provide an 'Emergency Exit' (e.g., an undo button, or an easy way to cancel an action).

Coined by Eric Ries (The Lean Startup), the MVP is heavily tied to iterative testing.

⇒13.1 What is it?

The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

An MVP is NOT a broken, half-built product. It is a complete, functioning product that has been stripped of all non-essential features. (e.g., If the goal is transportation, the MVP is a skateboard, not a car with no engine).

During the testing phase, you may realize that your core assumptions (from the Define phase) were entirely wrong.

⇒14.1 The Pivot

A structured course correction designed to test a new fundamental hypothesis about the product, strategy, or engine of growth.

• Zoom-in Pivot: A single feature becomes the whole product. (e.g., Instagram started as a complex location app called Burbn, but users only used the photo-sharing feature, so they pivoted).
• Customer Segment Pivot: The product solves a real need, but for a completely different user base than originally planned.

Design Thinking does not end when the product ships. Launching is just another test on a massive scale.

⇒15.1 Build-Measure-Learn Feedback Loop

• Build: Turn ideas into products (Prototypes/MVPs).
• Measure: See how customers respond using data (A/B testing, Analytics).
• Learn: Pivot or Persevere based on the data.

The faster you can cycle through this loop, the more successful the product will be.

You must use both. Analytics will tell you that 80% of users abandon the cart on page 3. But only a Qualitative interview will tell you why they are abandoning it.

A common objection to testing is 'We don't have the time or budget to test 50 people.'

⇒17.1 The Mathematical Reality

Jakob Nielsen proved mathematically that testing with just 5 users will uncover 85% of all major usability problems in a design.

Adding more users yields diminishing returns (the 6th user just repeats what the first 5 already said). It is much better to run three small tests with 5 users (iterating in between) than one massive test with 15 users.

A human-centered design must work for all humans, including those with disabilities (visual, auditory, motor, cognitive).

⇒18.1 Key Considerations

• Color Contrast: Can colorblind users read the text?
• Screen Readers: Does the digital prototype use semantic HTML so blind users can navigate via audio?
• Keyboard Navigation: Can the entire app be used without a mouse for users with motor impairments?

Designing for accessibility often improves the experience for everyone (e.g., captions on videos help deaf users, but also help people watching in noisy environments).

A modern software testing technique bridging Design Thinking and DevOps.

⇒19.1 The Technique

You push the new feature to the live production server, but it is hidden behind a 'Feature Flag' (a toggle in the code). You only turn the flag on for 1% of your real users. You monitor their behavior and server loads. If it fails, you instantly toggle the flag off without affecting the other 99%.

Testing is not the end of the process; it is often a new beginning. The insights gathered during testing almost always force the team to loop backward:

• Loop to Prototype (to fix a minor UI bug).
• Loop to Ideate (the feature works, but users want a different feature instead).
• Loop to Define (the entire problem was misunderstood).

Embrace the loop. The next unit covers how to take the finalized, tested product and pitch it to the business world.