Skip to main content

Unit 6 — Data by Design: Defining the Information That Drives Flow

Unit ID: FO-FND-06
Estimated Time: 90–150 minutes
Delivery Mode: Self-Guided or Catalyst-Led
Applies To: Founders, operators, managers, process and workflow owners
Prerequisites: Completion of Unit 4 (Simple Workflow) and Unit 5 (Exceptions & Edge Cases)

Unit Purpose and Role in FlowOps

Unit 6 introduces the idea that data is not a byproduct of work — it is a design decision.

Most organizations either:

  • Capture far too little information, forcing people to guess, or
  • Capture far too much, slowing work and degrading quality

Both failures break flow.

This unit teaches how to intentionally define minimum viable data: the smallest set of information required for work to move predictably, decisions to be made confidently, and exceptions to be handled consistently.

Without this discipline, later units (metrics, capacity, automation) become unreliable or impossible.

Why Data Design Comes After Flow Design

FlowOps deliberately introduces data after processes and workflows are defined.

If data is designed too early:

  • Teams collect information that does not matter
  • Fields exist with no purpose
  • Tools dictate behavior instead of flow

If data is designed too late:

  • Workarounds become institutionalized
  • Exception handling is inconsistent
  • Measurement is distorted

Unit 6 sits at the point where flow is visible but not yet scaled.

1. What This Unit Solves

The Problem It Addresses

In most organizations, data collection grows organically:

  • Someone adds a field “just in case”
  • A report requires new inputs
  • A tool enforces defaults that don’t match reality

Over time, this creates:

  • Bloated forms
  • Incomplete or inaccurate data
  • Resistance from users

This unit solves the problem of unintentional data accumulation.

Common Symptoms of Poor Data Design

  • Required fields that people guess through
  • Notes fields used for critical information
  • Inconsistent naming and definitions
  • Decisions made outside the system
  • Exceptions handled without context

These symptoms indicate that data was not designed to support flow.

2. The Standard: What Good Process Data Looks Like

What This Section Defines

This section defines the role data plays in FlowOps.

Data exists to:

  • Enable decisions
  • Trigger movement
  • Enforce quality
  • Create visibility

Data does not exist to:

  • Satisfy curiosity
  • Fill reports “someday”
  • Replace thinking

Principles of Good Data Design

Good process data is:

  • Purposeful
  • Minimal
  • Structured
  • Enforced

Every data element must have a reason to exist.

The Question Every Field Must Answer

“What breaks if this data is missing or wrong?”

If the answer is “nothing,” the data does not belong in the process.

3. Data Types in FlowOps

Why Classification Matters

Not all data serves the same function. Mixing data types causes confusion and misuse.

This section introduces four data categories used throughout FlowOps.

3.1 Identity Data

What It Is
Information that uniquely identifies the work item.

Examples

  • ID numbers
  • Names
  • References

Why It Matters
Without identity data, work cannot be tracked or referenced reliably.

3.2 Control Data

What It Is
Data that determines what happens next.

Examples

  • Status
  • Priority
  • Approval flags

Why It Matters
Control data drives flow. Errors here stop or misroute work.

3.3 Decision Data

What It Is
Information required to make judgments or approvals.

Examples

  • Specifications
  • Requirements
  • Constraints

Why It Matters
Missing decision data causes delays, rework, or unsafe assumptions.

3.4 Context Data

What It Is
Supplemental information that provides background or explanation.

Examples

  • Notes
  • Comments
  • Attachments

Why It Matters
Context supports understanding but should not replace structure.

4. Defining Minimum Viable Data

Purpose of This Section

This section explains how to decide what data is truly required for a workflow to function.

Required vs Optional Data

  • Required data blocks flow if missing
  • Optional data enhances clarity but does not block flow

Required fields must be:

  • Justified
  • Validated
  • Enforced

Optional fields should never be used as workarounds.

Designing Data for Handoffs

Data requirements must align with:

  • Acceptance criteria
  • Exception rules

If receivers consistently request missing information, data design is incomplete.

5. Data Quality and Validation

Why Validation Is Necessary

Collecting data without validation:

  • Encourages guessing
  • Creates false confidence
  • Corrupts metrics

Validation is not bureaucracy — it is protection.

Common Validation Rules

  • Format checks
  • Required presence
  • Logical consistency
  • Reference matching

Validation should prevent known failure modes, not every conceivable error.

6. Data Ownership and Stewardship

What This Section Is About

This section clarifies who is responsible for data integrity.

Ownership Rules

  • Process owners define required data
  • Data owners ensure accuracy
  • Everyone is responsible for honesty

Without ownership, data degrades quickly.

7. Outputs of Unit 6

By the end of this unit, the organization must have:

  • A defined field list for the workflow
  • Required vs optional designation
  • Field definitions
  • Basic validation rules

Without these, data remains incidental rather than operational.

8. Governance

Review Cadence

Data definitions should be reviewed:

  • When exceptions repeat
  • When workflows change
  • Before adding metrics or automation

Change Control

Fields should only be added or changed with:

  • Clear justification
  • Owner approval
  • Version tracking

9. Common Failure Modes

  • Making everything required
  • Relying on free-text notes
  • Designing data for reports instead of flow
  • Allowing tools to dictate data design

Good data design is intentional restraint.

10. Catalyst-Led Option

Catalyst may:

  • Facilitate data design workshops
  • Normalize definitions
  • Reduce over-collection
  • Align data to flow and metrics

Catalyst’s role is to keep data purposeful.

11. Completion Criteria

Unit 6 is complete only when:

  • Required data is defined and enforced
  • Optional data is clearly labeled
  • Field definitions exist
  • Validation rules are documented

Do not proceed until these conditions are met.

COPY-PASTE DATA DESIGN TEMPLATE

(Word / Docs friendly)

Workflow Name: __________________________
Workflow Owner: __________________________

Field Name

Data Type

Required (Y/N)

Purpose / Decision Enabled

Validation Rule
         

Notes / Context Fields:

Last Reviewed: __________________________

 

Back to top