Turning a paper sketch into working software

A prototype is most useful when it turns an uncertain idea into evidence for a decision. The prototype development cycle links a paper sketch to functional software by keeping each stage connected to an assumption that can be tested. Draw the workflow, make it interactive, observe how people use it, record the problems, and revise deliberately. Paper is not merely a preliminary exercise; it exposes sequence, ownership and missing information before expensive code hides them.

The cycle suits organisations using lean processes, Kanban and digital visual planning because it creates short feedback loops instead of waiting for a complete product. It also fits Australian teams operating across very different environments: Melbourne and Sydney are major hubs for software and manufacturing, while Perth supports mining operations extending across remote Western Australia. A prototype tested only in a central office may overlook the field conditions, skills and infrastructure its eventual users actually have.

Define the decision the prototype must support

Begin with the decision rather than a list of features. What should a person be able to do, and what evidence would show that the proposed design is better than the current process? For a visual planning system, that decision might involve whether a production team can identify a blocked item, understand its owner and move work forward without a facilitator. For a customer-facing tool, it might concern whether a first-time user can complete a transaction and recover from an error.

Write the workflow as a sequence of events. Identify the trigger, the person acting, the information available, the decision required and the resulting handoff. Include exceptions early: what happens when stock is missing, an approval expires or two teams edit the same record? A concise brief can then state the prototype hypothesis, the limits of the exercise and the evidence required to accept, revise or abandon it.

Local operating conditions belong in this brief. Australian small and medium-sized enterprises often have mixed teams, limited specialist capacity and established supplier relationships that cannot be changed through software alone. Adelaide’s defence and advanced manufacturing sectors may require traceable decisions, while healthcare and public-service workflows in Queensland often involve privacy obligations and long approval chains. These constraints should shape the prototype’s scope rather than appear as late “requirements” discovered during implementation.

Sketch the workflow before writing software

Use paper because it is cheap to change. Sticky notes, index cards or a printed flowchart can represent screens, decisions, queues and physical objects. Keep a separate lane for each actor so that handovers are visible. Draw only what the test requires, using realistic language from the workplace rather than polished interface labels. A useful sketch shows what happens, not how every pixel will eventually look.

Test the sketch with people who will influence or perform the work. Ask them to complete realistic scenarios while the designer observes where they hesitate, invent missing steps or rely on information the artefact does not contain. A facilitator should not rescue participants by explaining the intended process. The point is to expose ambiguity. For a Kanban board, for example, the test might reveal whether people interpret “in progress” consistently and whether ageing work items are noticeable without colour or technical training.

Direct observation can reveal assumptions that desk research misses. The account of author visits and fairs offers a useful parallel: planned experiences often generate different queues, timing needs and participation patterns from those expected in advance. A paper prototype should be treated in the same way. Each observed difference becomes a specific revision—such as changing the sequence, adding a status or removing an approval—rather than a vague request for a more attractive board.

Build the smallest testable software slice

Translate the validated sketch into a thin vertical slice. Instead of creating every screen as a static mock-up, build one complete path through the front end, application logic, data store and any required external service. This produces a minimum viable product that can generate genuine usage evidence. The scope should be narrow enough for rapid delivery but realistic enough that timing, validation and integration issues become visible.

Architecture decisions should follow the workflow rather than fashionable tooling. A browser interface may suit planners working across sites, while a server-side component is needed for permissions, audit records and business rules. WebSockets can deliver immediate board updates, and a small database can hold the relevant work states. The team should also decide which enterprise-system boundaries are represented in the prototype and which remain mocked, documenting those limits so users do not mistake a fixed response for a complete integration.

Security and usability cannot be postponed until after the prototype looks convincing. A Project Visit review of mobile login password handling highlights the value of examining authentication as part of the user journey rather than treating it as a technical afterthought. A test build should demonstrate safe session management, useful error messages and recovery from failed access. Use synthetic credentials, avoid collecting genuine passwords and involve security specialists when authentication will eventually connect to production systems.

Connect implementation to rapid feedback

Deploy the test slice early and make feedback part of the build rhythm. Short planning sessions can select one assumption, one implementation slice and one testing method for the coming cycle. A shared preview environment allows planners, developers and operational users to examine the same version. Changes should return to a prioritised backlog with the observation or measurement that prompted them, preventing preferred features from displacing unresolved workflow risks.

Real-time functionality can make collaboration easier to evaluate. The Project Visit simple Kanban board tutorial demonstrates how JavaScript and WebSockets can keep a board synchronised across connected clients. During testing, observe not only whether updates arrive correctly but also whether users understand what caused a card to move, whether stale information creates doubt and whether notification behaviour helps or interrupts their work.

Australian deployment conditions require deliberate checks. Teams in Sydney and Melbourne may operate across several time zones, while field personnel in the Pilbara or northern Queensland can face intermittent mobile coverage and long travel between sites. A prototype may need an offline state, cached information or a clear manual fallback. These are functional requirements, not optional refinements. Test them with actual devices and representative network conditions, and record who can support the system when a connection fails.

Review evidence and decide what to keep

Bring quantitative and qualitative evidence into the same review. Completion rates and response times reveal friction, while observations explain why a participant struggled. Version records, support requests, interface errors and workflow exceptions help distinguish a minor usability issue from a broken assumption. The decision should concern the evidence gathered against the original hypothesis, not the amount of effort already invested.

Useful signals to collect

• Task completion and the time required for each scenario
• Errors, abandoned steps and successful recovery attempts
• Unplanned handoffs or missing pieces of information
• Differences in interpretation between operational roles

Signals that justify another cycle

• Users need a facilitator to understand the intended workflow
• Observations contradict a core assumption from the paper stage
• Prototype data cannot represent an important integration condition
• Performance, access control or offline behaviour blocks realistic use

After the review, mark each assumption as supported, uncertain or contradicted. Keep, change and remove work accordingly, then record the rationale for the next slice. This decision gate is the essential lean mechanism within the cycle: learning changes the backlog, and the backlog determines what gets built. A prototype that produces no consequential change has served little purpose beyond visual reassurance.

Carry learning into the next build

Maintain traceability from the original problem through sketches, software slices, tests and revised decisions. Store artefacts in a shared visual workspace so stakeholders can see both the current version and the evidence behind it. This practice supports the research and industry-collaboration environment associated with Project Visit and the Chalmers Electronic Lean Research Team, where digital planning tools are examined alongside the organisational processes they are intended to improve.

Scaling comes after the pattern becomes reliable. A successful small slice can be extended with more work types, richer enterprise-system connections and broader permissions, but each addition should preserve the tested workflow. For Australian organisations, rollout planning must also cover local support, training time, accessible interfaces, audit needs and resilience during outages. Collaborative projects with industrial partners can help reveal these operational details before a system reaches widespread use.

The practical takeaway is to treat every cycle as a chain of evidence: sketch the riskiest assumption, build only enough software to test it, observe real behaviour, and let the resulting decision determine what happens next.