A pilot is a bounded experiment, not an indefinite free deployment. Define the workflow, support conditions and exit decision before inviting a design partner.
Choose a decision-changing hypothesis
A fictional document approval product might test whether a team can retrieve the latest decision without chasing colleagues. “People enjoy the app” is not a useful acceptance criterion. Record whether participants use sample data, receive hands-on help or depend on an unfinished integration. Assisted success and independent success answer different questions.
Write a one-page pilot brief
| Field | Illustrative entry |
|---|---|
| Participants | One operating team and one review owner |
| Workflow | Submit, comment and retrieve an approval |
| Evidence | Completed result, blockers and assistance required |
| Boundary | No sensitive documents during the first exercise |
| Exit | Continue, redesign the workflow or stop |
Include uncomfortable cases
Try a rejection, a replacement document and an unavailable approver. Assign someone to resolve blocked work. Separate defects from feature requests: an incorrect permission boundary deserves a different response from a request for branding options.
During the review, compare observations with the original hypothesis. Failed usage may reveal a weak need, confusing interaction or organisational resistance. Adding more features without identifying the cause makes the next pilot harder to interpret.
Does a free pilot prove willingness to pay?
It provides evidence about use under the offered conditions. Buying intent needs its own conversation about scope and commitment. A design partner's participation is not contracted revenue. Agree how the pilot ends, including useful exports, access removal and a clear explanation of what happens to unfinished work. A stopped pilot can still produce a valuable decision.
An asynchronous design-partner pilot
If the pilot spans time zones, define how blockers are reported outside the team's working hours. Record how long participants waited for help. Otherwise support availability can be mistaken for product usability when interpreting failed or incomplete tasks.
Sources and further reading
From this guide to your project
Product ↗
The experience connects your promise to the job your user needs to get done. We design that journey before adding more screens.
Tell us about your ideaExamples are educational and do not describe client results. Content prepared with AI assistance; see our editorial policy. Our method ↗