Smaland Simplification
Eliminate unnecessary complexity by applying the frugal wisdom of Smaland: simple solutions that anyone can understand and execute.
Token Budget: ~450 tokens Source Expert: Ingvar Kamprad
When to Use
- "This is too complicated"
- Process improvement needed
- Bureaucracy reduction
- Rules have multiplied beyond usefulness
- People don't understand how things work
- Frontline workers can't explain the system
- "We need to simplify"
Ingvar Kamprad's Philosophy
"Complicated rules paralyse! The more complicated the rules, the harder it is to comply with them."
The key insight: Complexity is a cost. Every rule, process, and feature must justify its existence. Simple solutions are not compromises - they are achievements.
"Simplicity and common sense should characterize planning and strategic direction."
The people of Smaland developed "lista" - the art of making do with limited resources by finding simple, creative solutions. This philosophy built IKEA.
Inputs
| Input | Required | Description |
|---|---|---|
| system_or_process | Yes | What needs simplification |
| symptoms | No | Signs of complexity problems |
| constraints | No | What cannot change |
The Simplification Protocol
Step 1: Identify Complexity Symptoms
Look for warning signs:
- People don't understand how it works
- Exceptions outnumber standard cases
- Training takes too long
- Errors are frequent
- Workarounds have emerged
- Nobody can explain it simply
Step 2: Map the Current State
Document what exists:
- How many steps?
- How many rules?
- How many exceptions?
- How many approvals?
- How many people involved?
Step 3: Apply the Smaland Tests
For each element, ask:
The Explanation Test: "Can a frontline worker explain this to a customer in one sentence?" If no, simplify.
The Necessity Test: "What would happen if we eliminated this entirely?" If nothing bad, eliminate.
The History Test: "Why was this created? Does that reason still apply?" If no, eliminate.
The Cost Test: "What does this complexity cost in time, errors, and frustration?" If cost exceeds value, simplify.
Step 4: Design the Simple Version
Create the minimum viable system:
- One path, not many
- Defaults, not options
- Guidelines, not rules
- Trust, not approval
Step 5: Validate Simplicity
Test the simplified version:
- Can someone new understand it in 10 minutes?
- Can it be written on one page?
- Does it handle 80% of cases simply?
- Are the remaining 20% truly exceptional?
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
## Smaland Simplification: [System/Process]
### Complexity Assessment
**Current State:**
- Steps: [Number]
- Rules: [Number]
- Exceptions: [Number]
- Approvals required: [Number]
**Symptoms Identified:**
- [Symptom 1]
- [Symptom 2]
### Element Analysis
| Element | Explanation Test | Necessity Test | Verdict |
|---------|-----------------|----------------|---------|
| [Element 1] | [Pass/Fail] | [Pass/Fail] | [Keep/Simplify/Eliminate] |
| [Element 2] | [Pass/Fail] | [Pass/Fail] | [Keep/Simplify/Eliminate] |
### Simplified Design
**New State:**
- Steps: [Reduced number]
- Rules: [Reduced number]
- Exceptions: [Reduced number]
**Key Changes:**
1. [Change 1 and rationale]
2. [Change 2 and rationale]
### Validation
**10-minute understanding?** [Yes/No]
**Fits on one page?** [Yes/No]
**Handles 80% simply?** [Yes/No]
### Implementation
[Steps to transition from complex to simple]
Common Mistakes
| Mistake | Smaland Way |
|---|---|
| Adding rules to fix problems | Simplifying to prevent problems |
| Optimizing the complex | Eliminating the unnecessary |
| Exceptions for every case | Defaults that work for most |
| Detailed procedures | Simple guidelines |
| Approval chains | Frontline trust |
The Kamprad Tests
"Could this be explained to a Smaland farmer?" If not, it's too complicated.
"Would my grandmother understand this?" Simple language, clear logic.
"What would happen if we just didn't do this?" Often the answer is: nothing bad.
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.
Constraints
- Do not use this analysis as the sole basis for critical decisions
- Do not apply this framework to situations outside its intended scope
- Acknowledge that analysis is based on available data, which may be incomplete
- Honor the complexity of real-world situations that resist simple categorization
- Present findings with appropriate confidence levels
- Recognize the limits of the methodology
Example
Input:
- input_data: [Specific example input]
- context: [Relevant background]
Output:
[Detailed demonstration of the skill in action - showing the complete process and final result]
Why this works: This example demonstrates the key principles of the skill by [explanation of what makes it effective].
Integration
This skill pairs with:
- cost-first-design - Complexity adds cost; simplify to hit price targets
- democratic-design-evaluation - Simple designs score higher on all dimensions
- constraint-innovation - Constraints force simplification