Make a paper prototype for a workshop booking

Represent the interaction with operable pieces

A paper prototype represents an interaction with physical pieces that someone can operate before software exists. It is especially useful for exploring sequence, wording, and missing states. A workshop booking can be represented by cards for session selection, details, review, and confirmation, with another person changing the visible pieces in response to actions.

Choose a narrow task and prepare the states needed to complete it. Use readable text and realistic choices rather than blank boxes labeled content. Decide who plays the system and what they may say. Their job is to reveal the prepared response, not explain the intended route or rescue every confusing moment. Choose a level of detail that supports the current decision without turning preparation into a substitute for action. Too little detail leaves collaborators inventing the missing conditions; too much can make an uncertain proposal look settled. State the boundaries and name the questions outside them. If another discipline owns an important condition, involve that person early instead of treating the design document as permission to invent an operational answer.

Book a fictional paper-marbling class

Create cards for booking a fictional paper-marbling class. Include two sessions, a full session, a missing email, and a confirmation. Use removable pieces for selected values and messages. Run a practice session with a colleague to check that the operator can find the correct card without improvising the service rules. Keep a brief record of the conditions used for the exercise: the task, information available, roles involved, and artifact version. This makes a later revision easier to compare without relying on memory. Capture questions in the moment, but resist converting every comment into a requirement. Afterward, decide which questions concern the method, which concern the proposed product, and which require an operational owner before work can continue.

Avoid improvising away design gaps

If an operator invents responses, the session may examine their helpfulness instead of the design. If every card assumes perfect input, errors remain unexplored. Paper also cannot faithfully answer questions about actual timing, browser behavior, or assistive-technology compatibility. Record those limits and choose a more suitable prototype when they become central. When the activity produces ambiguity, identify whether the problem lies in the question, the material, the facilitation, or an unresolved product decision. Changing the visual format alone may leave the same uncertainty intact. Return to the purpose and repair the relevant part. Record the change and its reason so collaborators can distinguish a clearer method from a genuinely different interpretation of the underlying evidence.

Choose what paper can answer

Review the prototype by tracing each action to a prepared state and noting where people need explanation. Keep observations from any real session separate from your practice walkthrough. Revise the cards cheaply, then decide which uncertainty remains. The value of paper is rapid, understandable exploration of behavior, with an honest boundary around what its simulation can demonstrate.