sethmblack Reduction Protocol
Systematically identify and eliminate unnecessary elements from any artifact until nothing remains that could be removed without impairing function. Based on Dieter Rams' principle: "Less, but better."
When to Use
- Simplifying a product, interface, or process
- Editing documents, presentations, or communications
- Streamlining workflows or procedures
- Reducing code complexity
- Decluttering any system with accumulated elements
- Request for "simplify," "reduce," "what can I cut"
Inputs
| Input | Required | Description |
|---|---|---|
| artifact | Yes | The design, document, process, or system to reduce |
| core_function | Yes | The essential purpose this artifact must serve |
| constraints | No | What cannot be removed (requirements, regulations) |
The Reduction Process
Phase 1: Establish Function
Before removing anything, establish with clarity:
- What is the core function? State in one sentence.
- Who is this for? Define the user/audience.
- What must they accomplish? List essential tasks/outcomes.
- What constraints exist? Regulatory, technical, organizational.
Without clarity of function, reduction becomes arbitrary deletion.
Phase 2: Inventory Elements
List every element in the artifact:
- For products: features, components, controls, materials
- For interfaces: screens, buttons, text, images, animations
- For documents: sections, paragraphs, sentences, words
- For processes: steps, approvals, handoffs, communications
Create a complete inventory before evaluation.
Phase 3: Categorize Each Element
For each element, determine category:
| Category | Definition | Action |
|---|---|---|
| Essential | Removal would impair core function | Keep |
| Supportive | Aids core function but not strictly necessary | Question |
| Decorative | Adds aesthetic without functional purpose | Remove unless proven valuable |
| Redundant | Duplicates another element's function | Remove |
| Legacy | Exists because it always has, no current purpose | Remove |
| Anticipatory | Added for "might need it" without evidence | Remove |
Phase 4: Apply Reduction Questions
For each Supportive, Decorative, or questionable element:
- The Removal Test: If I remove this, does the user's ability to accomplish the core function diminish?
- The Justification Test: Can I articulate why this element must exist?
- The Frequency Test: How often is this actually used/needed?
- The Alternative Test: Could another element serve this function?
- The Cost Test: What burden does this element create (complexity, maintenance, confusion)?
If an element fails these tests, mark for removal.
Phase 5: Validate Reductions
Before finalizing:
- Review removed elements: any truly essential items incorrectly categorized?
- Test reduced artifact against core function: does it still accomplish the purpose?
- Consider edge cases: are legitimate but rare needs addressed?
- Verify constraints: have any requirements been violated?
Phase 6: Document Results
Record what was removed and why, for future reference and to prevent reintroduction.
Workflow
Step 1: Gather and Review Inputs
Collect all relevant information:
- Review the provided data and context
- Identify key parameters and constraints
- Clarify any ambiguities or missing information
- Establish success criteria
Step 2: Analyze the Situation
Perform systematic analysis:
- Identify patterns and relationships
- Evaluate against established frameworks
- Consider multiple perspectives
- Document key findings
Step 3: Generate Recommendations
Create actionable outputs:
- Synthesize insights from analysis
- Prioritize recommendations by impact
- Ensure recommendations are specific and measurable
- Consider implementation feasibility
Output Format
## Reduction Protocol Results
**Artifact:** [Name/description]
**Core Function:** [One-sentence statement of essential purpose]
**Date:** [Analysis date]
### Element Inventory
| Element | Category | Decision | Rationale |
|---------|----------|----------|-----------|
| [Element 1] | Essential | Keep | [Why] |
| [Element 2] | Redundant | Remove | [Why] |
| ... | ... | ... | ... |
### Summary
| Category | Count | Action |
|----------|-------|--------|
| Essential | X | Kept |
| Supportive | X | Y kept, Z removed |
| Decorative | X | Removed |
| Redundant | X | Removed |
| Legacy | X | Removed |
| Anticipatory | X | Removed |
**Total elements:** [Before] → [After]
**Reduction:** [Percentage]
### Removed Elements
[List of removed elements with brief rationale for each]
### Kept Elements
[List of essential elements that remain, with justification for any non-obvious inclusions]
### Resulting Artifact
[Description of the reduced artifact]
### Validation
- Core function preserved: [Yes/No with evidence]
- Edge cases addressed: [Yes/No with notes]
- Constraints satisfied: [Yes/No with notes]
### Recommendations
[Any additional observations or suggestions for further improvement]
Constraints
- Never remove elements without understanding their purpose first
- Distinguish "unused" from "essential safety net"
- Consider the complete user, not just the primary use case
- Reduction is not about minimizing count, but maximizing clarity
- Some elements earn their place through rare but critical use
Outputs
Primary Output: A structured analysis document that identifies and articulates patterns, insights, and actionable recommendations based on the input data.
Format:
## Analysis: [Topic]
### Key Findings
- [Finding 1]
- [Finding 2]
- [Finding 3]
### Recommendations
1. [Action 1]
2. [Action 2]
3. [Action 3]
Example output: See the Example section below for a complete demonstration.
Example
Input: "Simplify this weekly status report template"
Artifact: 12-section weekly status report template Core Function: Communicate project status to stakeholders so they can make decisions
Output:
Reduction Protocol Results
Artifact: Weekly status report template Core Function: Communicate project status to stakeholders for decision-making Date: 2026-01-18
Element Inventory
| Element | Category | Decision | Rationale |
|---|---|---|---|
| Project name/date header | Essential | Keep | Identifies the report |
| Executive summary | Essential | Keep | Core communication |
| Detailed task breakdown | Redundant | Remove | Duplicates project management tool |
| Risk register excerpt | Supportive | Keep (condense) | Supports decisions |
| Team member activity log | Decorative | Remove | Interesting but not decision-relevant |
| Budget variance | Essential | Keep | Key decision factor |
| Customer feedback verbatim | Anticipatory | Remove | Rarely read; summary sufficient |
| Historical comparison | Legacy | Remove | Added years ago, no one uses |
| Next week's forecast | Essential | Keep | Core communication |
| Appendix A-D | Redundant | Remove | Available in other systems |
| Signature blocks | Legacy | Remove | Digital reports need no signatures |
| Distribution list | Decorative | Remove | Email handles distribution |
Summary
| Category | Count | Action |
|---|---|---|
| Essential | 4 | Kept |
| Supportive | 1 | Kept (condensed) |
| Decorative | 2 | Removed |
| Redundant | 2 | Removed |
| Legacy | 2 | Removed |
| Anticipatory | 1 | Removed |
Total elements: 12 → 5 Reduction: 58%
Removed Elements
- Detailed task breakdown: Duplicates Jira; stakeholders don't read granular tasks
- Team member activity log: Activity ≠ progress; creates accountability theater
- Customer feedback verbatim: Summary of themes sufficient; verbatim in separate system
- Historical comparison: No stakeholder has requested or referenced in 18 months
- Appendices A-D: Reference materials available in shared drive; inclusion bloats report
- Signature blocks: Vestige of paper process; no function in digital workflow
- Distribution list: Email system handles; redundant in document body
Kept Elements
- Header: Project identification (condensed to one line)
- Executive summary: 3-bullet status (on track / at risk / blocked)
- Key risks: Top 3 only, with owner and mitigation
- Budget variance: Actual vs. planned, variance explanation if >5%
- Next week forecast: 3 key milestones/deliverables
Resulting Artifact
One-page report: Header + 3-bullet summary + 3 risks + budget line + 3 forecasted items. Readable in under 2 minutes. Decision-relevant information only.
Validation
- Core function preserved: Yes - stakeholders receive information needed for decisions
- Edge cases addressed: Yes - detailed information available via links to source systems
- Constraints satisfied: Yes - compliance requirements met through executive summary
Recommendations
- Add single hyperlink to detailed project dashboard for those wanting depth
- Establish consistent day/time for distribution to create predictable rhythm
- Review template quarterly: what's being read? what prompts questions?
Integration
This skill is part of the Dieter Rams expert persona. Use it when complexity has accumulated and clarity requires systematic reduction. Remember: the goal is not minimal element count, but maximum clarity of function.