You send a new web service idea to a few contacts over LINE and hear, “That sounds useful.” On another day, you show a paper screen to someone who often calls with the same problem, and they ask where the signup begins. The reactions are encouraging, but they do not yet tell you whether the service should be built.
The explanation may change each time you email it. A trial request may be copied into a working table, then wait too long for a reply. You want to make the idea real, but you also want to avoid building a service that people use differently from what you expected.
This article helps business owners and service planners decide who should see what before development, and what reaction would justify the next step. Here, a web service means a browser-based way to complete tasks such as booking, applying, searching, introductions, or communication.
Why it is hard to know how much to make
“We have an idea. But what if we request development and no one actually uses it?”
Common situations include:
- People reply positively to a LINE message, but no one has tried to sign up.
- A repeated phone inquiry looks like a web service opportunity, but the right user flow is unclear.
- People comment on paper screens, but no one has tried the flow without an explanation.
- Trial requests arrive by email, but the team has not separated the users' different problems.
- Booking and payment both seem necessary, but building everything first feels risky.
- Similar services exist, but the difference is hard to explain in one sentence.
This uncertainty does not mean the idea is weak.
A friendly comment is different from spending time on a trial, leaving contact details, or completing a request.
The useful first artifact is not a smaller final product, but the smallest thing that answers the biggest open question.
The short answer
Before developing a new web service, work through this order:
- Choose one first user group.
- Choose one task that user needs to complete.
- Confirm how people handle that task today.
- Match the experiment to the biggest unknown.
- Define both a signal to continue and a signal to reconsider.
If the message is unclear, test one explanation and one trial action.
If the screen order is unclear, let people try a clickable mock.
If intake, notifications, or another service connection must actually run, build one small end-to-end prototype.
Getting evidence for the next decision matters more than making the prototype look complete.Instead of asking only, “Can you build this feature?”, say, “We want to learn whether this user will complete this task.”
30-second check: what should you test now?
Answer four questions to choose a provisional starting point: interest, screen flow, or a working process.
The result is not a final decision.
Use it to explain the first experiment in a comparison or development consultation.
30-second check
What should you test before development?
0/4
Answer the 4 questions first
The result suggests a useful next experiment. It is not a final development decision, only a starting point for comparison or consultation.
When unsure, choose the answer closest to what you still need to learn.
Collect three facts before building
Do not start with a complete feature list.
Start with three facts about the user's current situation.
1. How do people complete the task today?
Ask about phone calls, messages, email, search, paper, and existing services.
Instead of only asking whether the task is frustrating, ask what happened the last time they completed it.
2. Where do they stop or give up?
Look for repeated delays, checks, and reasons for abandoning the task.
Confirm that the current problem repeats before spending time explaining the proposed solution.
3. What next action would show real interest?
Do not stop at “That sounds useful.”
Choose one concrete action, such as requesting a trial, choosing a trial date, or making a provisional application.
The U.S. Small Business Administration describes market research as a combination of demand, market scope, current alternatives, and direct customer research (reference).
That supports a practical rule: review similar services and observe actual user behavior.
Compare four ways to test the idea
This is not a ranking.
Choose the method that matches what you still need to learn.
| Experiment | Best fit | Main benefit | Tradeoff to check | Evidence for the next step |
|---|---|---|---|---|
| One explanation and one trial action | You need to learn who cares and whether the message is clear. | The team can test the message and next action without building detailed screens. | A signup does not prove continued use. Record who acted and what they expected. | The intended user requests a specific trial or follow-up. |
| Paper screens | You need to discuss the usage moment and required information. | Wording and order can change immediately during the session. | Too much help from the presenter can hide where people would hesitate alone. | The user can explain the moment and expected outcome in their own words. |
| Clickable mock screens | You need to test search, input, review, and completion order. | The team can find unclear labels and actions before building back-office logic. | Notifications, payment, and external connections do not actually run. | The intended user completes one task without help. |
| One small working prototype | Intake, notifications, search, or another service connection must run to learn. | The user and operating workflow can be observed in a real use moment. | Adding several tasks at once makes it hard to know what worked and what failed. | The user completes the task and the operating team can repeat intake and follow-up. |
When the choice is unclear, return to “What do we need to learn next?” instead of “What should we build?”
What official guidance suggests
The GOV.UK Service Manual recommends learning who likely users are, what they are trying to do, how they do it today, and what frustrations they experience before planning or building a service (reference).
Its discovery guidance also recommends reframing a proposed solution as a problem to solve (reference).
For example, replace “build a store search service” with “help a first-time visitor find a store that is open now.”
This reframing may reveal that a web service is not the only useful answer.
The alpha guidance then says a team does not need to prototype the entire journey. It should build only enough to test important ideas, without treating the prototype as production-quality code (reference).
Ready Mock applies those public-service principles as decision support for commercial service ideas:
- When the user and task are unclear, learn about current behavior before estimating features.
- When one uncertainty is risky, prototype only the screen or workflow needed to test it.
- Treat stopping or changing direction as a valid result of the experiment.
This is practical guidance, not a fixed duration, participant count, or success threshold.
Define signals to continue and reconsider
Write the decision signals before the trial.
You do not need to invent a universal percentage.
Start by observing whether action happened, hesitation decreased, and the operating workflow could continue.
| Question | Signal to continue | Signal to reconsider | Next check |
|---|---|---|---|
| Is the message clear? | The intended user treats it as their task and requests a trial. | Only friendly comments appear, with no concrete next action. | Narrow the user group and task. |
| Can people use the flow? | People finish the intended action without an explanation. | Several people stop at the same word or input step. | Reduce steps, wording, and requested information. |
| Can operations continue? | Staff can repeat intake, review, and follow-up without excessive effort. | Phone calls and repeated entries increase compared with the previous method. | Clarify ownership and the working record. |
“People liked it” is too vague to guide the next step.
Record who tried it, what they did, and where they stopped.
Five preparations before consultation
You do not need a finished specification.
Prepare these five items:
- Describe one first user with the moment they need help, not a broad label such as “busy people.”
- Write whether they currently use phone, LINE, email, search, paper, or an existing service.
- Choose one main unknown: interest, screen flow, or real operations.
- Separate the back-office steps people can handle during a trial from the steps that must actually run.
- Write one signal to continue and one signal to reconsider.
For example:
This keeps the consultation focused on the task and evidence instead of a complete feature list.
Pre-development experiment checklist
Select the items you can answer now.
The remaining items can become consultation topics.
Copyable consultation note
Leave unknown items blank or write “decide in consultation.”
Copy a web service idea consultation note
Use this note to discuss who should see what and which reaction should guide the next step. Unknown items can stay as “decide in consultation.”
What we want to discuss about a new web service idea: Idea in one sentence: Example: help parents find a local class with an available trial date First intended user: Example: a parent who recently moved and is looking for a child activity One task they need to complete: Example: choose an available trial date at a class within travel distance Current alternative: Example: search for classes and call each one to ask about availability Problem with the current alternative: Example: calls must happen during opening hours, and available dates are hard to compare Difference from similar services: Example: start from actual available trial dates, not only class descriptions Biggest question before development: Example: whether parents can move from search to provisional signup without help First artifact to show: Example: clickable search, class detail, and provisional signup screens Back-office steps people can handle during the trial: Example: staff manually confirm availability with each class and send the result Part that must actually run: Example: receive a preferred date and contact details, then notify the operator Signal to continue: Example: intended parents complete the provisional signup without an explanation Signal to reconsider: Example: most people want to search by class name and do not use available dates What we want to decide: Example: whether to begin with paper screens, a clickable mock, or a working prototype Examples we can share: Example: LINE explanation, paper screens, questions from phone calls, notes about similar services
Your next step
Think of one person who recently experienced the problem.
Ask how they handled it last time, then choose whether a one-page explanation, paper screen, clickable mock, or working prototype would support the next decision.
For a first consultation, this sentence is enough:
Building is not the first goal.
The first goal is to create a small experiment that lets user behavior guide the next decision.
Further reading
- U.S. Small Business Administration, Market research and competitive analysis. Used to confirm demand, market scope, competition, and direct customer research topics. Last updated March 24, 2026. Accessed July 26, 2026.
- Government Digital Service, GOV.UK Service Manual, User research in discovery. Used to confirm research into users, current behavior, frustrations, and needs before planning or building. Published November 18, 2016. No update date shown. Accessed July 26, 2026.
- Government Digital Service, GOV.UK Service Manual, How the discovery phase works. Used to confirm reframing a proposed solution as a problem and deciding whether to proceed. Published August 4, 2016; last updated June 21, 2021. Accessed July 26, 2026.
- Government Digital Service, GOV.UK Service Manual, How the alpha phase works. Used to confirm focused prototypes and avoiding production-quality implementation during an exploratory phase. Published August 4, 2016; last updated May 8, 2019. Accessed July 26, 2026.