Identify an assumption that matters
“We want to test the application” is too vague. An assumption might be that business customers will place repeat orders themselves if they have a simple product list and their agreed commercial terms. Another might be that employees will find a document faster in an organised dashboard than in folders and emails.
These are hypothetical examples. For your project, record the user group, task and change you want to observe. Agree how you will establish a baseline, such as the current way of completing the task and the most common problems.
Choose one complete journey
For an ordering portal, a first version might give an approved customer access to products, order submission and confirmation by staff. If the aim is to test independent ordering, a loyalty programme and extensive recommendations are not essential at this stage.
Some administration can remain manual if this allows the pilot to run safely. You still need to know who will do it and how long it takes. A manual workaround should be a deliberate part of the test, not a hidden problem discovered after launch.
Group features by their role in the test
Ask these questions about each feature:
- Can the user complete the main task without it?
- Is it needed for safe operation and correct access to data?
- Will it help assess the chosen assumption?
- Can a simpler solution replace it during the pilot?
Defer elements that do not affect what you learn. Features essential for users, operations and security still belong in the first release, even if they do not appear in a product presentation.
Distinguish between a wireframe, a prototype and a working product
A wireframe may be enough to check whether users understand the layout and labels. A prototype may help assess technical feasibility. To test actual use of a service, however, people need conditions in which they can complete the task.
A version released to users needs appropriate permissions, data protection, testing and issue handling. Reducing the number of features does not remove those responsibilities. Preparation depends on who will use the product and what they will use it for.
Plan the decision you will make after launch
Before starting, agree who will take part, what you will observe and when you will assess the result. Record completed tasks, points where users stop, support questions and the time spent by both users and staff. Login numbers alone may say little about a tool’s usefulness.
Finish by choosing the next step: further development, fixing the main problem, another test or stopping the idea. A well-scoped MVP gives you evidence for that decision instead of simply adding features.
If you are planning your own product, see how we approach web applications. We can start by clarifying assumptions and the scope of the first stage.
LET’S TALK ABOUT YOUR PROJECT
Let’s talk about your project.
Tell us what you want to change. We will help define the scope and next steps.
Contact us