TLDR
- Start by confirming that the problem is real before designing the solution.
- Talk to the people who would actually use the product.
- Build the cheapest prototype that can answer your next important question.
- Test several ideas instead of becoming attached to the first one.
- Watch what users do, not only what they say.
- A failed prototype is useful if it prevents an expensive failed launch.
A product idea can become expensive surprisingly fast.
First comes the design. Then engineering. Tooling. Packaging. Software. Manufacturing. Inventory. Marketing.
By the time anyone discovers that customers do not actually want the product, a lot of money may already be committed.
Good design processes try to move that learning much earlier.
The goal is not to predict the future perfectly. It is to find inexpensive ways to be wrong before being wrong becomes expensive.
Start With the Problem
A common mistake is starting with a solution.
Someone says:
“We should make an app that does this.”
Or:
“We need a new smart device for that.”
The next question should be:
What problem are we solving?
Talk to the people experiencing the problem.
Ask how they handle it now.
What frustrates them?
How often does the problem happen?
What do they currently spend to solve it?
What happens if they do nothing?
Sometimes the original idea survives this research.
Sometimes the team discovers it was solving a problem that barely exists.
That is useful information.
The Design Council’s Double Diamond begins with this kind of discovery. The first step is understanding the problem rather than assuming the original brief already describes it correctly.
Define What Success Looks Like
Once the problem is clearer, narrow it down.
A useful product brief should describe the outcome rather than lock the team into one solution.
For example:
Weak:
Build a mobile app that lets warehouse workers report damaged inventory.
Better:
Give warehouse workers a way to report damaged inventory in under 30 seconds without leaving their work area.
The second version leaves room for more ideas.
Maybe the answer is an app.
Maybe it is a barcode workflow.
Maybe it is a button inside software the warehouse already uses.
Maybe the company discovers workers are already reporting damage and the actual problem is what happens afterward.
Defining the problem correctly creates space for better solutions.
Build the Cheapest Useful Prototype
A prototype does not have to resemble the finished product.
It only needs to answer a question.
If you are testing a new physical product, early prototypes might be:
- cardboard
- foam
- 3D prints
- laser-cut parts
- modified existing products
- rough CAD renders
For software, you might use:
- paper screens
- clickable mockups
- simple wireframes
- a spreadsheet
- a manually operated version of the proposed service
The right level of detail depends on what you need to learn.
If the question is, “Can people understand this interface?” you probably do not need to build the database behind it.
If the question is, “Will this hinge survive 50,000 cycles?” cardboard is not going to help much.
Build to the question.
Test More Than One Idea
Teams become attached to ideas very quickly.
The first concept starts to feel like the product instead of one possible solution.
That can make feedback surprisingly emotional.
A better approach is to develop several concepts.
The Design Council describes the development stage of its Double Diamond as a period for exploring multiple answers, testing ideas at small scale, rejecting what does not work, and improving what does.
That changes the conversation.
Instead of asking:
“Do people like our idea?”
you can ask:
“Which of these approaches solves the problem most clearly?”
That is a much better question.
Watch People Use It
Users are often polite.
Show someone your prototype and ask whether they like it.
They may say yes.
Now give them a task and watch what happens.
Where do they hesitate?
Which button do they press?
Do they hold the product correctly?
What instructions do they ignore?
What do they try to do that the design does not support?
These moments are valuable.
Do not immediately explain the prototype when a user struggles.
If you have to stand beside every tester saying, “No, you click that first,” the prototype has discovered something important.
Test the Riskiest Assumption First
Every product contains assumptions.
For example:
Customers have this problem.
They care enough to solve it.
They understand the concept.
The product can be manufactured economically.
The technology works.
People will pay enough to support the business.
Do not spend six months refining the easy parts while ignoring the assumption that could kill the project.
Find the biggest uncertainty.
Test it.
A technically brilliant product is not much of a success if the market will only pay $30 and it costs $80 to produce.
Likewise, market demand does not matter much if the physical design cannot safely perform its main function.
Learn Before You Polish
Beautiful prototypes have a downside.
People become reluctant to change them.
A rough foam model almost invites somebody to draw on it.
A polished $4,000 prototype feels finished.
That can discourage exactly the experimentation the prototype was supposed to encourage.
Keep early versions disposable.
Add visual refinement when appearance becomes something you actually need to test.
There is no prize for having the nicest prototype in the trash bin.
Know When to Move Forward
Eventually, prototyping needs to become production.
Look for evidence that the biggest questions are becoming smaller.
Users understand the product.
The core function works.
The design can be manufactured.
Costs are becoming predictable.
Repeated testing produces refinements rather than complete redesigns.
You will never remove every risk.
The purpose of a design process is not to achieve certainty.
It is to replace expensive guessing with progressively better information.
Final Thoughts
Innovation often gets presented as a moment of inspiration.
The useful part usually looks less dramatic.
Talk to people.
Define the real problem.
Make something.
Test it.
Find out why it failed.
Change it.
Then test it again.
A cheap prototype that proves an idea is wrong can be one of the most valuable things a design team produces.
It means the lesson arrived before the invoice did.
