Many internal tools start with a long list of wishes and end as a large project nobody has tested. A short prototype is a cheaper way to learn. In two weeks you cannot build a finished tool, but you can learn whether the people who would use it actually want it and whether the idea works on their real work.
This article is for an owner or manager who is considering a small internal tool, such as an order tracker, a quoting form or an approval workflow, and wants to find out before committing a larger budget.
Choose one scenario
Pick a single situation that a real person meets regularly, and follow it from the first click to the result. For example: "A salesperson receives an enquiry, fills in the details, and gets a draft quote to send." That is one scenario. "Manage customers, quotes and invoices" is not.
Write the scenario in three or four sentences and name the person who lives it. If you cannot name that person, the scenario is too vague, or nobody owns the problem yet.
Decide what to build and what to fake
A prototype is not a smaller version of the final product. It is a tool for learning, so spend effort only where the learning is.
Build for real:
- the screens or forms the user sees and touches during the scenario
- the main calculation or rule, if the whole idea depends on it
- realistic sample data, ideally copied from last month's actual cases with personal details removed
Fake on purpose:
- logins and user roles: one shared account is enough
- connections to other systems: paste the data in by hand or use a prepared file
- error handling for unusual cases: note them in a list instead
- design polish, reports and settings
Faking is not cutting corners. It is a decision to postpone cost until you know the idea is worth it. Keep a short list of everything you faked, because that list becomes the first estimate of the work still to do.
Plan the two weeks
A simple split works for a small team:
- Days 1–2: set-up. Confirm the scenario with the user, collect sample data, agree what will be faked, and write the decision rule (see below).
- Days 3–8: build. Make the one scenario work end to end. Show the current state to one user halfway through, even if it is rough, to catch a wrong assumption early.
- Days 9–10: show and decide. Run a session with real users, record what happens and hold the decision meeting.
If the build runs late, cut scope rather than the session with users. A prototype nobody has tried teaches almost nothing.
Show it to the people who will use it
Invite two to four people who do this work today. Give each a real task from their recent work and ask them to complete it with the prototype while you watch. Do not explain the screens first; where they hesitate is the information you came for.
Note three things for each person: whether they finished the task, how long it took compared with their current way, and what they said unprompted. Ask at the end whether they would use it next week if it existed. For a more structured version of such a session, see testing a new internal tool with real work.
Agree the decision before you start
The most useful step takes ten minutes in the first two days. Write down what result means "continue" and what means "stop". For example:
- Continue if most users finish the task and at least some would use the tool next week.
- Change and test again if users finish but only with help, and the cause is clear and fixable.
- Stop or rethink if users prefer their current way, or the main rule turns out not to work on real data.
Without this rule, a pleasant demo tends to turn into a yes, and a disappointing one into endless discussion. With it, stopping is a normal and cheap outcome, not a failure.
After the decision
If you continue, use the list of faked parts as the starting point for the estimate, and decide which of them are needed in the first real version. If you stop, write two lines on what you learned and keep them where the next idea will find them. Either way, the two weeks have bought you facts instead of opinions.
Sources
- Practical guidance based on common prototyping and user-testing practice, offered as a planning aid. The durations and the decision rule are starting points to adapt to your own company. No client results or market figures are claimed in this article.