Data Flow

A data flow maps how information moves through a product: what the user enters, what gets validated and transformed, where it's stored, which APIs it travels through, and what comes back out as screens, reports, and exports. The unit is the piece of data, not the step or the person. Sibling distinctions: a system flow (System Flow) tracks actions and events in time ("validate, then queue a job"); a data flow tracks the information itself ("the email address goes from this form to this table to this analytics vendor"). Same territory, different question.

Lineage (labeled as history)

Data-flow diagrams (DFDs) come from 1970s structured analysis: Tom DeMarco's Structured Analysis and System Specification (Yourdon Press, 1979) codified the Yourdon/DeMarco notation — processes (circles), data stores (open-ended rectangles), external entities (squares), and labeled flows (arrows) — with the discipline of hierarchical decomposition from a single "context diagram" downward. Gane & Sarson (1979) published a parallel notation; the two symbol sets differ, the idea doesn't. Designers rarely need formal DFD symbols; what's worth stealing is the discipline: every flow line is named data ("order total," not "info"), and every store, source, and destination is explicit.

Why designers need it

"What data does this screen need?" is the #1 wireframe blocker. Every list, card, and detail view is a claim that certain data exists, is fresh, and is queryable. A dashboard mock showing "average processing time" is fiction until the data flow shows where timestamps are captured and computed. Draw the data flow first and each screen becomes a checklist of fields — with a source for each, or a red flag.
Empty and stale states fall out of it: wherever data might not exist yet (new user, no uploads) or lag reality (cached, batch- updated nightly), the UI needs an answer (Empty State Flow, State Flow).
Forms are data-flow front ends: what's required vs. optional, validated where (client, server, third party), and stored how long — all data-flow questions (Forms & Input).

Privacy and security are design concerns

The data flow is where privacy stops being a policy PDF and becomes concrete. For each flow, answer: What's collected (and is each field necessary — data minimization)? Where does it live (your DB, a vendor, the user's device, which country)? Who can see it (which roles, which third parties, which support tools)? How long is it kept (retention, and does delete actually delete — downstream copies in analytics, backups, exports)? Regulations like GDPR require this mapping anyway; designers who hold the data flow can design honest consent prompts, truthful privacy settings, and a delete-account flow that isn't a lie. Depth: Privacy & Security UX.

Example — image upload to map dashboard

[User uploads images]  ← PII: photos may contain faces, plates
  → (Metadata extracted: EXIF — GPS location!, timestamp, device)
       ← PII: GPS is location data. Design decision, not default:
         strip? ask? blur precision? Say so at upload time.
       └── ✗ no EXIF / corrupted → image kept, flagged "no
            location" → dashboard needs an "unmapped items" state
  → [Files stored: object storage]   [Metadata stored: database]
       ← who can access? retention? included in account delete?
       └── ✗ storage write fails → user-visible error, no orphan
            metadata row pointing at a missing file
  → (Processing pipeline: resize, classify, geocode via
       third-party API)
       ← data leaves your system here — vendor sees images +
         coordinates; is that in the privacy policy the user saw?
       └── ✗ API down/quota → results delayed → dashboard shows
            "processing" honestly, not a half-empty map
  → [Results saved]
  → [Dashboard displays map]  ← shows location history: visible
       to whom? teammates? public links? default matters.
       └── ✗ zero mapped items (new user / all failed) → empty
            state that explains and offers the next action

The ← PII annotations are the method: mark every point where personally identifying data enters, moves to a new store, crosses to a third party, or becomes visible to new eyes. Those points are your consent, disclosure, and settings surface.

How to build one

Start with one screen or one user action. List every field it shows or collects.
For each field, trace backward to its source (user input, system- generated, third party, derived) and forward to every place it lands (stores, vendors, exports, logs).
Name the data on every arrow — "email address," "order history," never "data."
Mark PII/sensitive data at every hop; mark third-party crossings.
For each store: who reads it, how long it's kept, what deletion means.
For each flow: what the user sees when the data is missing, stale, or failed to arrive.
Walk it with an engineer — the real pipeline always has more copies of the data than anyone remembers.

Common mistakes

Unlabeled arrows ("data" is not a label).
Missing outputs: exports, reports, emails, and logs are data flows too — and favorite leak sites.
Assuming delete deletes — trace the copies (analytics, backups, vendor systems, other users' exports).
No empty/stale/failed answer for each screen's data.
Collecting fields no flow consumes ("might need it later" is a liability, not an asset).
Treating third-party crossings as internal — every vendor hop is a disclosure event.

Checklist

Every arrow labeled with the specific data it carries.
Every screen's fields traced to a source — or flagged as unavailable before wireframing.
PII marked at every collection, storage, crossing, and display point.
Third-party crossings listed and matched against what users were told (Privacy & Security UX).
Retention and real deletion behavior defined per store.
Who-can-see-it answered for every display, share, and export.
Missing / stale / failed data has a designed state per screen (Empty State Flow, Error Flow).
Every collected field is consumed by some flow — or cut.
Verified with engineering against the actual pipeline.

Sources

DeMarco, T. (1979). Structured Analysis and System Specification. Yourdon Press/Prentice Hall — the Yourdon/DeMarco DFD notation and structured analysis method.
Gane, C. & Sarson, T. (1979). Structured Systems Analysis: Tools and Techniques — the parallel Gane-Sarson DFD notation.
Yourdon, E. — Just Enough Structured Analysis, ch. 9 "Dataflow Diagrams" (yourdon.com) — practical DFD guidance from the method's co-popularizer.
EU General Data Protection Regulation (GDPR, 2016/679) — data- mapping, minimization, and retention obligations that make this diagram legally load-bearing; see Privacy & Security UX.