01
Step one: define what enters the system
Begin with the input. State which file types are accepted, who may upload them, and what identifying details must be present or removed. In a worked example, a research lab uploads sequencing output for twenty samples tied to a study code, not patient names. The page should list required fields, show how mismatched sample labels are caught, and explain what happens when a file fails a quality check. A reader should leave knowing exactly what to prepare, who is responsible for it, and which problems stop the process early.
02
Step two: separate automated work from review
Next, show which actions are automated and which need a person. Continuing the example, software might align reads, call variants and annotate them against reference sources, while a scientist reviews flagged findings and records a decision. Name each stage, its output and the version of the method used, so results can be reproduced later. If machine-generated suggestions appear, label them as suggestions. This section should make accountability visible: who approved a variant, when they did so, and what evidence they saw. Readers judge a workflow by how clearly it marks human judgment.
03
Step three: design the report and its follow-up
Finally, describe the report itself. In the example, the study team receives a summary of reviewed variants, method notes, limitations and a list of samples excluded for quality. Decide the audience first: a researcher needs detail and data tables, while a clinical reader needs plain wording and clear caveats. Add a revision path so corrected results are issued with a visible change note. End the page with what happens to the data afterward, including retention, export and deletion choices, so the workflow reads as complete rather than stopping at a document.