- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24) - apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004) - apps/web: React 19 + Vite 8 (ESM) - libs/shared/api-interface: Zod contract base - Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit - WDS artifacts: - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs) - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact) - Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md - AGENTS.md + README.md como entrada para devs/agentes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.9 KiB
Kaizen Principles
Core principles and patterns for continuous improvement in Phase 8 (Product Evolution).
The Kaizen Philosophy
改善 (Kaizen) = Continuous Improvement
Ship → Monitor → Learn → Improve → Ship → Monitor → Learn...
This cycle never stops!
Kaizen vs Kaikaku
Two approaches from Lean manufacturing:
Kaizen (改善) - What You're Doing Now
- Small, incremental changes (1-2 weeks)
- Low cost, low risk
- Continuous, never stops
- Phase 8: Product Evolution
Kaikaku (改革) - Revolutionary Change
- Large, radical changes (months)
- High cost, high risk
- One-time transformation
- Phases 1-7: New Product Development
You're in Kaizen mode! Small improvements that compound over time.
See: src/core/resources/wds/glossary.md for full definitions
Kaizen Principle 1: Focus on Process, Not Just Results
Bad:
- "We need to increase usage!"
- (Pressure, no learning)
Good:
- "Let's understand why usage is low, test a hypothesis, measure impact, and learn."
- (Process, continuous learning)
Kaizen Principle 2: Eliminate Waste (Muda 無駄)
Types of waste in design:
- Overproduction: Designing features nobody uses
- Waiting: Blocked on approvals or development
- Transportation: Handoff friction
- Over-processing: Excessive polish on low-impact features
- Inventory: Unshipped designs
- Motion: Inefficient workflows
- Defects: Bugs and rework
Kaizen eliminates waste through:
- Small, focused improvements
- Fast cycles (ship → learn → improve)
- Continuous measurement
- Learning from every cycle
Kaizen Principle 3: Respect People and Their Insights
Listen to:
- Users (feedback, behavior)
- Developers (technical insights)
- Support (pain points)
- Stakeholders (business context)
- Team (observations)
Everyone contributes to Kaizen!
Kaizen Principle 4: Standardize, Then Improve
When you find a pattern that works:
-
Document it
# Pattern: Onboarding for Complex Features **When to use:** - Feature has low usage (<30%) - User feedback indicates confusion - Feature is complex or non-obvious **How to implement:** 1. Inline tooltip explaining purpose 2. Step-by-step guide for first action 3. Success celebration 4. Help button for future reference **Expected impact:** - Usage increase: 3-4x - Drop-off decrease: 50-70% - Effort: 2-3 days -
Create reusable components
D-Design-System/03-Atomic-Components/ ├── Tooltips/Tooltip-Inline.md ├── Guides/Guide-Step.md └── Celebrations/Celebration-Success.md -
Share with team
- Document in shared knowledge
- Train team on pattern
- Apply consistently
-
Improve the pattern
- Learn from each application
- Refine based on feedback
- Evolve over time
Kaizen Prioritization Framework
Priority = Impact × Effort × Learning
Impact: How much will this improve the product?
- High: Solves major user pain, improves key metric
- Medium: Improves experience, minor metric impact
- Low: Nice to have, minimal impact
Effort: How hard is this to implement?
- Low: 1-2 days
- Medium: 3-5 days
- High: 1-2 weeks
Learning: How much will we learn?
- High: Tests important hypothesis
- Medium: Validates assumption
- Low: Incremental improvement
Kaizen Metrics Dashboard Example
# Kaizen Metrics Dashboard
## This Quarter (Q1 2025)
**Cycles Completed:** 9
**Average Cycle Time:** 10 days
**Success Rate:** 78% (7/9 successful)
**Impact:**
- Feature usage improvements: 6 features (+40% avg)
- Performance improvements: 2 features (+15% avg)
- User satisfaction: 3.2/5 → 4.1/5 (+28%)
**Learnings:**
- 12 patterns documented
- 8 reusable components created
- 3 hypotheses validated
**Team Growth:**
- Designer: Faster iteration
- Developer: Better collaboration
- Product: Data-driven decisions
When to Pause Kaizen
Kaizen never stops, but you might pause for:
1. Major Strategic Shift
- New product direction
- Pivot or rebrand
- Complete redesign needed
2. Team Capacity
- Team overwhelmed
- Need to catch up on backlog
- Need to stabilize
3. Measurement Period
- Waiting for data
- Seasonal variations
- External factors
But always return to Kaizen!
Small Changes Compound
Example trajectory:
Month 1:
- Cycle 1: Feature X onboarding (+40% usage)
Month 2:
- Cycle 2: Feature Y onboarding (+60% usage)
- Cycle 3: Feature Z performance (+15% retention)
Month 3:
- Cycle 4: Feature X refinement (+7% usage)
- Cycle 5: Onboarding component library (reusable)
- Cycle 6: Feature W onboarding (+50% usage)
Month 4:
- Cycle 7: Dashboard performance (+20% engagement)
- Cycle 8: Navigation improvements (+10% discoverability)
- Cycle 9: Error handling (+30% recovery rate)
Result after 4 months:
- 9 improvements shipped
- Product quality significantly improved
- User satisfaction increased
- Team learned continuously
- Competitive advantage built
Each cycle takes 1-2 weeks. Small changes compound!
Kaizen Success Story Example
Starting Point:
- Product satisfaction: 3.2/5
- Feature usage: 25% average
- Support tickets: 50/month
- Churn rate: 15%
After 6 Months (24 Kaizen cycles):
- Product satisfaction: 4.3/5 (+34%)
- Feature usage: 65% average (+160%)
- Support tickets: 12/month (-76%)
- Churn rate: 6% (-60%)
Investment:
- 24 cycles × 1.5 weeks = 36 weeks
- Small, focused improvements
- Continuous learning
- Compounding results
Result:
- Product transformed
- Team learned continuously
- Competitive advantage built
- Users delighted
This is the power of Kaizen! 改善
Remember: Great products aren't built in one big redesign. They're built through continuous, disciplined improvement. One cycle at a time. Forever.