“We need a form after payment” sounds like a small development task. It leaves several decisions open: what information is missing, who needs it, whether work can start without it, and what a customer should do if they leave halfway through.
At OVZA, requests often came from my manager as a verbal requirement or a partially developed Figma screen. My contribution included developing the missing steps and implementing the customer and operational workflows through custom plugins. The manager supplied the business objective; I worked through much of the detailed solution.
That experience shapes how I would approach an incomplete brief today. The aim is to make the next development decision clear without turning every small feature into a lengthy specification exercise.
Start with the job that needs to move forward
Before discussing fields, describe the business event in one sentence. For example: “After a customer purchases this service, operations needs these details before preparing the application.” That sentence identifies a trigger, a person and a dependency.
Then ask what happens today. Does an employee request the details by email? Does the customer already supply some of them during checkout? Which missing piece actually prevents work from starting? Requiring the same information twice may make an interface look complete while creating avoidable work.
For a hypothetical Saudi service company with a delivery team in Egypt, I would also ask who answers a customer when information needs correction. Geography is relevant here because the handoff needs an explicit owner, not because it tells us how every regional business operates.
Separate a decision from an assumption
A short decision log can prevent a design guess from becoming a business rule. I would give each unresolved question an owner and record the current assumption beside it.
Consider an example: “Customers may edit the form until operations starts reviewing it.” That may be a useful proposal, but someone responsible for the service must confirm whether it is acceptable. If changing a submitted detail means redoing work, the editing boundary affects cost and communication.
The same applies to Arabic and English. Is the customer choosing a preferred communication language, or only changing the current page? Those are different requirements. A language switch should not silently make that business decision for us.
Walk through one ordinary case and two awkward ones
An ordinary case establishes the intended sequence: payment confirmed, details requested, submission received, employee assigned. Then explore two plausible interruptions before adding more interface polish.
In our hypothetical form, the customer might close the browser after payment. The form link therefore needs a recoverable route that does not depend on keeping the success page open. A different customer might submit an unreadable attachment. That calls for a correction request with a clear next action, rather than a generic rejection.
Write these as examples the manager can assess. “If the customer returns tomorrow, where do they continue?” is usually easier to resolve than “Do we need persistence?” The technical design follows the agreed behaviour.
Draw the first release boundary
Developing the requirement also means deciding what can wait. Automatic assignment, a detailed reporting dashboard and a new messaging channel might be useful later. They are not automatically necessary to make the first workflow usable.
For the example above, a modest release might include a saved submission, an operations inbox, an explicit correction action and customer notifications. Assignment could remain manual if somebody owns that queue. The compromise should be visible: simpler implementation in exchange for ongoing operational work.
I would record one success measure at this stage, such as the share of paid requests still missing required information after an agreed interval. The team should establish a baseline before claiming improvement.
Finish with something people can accept
My preferred handoff is a short workflow, a list of confirmed rules, open questions and concrete acceptance examples. One example could read: “When a customer submits valid details, both the customer and the assigned queue can identify the same request reference.”
This gives design, development and operations a common object to review. It also exposes decisions that still need the manager’s authority. The developer can contribute meaningful product thinking while keeping that division of responsibility clear.
Read the OVZA case study for the confirmed project context behind this approach.
Frequently asked questions
What should a workflow brief define?
Define the starting event, the people involved, the information required, the next action, and what happens when a step fails.
Does turning a brief into a system make someone a product owner?
It demonstrates requirements thinking and implementation judgement. Backlog ownership, prioritisation authority and outcome measurement need separate evidence.