Prototype
Prototype
What is a prototype?
- A mock-up for testing ideas
- The goal is learning, not finishing
- Build it cheap and fast, and learn early
What a prototype really changes is not the deliverable but the nature of the meeting. With nothing in front of the group, discussion becomes a clash of “I think” versus “in my experience,” and the taste of the loudest or most senior person hardens into the conclusion. Put one clickable screen on the table and the debate shifts from taste to observation, because where users stopped and what they couldn’t find stays on record as evidence. That is why organizations fluent in prototyping measure progress by the number of validations, not the page count of the plan.
Choose the form based on the question you need answered. If you are asking “does this flow make sense?”, paper or slides are enough and take half a day. Only when you reach “is the button placement confusing?” do you need a mockup close to the real product. A Wizard of Oz setup, where people handle things by hand behind the scenes so it looks automated, and a sign-up page launched with no service behind it to gauge interest, are both prototypes too. The test is not polish but whether you can throw it away. If you are not ready to discard it, it is already a development deliverable with a delivery deadline, not a learning tool.
In Korean organizations, prototyping breaks down because of the schedule, not the tools. If you can’t keep one build-show-fix cycle within 2 weeks, it stops being validation and becomes yet another small development project. User observation doesn’t need statistical representativeness either: watching just 5–8 people per job function use the product for real usually surfaces the problems that repeat. The teams that follow the rule of testing one hypothesis at a time end up moving fastest. Now that AI tools let a planner put up a working screen in a day, the bottleneck is no longer build speed but sharpening “what to ask.”
The most common failure in practice is treating a prototype as a “small finished product.” After two weeks spent polishing colors and fonts because it was “for the report,” teams hear “but we’ve built this much” even when testing exposes a fatal flaw. This is the moment a validation tool turns into a sunk cost. The opposite is also common: executives see a rough draft and take offense at being shown something so unpolished. That friction comes from never agreeing in advance on what the prototype is meant to test. It is also not rare for code hastily written for validation to go straight into production under deadline pressure, only to be paid back as years of technical debt.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”The word comes from the Greek for “original form.” The manufacturing idea of a test model spread into software and design, and it became standard business vocabulary largely through the design thinking methodology popularized by Stanford’s d.school and IDEO, where prototyping is the key step for testing ideas.
Consider a hypothetical case. The four-person training team at Company A, a food manufacturer with 900 employees, was about to request a KRW 300 million (≈ US$224,500) budget for a mobile learning app for frontline workers. The e-learning rollout before it had reached a completion rate of only 31% among field staff, so executives held off on approval, asking, “Won’t they just ignore this one too?” Instead of starting development, the training team decided to run a three-week prototype test first.
- In the first meeting, Team Lead Kim pinned down the validation question in one line: “What we don’t know isn’t whether the app looks good. It’s whether shift workers actually want to watch a five-minute video in the break room.”
- Assistant Manager Park, with no developer, built a clickable prototype from 12 slides in two days, so people could tap through everything from login to watching a video to confirming completion.
- We observed eight people from three job groups (production, logistics, and sales) one at a time for 30 minutes each. Six stalled at login, muttering “what was my employee ID?” and not a single person tapped the learning community tab.
- Without building any recommendation feature, Assistant Manager Park spent two weeks sending a video link by KakaoTalk every morning at 7 a.m., by hand, and tracked open rates. Links sent 30 minutes before shift start got three times the click rate of those sent in the evening.
- Based on these results, Company A dropped the community feature and switched login to phone-number verification. It cut its development budget from KRW 300 million (≈ US$224,500) to KRW 140 (≈ US$1) million, and six months later completion among field staff rose from 31% to 78%.