Your prototype needs this. Do you have it?

A prototype can look polished and still fail to answer the questions that matter.

Can users understand it without help? Does it solve a problem they actually have? Can your team build it at a reasonable cost? A prototype should help you learn before more time and money go into development.

I have seen teams focus on colors, screens, and surface details while leaving the main user problem untested. That approach creates a product that looks ready but gives little useful evidence.

A stronger prototype gives you clear signals.

Start with the problem

Before I review a prototype, I ask one simple question:

What decision should this prototype help us make?

You may need to learn whether users understand a new booking flow. You may want to test the size of a physical product. You may need to check whether a business customer would pay for a service. Each goal calls for a different type of prototype.

Write the main question in one sentence:

“We want to learn whether new users can complete the sign-up process without support.”

This sentence keeps the work focused. It also helps you decide what to test and what to leave out.

Check the user need

A prototype has value only when it connects to a real user need.

I look for signs that the team understands:

• Who will use the product
• What task they are trying to complete
• What makes that task difficult
• What they use today
• What could make them change their current habit

A short interview can reveal more than a long internal discussion. Ask people to describe the last time they faced the problem. Listen for actions, workarounds, delays, and frustrations. Avoid asking, “Would you use this?” People often give friendly answers that do not match their future behavior.

A better question is:

“How do you handle this today?”

Their answer gives you a starting point for your prototype.

Test the main action

A prototype does not need every feature. It needs the features that support the main user action.

For a food delivery app, that action may be placing an order. For a project management tool, it may be assigning a task. For a medical device concept, it may be adjusting a setting safely.

I suggest mapping the user path in a few steps:

1. What brings the user to the product?
2. What do they see first?
3. What choice do they make?
4. What happens after that choice?
5. What result do they expect?

If the path contains too many screens, unclear labels, or repeated decisions, users may struggle even when the design looks clean.

A simple paper sketch can expose this problem before a digital prototype is built.

Choose the right level of detail

A low-detail prototype works well when you are testing structure, wording, or user flow. It is quick to change and keeps attention on the task.

A high-detail prototype makes sense when you need to examine visual behavior, interaction details, or a physical form. It can help people understand how the final product may work, though it should not be treated as proof that the product is ready to launch.

I prefer to begin with the lowest level of detail that can answer the main question. More detail can be added after the basic path makes sense.

This reduces rework and gives users fewer distractions during a test.

Watch people use it

A useful test is not a presentation. It is an observation.

Give the participant a task and let them try to complete it. Avoid explaining each screen as they move through the prototype. If you guide them too much, you may test your explanation instead of the product.

Pay attention to:

• Where they pause
• What they expect to happen
• Which words they misunderstand
• Which actions they repeat
• When they ask for help
• What they ignore
• Whether they can describe the result afterward

I often ask participants to think aloud, though silence can also reveal useful behavior. A long pause may show that the next step is not clear. A quick click may show confidence, or it may show that the user is guessing.

Record the session only with permission. Keep notes tied to observed behavior rather than personal opinions.

Use clear success measures

A prototype test needs a simple way to judge the result.

You might track:

• Task completion
• Time spent on the task
• Number of wrong choices
• Requests for help
• User confidence after the task
• Reasons for stopping

Set the measure before testing. This prevents the team from changing its view after seeing the results.

For example, your test could use this standard:

“Four out of five target users complete the main task without guidance.”

That does not prove the product will succeed in the market. It tells you whether the tested flow is ready for another round of work.

Test with the right people

Feedback from colleagues can help with spelling, layout, and basic logic. It may not reflect the behavior of your target users.

Recruit people who share the key traits of your intended audience. A business tool may need office managers, sales teams, or finance staff. A home product may need people who face the problem in their own routine.

Keep the group small during early testing. A few sessions can reveal repeated issues. When the same problem appears across several participants, it deserves attention.

Avoid choosing only people who already support the idea. They may overlook barriers that a new user would notice at once.

Review the build cost

A prototype can test desirability and usability, yet the idea may still be hard to produce.

For a physical product, review:

• Materials
• Number of parts
• Assembly steps
• Product size
• Safety needs
• Repair access
• Packaging and shipping

For software, review:

• Data requirements
• Third-party tools
• Account permissions
• Security needs
• System connections
• Support effort

A short discussion with an engineer, manufacturer, or technical specialist can uncover limits that are not visible in the prototype.

The goal is not to solve every production detail at this stage. The goal is to identify risks early enough to make a sensible choice.

Learn from small tests

Dropbox provides a useful example of early product testing. Before building a complete file-syncing system, the team showed a video that demonstrated the intended experience. The response helped test interest in the idea before a full product was available.

The lesson is simple: a prototype can test demand without containing every technical part of the final product.

A restaurant may test a new menu item with a small group. A software company may test one workflow with a clickable screen. A hardware team may create a rough model to check size and handling.

The best format depends on the question.

Know when the prototype is doing its job

Your prototype is giving useful evidence when you can answer these questions:

• Can the target user describe the problem?
• Can they complete the main task?
• Do they understand the value?
• Which parts create confusion?
• What would make the product hard to build?
• What should change before the next test?

A prototype does not need to receive praise. It needs to reveal what the team should do next.

If every test participant likes the idea but nobody can explain how they would use it, the concept may need more work. If users complete the task but do not see enough value to change their current behavior, the product message or core offer may be weak.

I treat negative feedback as useful when it is specific and connected to observed behavior.

Before moving forward, review the evidence, not just the appearance. A clean interface, detailed model, or smooth demo can support a good test, but it cannot replace one.

A capable prototype makes learning easier. It gives your team a shared object to discuss, helps users react to something concrete, and exposes problems while changes are still manageable. Build only what you need to test the next decision, measure what users actually do, and let the findings shape the next version.

A prototype can look polished and still fail to answer the question that matters most:

Will people understand it, use it, and come back to it?

I have seen teams spend days refining colors, icons, animations, and page layouts before asking a simple question: “What does a new user think this product does?”

That question often reveals more than another round of internal reviews.

The one thing a prototype cannot go without is direct feedback from the people it is meant to serve.

A prototype is not a finished product. It is a way to test an idea before the team commits more time, money, and development work. Without feedback, the prototype becomes a presentation piece. It may look complete, yet it gives the team little evidence about whether the product solves a real problem.

I use feedback to check four practical points.

1. Can users explain the purpose?

Show the prototype to someone who has not joined the project. Ask them what they think the product helps them do.

Do not explain every screen before they respond. Extra context can shape their answer and hide unclear parts of the design.

If the person cannot describe the main purpose in their own words, the product may need a clearer message, a simpler first screen, or a better user flow.

A meal-planning app can have many useful features, such as recipe storage, shopping lists, and nutrition details. A new user may still leave if the first screen does not make the next action clear.

2. Can users complete the main task?

Give people a specific task instead of asking whether they “like” the prototype.

You might say:

“Find a suitable plan for next week and save it.”

Then watch what happens. Notice where the user pauses, taps the wrong button, opens the wrong menu, or asks for help. These moments often show more than a positive comment.

I prefer asking users to think aloud, but I do not interrupt every few seconds. Silence can show that the person is focused. A long pause can point to confusion. Both are useful signals.

3. Does the product fit the user’s current habits?

A prototype may solve a problem in theory but add effort to an existing routine.

Imagine a small business tool that helps shop owners track stock. If updating inventory requires opening several screens after every sale, many owners may return to paper notes or a spreadsheet. The idea may be useful, but the workflow does not match the way they work.

Ask questions such as:

• What do you use today?
• What feels slow or frustrating about that method?
• When would you use this product?
• What might stop you from using it?

These questions help separate a real need from a feature that only sounds useful inside a meeting.

4. Which problem should the team fix next?

Feedback can produce a long list of requests. Not every request deserves equal attention.

I look for repeated problems that block the main task. If four out of five users cannot find the checkout button, that issue should receive attention before a request for more color options.

I also compare user comments with observed behavior. People may say a feature is helpful, then ignore it during the test. Their actions give the team another source of information.

A simple feedback record can include:

• The task the user received
• The step where confusion appeared
• The user’s exact words
• The impact on the main task
• A possible design change
• The result after another test

This keeps feedback connected to decisions. It also prevents the loudest opinion in the room from controlling the product direction.

The number of testers depends on the prototype and the question being tested. A small group can reveal repeated usability problems, while a larger study may help compare user groups or product concepts. The goal is not to collect praise. The goal is to learn what needs attention before development becomes harder to change.

I once worked with a team that wanted to improve a booking service. The members believed the search feature was the main concern, so they spent time adjusting filters. During user sessions, people reached the results page but could not tell whether a booking had been completed. The team changed the confirmation screen and tested it again. The change was small, yet it removed a point of uncertainty that had affected the whole journey.

That is the value of feedback. It brings the product back to the user’s experience.

A strong prototype does not need to answer every question. It needs to expose the right questions early enough for the team to act on them.

Before refining another detail, I ask three things:

• Who will test this prototype?
• What task will they complete?
• What decision will the feedback help us make?

When those answers are clear, the prototype becomes more than a visual sample. It becomes a practical tool for learning, testing, and making better product choices.

A prototype can look promising on the workbench and still face problems when real users handle it, suppliers review it, or production teams prepare to build it.

I often see teams reach this stage with the same concerns:

• The product works, but it feels difficult to use.
• The design looks good, but some parts are costly to make.
• The prototype proves the concept, but it does not reflect the final product.
• Feedback comes from scattered sources, so the next design move is unclear.

Moving a prototype forward is not about adding more features at random. It is about finding the gaps, testing the right details, and making steady design decisions.

Start with the purpose of the next prototype

Before changing the design, I define what the next prototype needs to prove.

It may need to answer questions such as:

• Can users understand how to operate it?
• Does the product fit comfortably in the hand?
• Can the enclosure protect the internal parts?
• Can the chosen materials handle normal use?
• Can a supplier produce the parts with consistent quality?
• Does the product meet the required safety and performance checks?

A prototype built for user testing will not look the same as a prototype built for manufacturing review. Each version should have a clear purpose. Without that focus, teams may spend time polishing details that do not solve the main product problem.

Review user feedback before changing the design

User feedback becomes useful when it connects to a specific design decision.

I group feedback into areas such as:

• Usability
• Comfort
• Appearance
• Product performance
• Durability
• Assembly
• Cleaning and maintenance
• Price-related concerns

Imagine a handheld device that users say feels uncomfortable after several minutes. The answer may not be a complete redesign. A small change to the grip shape, button position, surface texture, or product weight may improve the experience.

I also look for repeated behavior instead of relying on one comment. If several users press the wrong button, the issue may come from the button layout or visual cues. A short test session can reveal more than a long list of personal opinions.

Check the design for manufacturing needs

A prototype can be made successfully with 3D printing, hand finishing, or small-batch methods. That does not mean the same design will work well for injection molding, CNC machining, sheet metal fabrication, or electronic assembly.

At this stage, I review:

• Wall thickness
• Draft angles
• Sharp corners
• Fastening methods
• Part count
• Material selection
• Assembly order
• Surface finishing
• Tolerance requirements
• Access for inspection and repair

A simple example is a plastic enclosure with several tight corners. It may print without trouble, yet the shape could create sink marks, weak areas, or mold limitations during production. Adjusting the geometry early can reduce later changes.

Supplier feedback should be part of this review. A manufacturing partner may suggest a different material, split line, fastener, or production method. These suggestions can affect the appearance of the product, so I prefer to discuss them before the design becomes difficult to change.

Test the parts that affect the experience

Not every feature needs the same level of testing.

I give more attention to parts that affect:

• Safety
• Product reliability
• User comfort
• Product controls
• Water or dust protection
• Heat management
• Battery performance
• Structural strength
• Assembly accuracy

A product can pass a basic function test and still frustrate users. A latch may close correctly but require too much force. A screen may display the right information but be difficult to read under normal lighting. A charging port may work but sit in a position that makes daily use awkward.

Small tests can expose these issues. I may ask users to complete a short task, observe where they pause, and record the actions they repeat. I may also test the same part under different conditions, such as low light, repeated use, heat, moisture, or transport.

Reduce unnecessary complexity

Extra parts often create extra costs, assembly steps, and possible failure points.

When reviewing a prototype, I ask:

• Can two parts become one?
• Can a custom part use a standard component?
• Can the assembly process become easier to understand?
• Can the product be repaired without damaging the enclosure?
• Does each feature support a clear user need?
• Can the same material work across several parts?

This does not mean removing useful functions. It means making sure each part has a reason to stay.

A product with fewer components may be easier to assemble, but the change should not reduce strength, service life, or user safety. Design decisions need to balance the user experience with production needs.

Build a test plan for the next version

A useful test plan does not need to be long. It needs to connect each question with a way to check it.

For example:

The purpose is not to collect data for its own sake. Each test should help the team decide what to keep, adjust, or remove.

Keep a record of design changes

Prototype development can become confusing when several versions look similar.

I recommend recording:

• Version number
• Date
• Main design changes
• Materials used
• Test results
• Open issues
• Person responsible for the next action

Photos, marked-up drawings, and short notes can prevent repeated work. They also help suppliers understand which version they are reviewing.

A change log is especially useful when the mechanical design, electronics, software, and packaging develop at different speeds. It gives everyone one shared reference.

Prepare for a production discussion

When a prototype is ready for a supplier review, I prepare more than a 3D file.

Useful materials may include:

• 2D drawings
• 3D CAD files
• Material details
• Surface finish requirements
• Tolerance information
• Assembly instructions
• Test results
• Packaging needs
• Questions about production volume

It is also helpful to explain what is fixed and what can still change. A supplier can give better feedback when they know which dimensions, materials, or features are open for review.

A practical path from prototype to the next stage

A clear development path may look like this:

1. Define what the next prototype must prove.
2. Review feedback from users and internal teams.
3. Identify problems that affect safety, use, cost, or production.
4. Update the design based on evidence.
5. Test the revised parts and functions.
6. Review materials and production methods with suppliers.
7. Record the results and open issues.
8. Prepare the prototype for the next build or pilot run.

The path may change across product categories. An electronic device may need more attention on heat, battery, and software behavior. A mechanical product may need deeper testing on strength, fit, and assembly. The method remains similar: define the question, test the design, learn from the result, and make the next decision with clear information.

Your prototype does not need to be perfect before it moves forward. It needs to show what works, expose what still needs attention, and give the team a practical basis for the next build. When design feedback, user testing, and manufacturing input are handled together, the prototype becomes more than a demonstration. It becomes a reliable step toward a product that people can use and a team can produce.

Interested in learning more about industry trends and solutions? Contact lingchao: mr.xu@lingchaopcb.com/WhatsApp +8613780181891.

Donald Norman (2013) The Design of Everyday Things Revised and Expanded Edition

Steve Krug (2014) Don’t Make Me Think A Common Sense Approach to Web Usability

Eric Ries (2011) The Lean Startup How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

Alexander Osterwalder and Yves Pigneur (2010) Business Model Generation

Tom Kelley and Jonathan Littman (2001) The Art of Innovation

Jakob Nielsen (1994) Usability Engineering