Validate a user journey
Check whether the screens and steps support the intended task.
APPS/005Prototypes and early versions
Test the idea
before expanding it.
We give your idea a form you can test before investing further. This may be a screen prototype or a functional first version: we choose what is needed to test the journey, proposition or technical connection.
Fewer assumptions.
A first useful test.
Sometimes the uncertainty concerns the experience; sometimes it is a technical dependency. We build the test needed to examine it before committing to a larger phase.
Test a proposition
Show a concrete idea to representative people and collect their observations.
Test an integration
Check a technical dependency before building the whole project around it.
Define the development scope
Use what you have learned to decide on features, priorities and later releases.
From a hypothesis
to something you can test.
We distinguish a mockup from an operational application. We choose the level of implementation needed to answer the question you want to test.
Starting point
- Scenarios
- User journeys
- Users
First testOutcome
- Prototype
- Observations
- Decisions
A tool of your own.
A specific delivery.
These are the elements we define in the proposal. The final scope depends on your starting point and business priorities.
/001Validation question
We agree on what we need to learn and what signals we will use to decide on the next step.
/002Priority user journey
We select screens and features that represent the core use case.
/003Prototype or functional version
We build the sample with the functionality and data the test requires.
/004Review of results
We organise the observations and propose what to keep, change or investigate before expanding the work.
/005Handover and continuity
We hand over the access, documentation and guidance covered by the agreed scope. Follow-up or maintenance is defined separately if commissioned.
A specific uncertainty.
A test to resolve it.
(4)Choose what to test
We define the question the test should answer and the observations that will help you decide.
Choose the prototype type
We agree whether you need a clickable mock-up, a test connection or a version that runs the main workflow.
Build and test
We prepare the sample and test it with the agreed user roles, observing questions and problems.
Decide what comes next
We organise the findings and explain what can be reused, what needs changing and what remains untested.
Designed for your team.
Sustainable for your business.
Test scope
The prototype answers a defined question. We make clear what works and what is represented or simulated.
Test data
We choose fictional data or authorised material and agree who takes part in the test.
From test to product
We identify the work needed to turn the sample into a launched service, including access, operations and maintenance.
Before we start.
(5)Can the prototype be published as a product?
It depends on how it was built. A visual prototype is not a production application. Even an early functional version needs operation, access, testing and maintenance defined before wider use.
Can the work be reused afterwards?
A functional version can provide a foundation for further development. A mockup's main value lies in its design and the decisions it informs. We agree on this distinction from the start.
Does everything have to be defined from the beginning?
We need a clear goal and scope for the first version. Further features can be prioritised after testing; changes are assessed before they are added.
Can we connect the tools we already use?
We review the integration interfaces, permissions and terms. If a connection is not feasible, we explain alternatives and their limitations before committing to development.
What happens after delivery?
We agree on hosting, support, maintenance and documentation. The proposal distinguishes operation of the delivered version from extensions and recurring services.
Engineering × Design.
For the next step.