Write a useful product requirements document
Document a studio cancellation feature through its problem, scope, rules, states, dependencies, and acceptance conditions so designers and implementers can resolve the same task.
Explain the behavior that needs agreement
A product requirements document should make a proposed change understandable and reviewable. It need not become a long inventory of every screen. For a studio cancellation feature, the essential questions include who may cancel, when cancellation is allowed, what changes afterward, and how the person recognizes that the request succeeded.
Record rules, states, and open questions
Write the problem and intended outcome before the proposed behavior. Separate confirmed service rules from questions awaiting an owner. Include important states, data that must be preserved, operational dependencies, and explicit exclusions. Link to prototypes as illustrations of behavior while keeping decisive rules readable without opening a design tool. Place the proposed solution beside a simpler alternative and ask what extra work each one creates. Count decisions the person must make, rather than decorative elements on the proposal. A useful proposal explains its scope before commitment and its resulting responsibilities. If the design depends on someone remembering an instruction from a previous screen, move that instruction closer to the decision or remove the dependency.
Specify cancellation through concrete cases
Draft a short document for canceling a workshop booking. Describe eligible bookings, a review step, confirmation, waiting-list implications, and support for unavailable cancellations. Add acceptance conditions for a successful cancellation, a failed request, and an uncertain response. Use concrete examples of booking states rather than a vague requirement to be user friendly. Keep a record of the starting conditions alongside the prototype. The same action can be easy with a familiar record and confusing with an incomplete one. Choose the record deliberately, then describe what would count as completion. Show the state immediately after the action as carefully as the initial view. A proposal that ends at the interface action cannot answer whether the person understands the result.
Resolve contradictions before implementation
If the document repeats screen text without explaining rules, implementers still have to invent behavior. If it contains every future idea, the current decision becomes harder to review. Resolve contradictions between the prototype and the written requirement before implementation, especially around irreversible actions, saved data, and operational responsibilities. Check whether a local fix creates a problem elsewhere. A longer explanation may clarify one choice but become clipped in another context; an extra confirmation may protect a destructive action but obstruct routine work. Carry the revision through the full example and its alternate route. Document the tradeoff explicitly so the next person modifying the design understands which behavior the change was intended to protect.
Check that another person can interpret the rules
Ask a colleague to identify the expected outcome for each example without consulting you. Any unanswered question about status, responsibility, or recovery belongs in the document or its explicit open-question list. Keep the document close to the implemented behavior as the feature changes. Its value comes from reducing consequential ambiguity, not from page count or formal vocabulary.
Worked decision
For a request that times out, specify how the booking's current status is checked before the person is encouraged to cancel again.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
