Workflow variants are complete strategies for specific contexts, not degraded versions of an ideal — each variant has its own integrity
Design workflow variants as complete self-contained strategies for specific contexts rather than as degraded versions of a single 'ideal' workflow, with each variant having its own integrity and appropriate output standards.
Why This Is a Rule
The default mental model treats workflow variants as compromises: the "full" workflow is the ideal, and any shorter version is a degraded shortcut that produces inferior output. This framing produces guilt ("I should be doing the full version") and quality confusion ("this output is from the short version, so it's probably not good enough"). Both are harmful because they prevent legitimate adaptation to context.
A "quick report" isn't a degraded version of the "full report" — it's a different document designed for a different purpose. The quick report optimizes for speed and key-point extraction; the full report optimizes for comprehensiveness and depth. Each has its own integrity, its own quality standards, and its own appropriate contexts. Treating the quick version as "the full version with stuff cut out" guarantees it feels incomplete; treating it as "a complete strategy for situations requiring rapid synthesis" gives it its own quality standard it can fully meet.
This reframing parallels the design principle of responsive design in web development: a mobile layout isn't a degraded desktop layout — it's a complete design optimized for mobile constraints. The same content adapts its presentation to the context rather than trying to be a smaller version of a different context's optimal solution.
When This Fires
- When designing "lite" or "quick" versions of existing workflows
- When using a shortened workflow and feeling guilty about "cutting corners"
- When output quality is inconsistent because the same standards are applied to different workflow variants
- When contexts vary (time-pressure, energy level, stakes) and a single workflow can't serve all of them
Common Failure Mode
The "cutting corners" narrative: using a shorter variant while mentally comparing it to the full version, producing guilt and half-hearted execution. The result is worse than either a committed full version or a committed quick version — you get the time cost of trying to do the full version with the quality of a resentful shortcut.
The Protocol
(1) For any workflow that needs to adapt to different contexts, design named variants: "Full" (optimal conditions, high stakes), "Standard" (normal conditions, moderate stakes), "Rapid" (time-constrained, lower stakes). (2) Each variant gets its own complete description: steps, output standards, and quality criteria calibrated to its context. (3) The "Rapid" variant is not "Full minus steps 3, 5, and 7" — it's a redesigned workflow that achieves its own purpose within its own constraints. (4) When selecting a variant, choose based on context, then commit fully. No guilt, no half-measures, no "I should be doing the full version." (5) Each variant's output should be excellent by its own standards. A quick email update written well is better than a comprehensive report written resentfully.