Designing Nonlinear Workflows Without Losing Readiness Checks

Nonlinear workflow software design starts by separating what must happen first from what usually happens first. A customer may collect evidence for a later task before finishing an earlier one. Block that work only when a real dependency requires it, and make the reason visible.

For an expert-led planning product, distinguish drafting, reviewing and approving. Someone can draft a recommendation provisionally while waiting for evidence. Calling that draft approved is a different decision and may require a stricter gate.

Classify each prerequisite

Relationship	Example	Product behaviour
Hard dependency	Approval requires confirmed evidence	Block approval and name missing evidence
Preferred order	Background notes are easier before planning	Suggest the order without forbidding work
Provisional dependency	Draft can begin with an assumption	Allow draft and show the assumption
Independent task	Upload an existing asset	Allow when the user has it

Review the table with the domain expert using an actual awkward case. Ask what specifically becomes incorrect if the order changes. If the answer is only that the process normally happens that way, investigate a recommendation rather than a hard lock.

Keep work status separate from milestone readiness

Give tasks states that describe the work, such as not started, draft, awaiting evidence and reviewed. Define milestone readiness from the particular evidence and approvals required. Do not derive it automatically from the number of checked boxes.

In an illustrative plan with ten tasks, eight are complete but the required approval and evidence check are unfinished. Task completion is 80 percent. The milestone is not ready. Show both facts with their meanings instead of calling the product 80 percent ready for launch.

Test the dependency map for loops and revisions

Follow every hard prerequisite backwards. If task A requires B and B requires A, the user has no valid starting point. Resolve the loop by separating a provisional draft from the final approval, or correct the rule that created the circular dependency.

Then change evidence after a dependent task was reviewed. Decide whether that task remains valid, needs review or is blocked from use. A completed badge should not conceal that its required evidence has changed. Preserve the prior result so the reviewer can see what they are reconsidering.

Write acceptance cases for out-of-order work

Task the user attempts early
Required inputs already available
Missing inputs and their effect
Allowed provisional action
Condition required for final approval
Message explaining a blocked action
Effect of changing an upstream item later
Evidence retained from the previous review

Run a user through a later independent task first, then return to the suggested sequence. Check that progress is retained. Next attempt a truly dependent approval without its evidence and confirm the product explains the blocker and links to the missing action.

The aim is to represent the domain’s actual dependencies. A flexible interface should not waive a required review, and a rigorous one should not force users to pretend they have no work ready simply because it belongs on a later screen.

Bring one case where work happens out of order. We can separate genuine prerequisites from the sequence the interface merely prefers. Discuss the first release with Adamant Code.