Software Prototyping: 7 Steps to Test a Business Workflow Before Building

Software prototyping creates a trial version of an app idea so people can test how it might work. A prototype can be a sketch, a clickable screen flow, or a small coded experiment. Its purpose is to answer a question before the business commits to building the full system.

For example, a company may want to know whether staff can approve a purchase request without sending follow-up emails. This article explains prototype types, seven steps for testing a workflow, and how to turn findings into a build decision. It also clarifies what a prototype cannot prove.

What a software prototype should help you learn

A useful prototype targets uncertainty. That uncertainty may concern the screen layout, the steps in a workflow, or a technical constraint. Start by naming the question. Otherwise, the team may spend time making an attractive demo without learning anything that changes the project.

Consider a dispatch system. The team might test whether a planner can assign a job while seeing technician skills and availability. In contrast, a technical experiment might test whether a map service can handle the required route data. These questions need different prototypes.

Separate learning from approval. A manager may like the look of a screen, yet real staff may still struggle to complete a task. So, ask people to use the prototype and explain their choices rather than collect opinions about appearance alone.

Choose the right level of detail

Sketches and simple wireframes

Sketches show rough layouts and the order of steps. They work well when the team still needs to compare basic approaches. Because they take less effort to change, people can challenge the flow without worrying about losing polished work.

Yet a sketch may not reveal subtle interaction problems. Users cannot always tell what happens after a click or how an error appears. Use it to test structure, then add detail only when the next question requires it.

Clickable screen prototypes

A clickable prototype links screens together. It can show forms, menus, and key transitions without a full backend. For example, users can move from a request form to a review screen and then an approval state.

The Nielsen Norman Group’s guidance on low- and high-fidelity prototypes explains how detail affects what teams can test. Choose enough realism for the question, but avoid spending time on details that do not affect the decision.

Coded prototypes and technical experiments

A coded prototype can test realistic interactions or a narrow technical concern. It may help with keyboard behavior, complex tables, file handling, or an integration. Yet prototype code often lacks the security, testing, and operating features that production needs.

The GOV.UK Service Manual’s guidance on making prototypes highlights their role in exploring and testing ideas. A realistic appearance should not make the team assume the underlying system is ready for live work.

Prototype, proof of concept, and MVP

A prototype often explores how a user will experience a proposed solution. A proof of concept tests whether a technical idea can work. An MVP delivers a limited but usable product to learn from real use. Teams may use these terms differently, so agree on the expected deliverable.

For example, a clickable stock-transfer flow is a prototype. A short experiment that reads labels from a scanner may be a proof of concept. A live stock-transfer app with controlled access and reliable records could be an MVP.

Oxen’s article on MVP software development explains how a limited product differs from an early demo. This distinction helps prevent a project from treating a mockup as a nearly finished app.

7 steps for useful software prototyping

1. Select one uncertain workflow

Choose a task that matters and contains a meaningful unknown. It might involve several roles, repeated mistakes, or a new way of working. Avoid prototyping every screen before the team knows which decisions need testing.

Write a clear learning goal. For instance: “Can a branch manager review a purchase request, spot missing details, and return it to the requester without a separate message?” This is more useful than “test the purchasing dashboard.”

Also record the current process. Note who starts the task, what details they need, and how they know it is complete. The prototype should improve a real workflow rather than only replace paper with a screen.

2. Identify users and realistic cases

Include the people who perform the task, not only the people who sponsor the project. A requester, reviewer, and finance user may each see different problems. Also, include less confident users when they form part of the intended audience.

Choose realistic cases with enough detail to expose decisions. For example, a request may include an urgent item, a missing cost code, or a value above an approval limit. These cases reveal whether the flow supports actual work.

Use fictional or approved test data. Do not copy sensitive customer or employee records into a design tool without a clear reason and suitable controls. Realism comes from the structure of the task, not from exposing private details.

3. Map the full task, including exceptions

Draw the start, decisions, handoffs, and end state. Then ask what happens when details is missing or a request needs revision. A smooth happy path alone cannot show whether staff will need to return to email.

Define visible states such as draft, submitted, returned, approved, and cancelled. Yet include only states that have a clear business meaning. Too many similar labels can make the process harder to understand.

Also note what each role can see and change. Oxen’s guide to role based access control can help frame these questions. The prototype should make role differences visible even if it does not enforce them technically.

4. Build only what the test needs

Create the screens and interactions needed for the chosen task. Leave unrelated modules out. This keeps the prototype quick to revise and makes it easier to understand what the test actually covers.

Tell participants which parts work and which parts are placeholders. If a search field only accepts one prepared example, say so when needed. Otherwise, a limitation of the prototype may look like a flaw in the proposed workflow.

Keep a short list of assumptions. For instance, the design may assume that each request has one approver. Testing can then reveal whether that assumption holds across the business.

5. Run task-based sessions

Give users a goal without telling them which buttons to press. Ask them to complete the task and explain what they expect at each step. Meanwhile, observe where they pause, backtrack, or ask for help.

Avoid coaching them through the path too soon. If the facilitator explains every screen, the session measures the facilitator’s guidance rather than the design. Instead, note the problem and ask a neutral question about what the user expected.

Record behavior separately from suggestions. “The user missed the return reason” is an observation. “Make the text red” is one possible solution. The team should consider several solutions before deciding how to revise the design.

6. Revise the flow and test the change

Group findings by their effect on the task. A blocked approval matters more than a preference for a different icon. Next, choose changes that address the cause rather than patching each symptom.

For example, users may miss a return reason because the design places it on a separate tab. Moving it beside the request details may work better than adding another notification. Test the revised flow to see whether the problem persists.

Keep unresolved questions visible. If the prototype cannot show live stock availability, do not mark that issue as solved. Assign it to a technical investigation or later app test.

7. Turn findings into a build decision

Summarize what the team learned, which assumptions changed, and what remains uncertain. Then decide whether to build, revise the concept, or stop. A prototype that prevents an unsuitable project can still deliver useful value.

Translate confirmed behavior into needs and acceptance criteria. For example, the final app must show the return reason on the request page and preserve the request history. This gives developers and reviewers something concrete to verify.

Use Oxen’s guide to user acceptance testing for the later live-build checks. Prototype testing helps shape the design; it does not replace testing the built app.

A hypothetical purchase-approval test

Imagine a company that receives purchase requests through messages and spreadsheets. The prototype lets staff submit a request, attach a file, and choose a cost code. A manager can approve it or return it with a reason.

In the first session, requesters understand the form. Yet managers cannot tell whether a revised request contains a changed price. The team adds a simple revision summary and tests that screen again.

The next session shows a different issue: finance needs a final approved amount rather than just a status. The team records that as a business rule. It also marks actual accounting integration as an unresolved technical task.

As a result, the build starts with clearer decisions about revision history and approved values. The prototype does not prove that every integration will work. It does show which details the users need to complete the task.

What software prototyping cannot prove

A screen demo does not prove security, performance, data integrity, or reliable recovery. It may show a login screen without a real identity system. Likewise, it may display a report instantly because it uses prepared data rather than a large database.

Keep those limits in the handover. If the team uses a coded prototype as a starting point, it should review the code before reuse. Production work may still need access checks, validation, error handling, tests, and deployment controls.

Also avoid broad claims from a small test group. A few sessions can reveal useful problems, but they do not prove how every user will behave. Treat findings as evidence for design decisions and continue learning during development.

What to request from your development partner

• A clear question for each prototype.
• The user roles and tasks the test will cover.
• The limits of the prototype and its test data.
• A record of observations, decisions, and open questions.
• Updated needs that reflect the findings.
• A clear statement about whether any prototype code will enter production.

Agree on these outputs before work begins. Otherwise, the business may receive polished screens without the evidence needed to approve development. A short decision record often offers more value than extra visual detail.

Test the uncertain decision before funding the full build

Software prototyping helps a business learn while change remains cheap and manageable. Start with one question, observe real users, and record the decision. Then carry the findings into the needs and test plan for the actual app.