ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity
BMAD-METHOD/devKalla-Fordonscervice/_wds/workflows/8-ongoing-development/steps/step-8.3-design-update.md

7.7 KiB
Raw Blame History

Step 8.3: Design Update

Your Task

Design the incremental improvement - not a complete redesign, but a targeted update.

Before You Start

Ensure you have:

  • ✅ Completed step 8.2 (context gathered)
  • ✅ Root cause identified
  • ✅ Hypothesis formed
  • ✅ Clear scope defined

Kaizen Principle: Small, Focused Changes

Remember:

  • ❌ Complete redesign
  • ✅ Targeted improvement
  • ❌ Change everything
  • ✅ Change one thing well
  • ❌ Big bang release
  • ✅ Incremental update

Design Process

1. Define What's Changing vs What's Staying

Create: C-Scenarios/XX-update-name/change-scope.md

# Change Scope: [Update Name]

## What's Changing

### Screen/Feature: [Name]

**Changes:**

- [ ] Copy/messaging
- [ ] Visual hierarchy
- [ ] Component usage
- [ ] User flow
- [ ] Interaction pattern
- [ ] Data structure

**Specific changes:**

1. [Specific change 1]
2. [Specific change 2]
3. [Specific change 3]

---

## What's Staying

**Unchanged:**

- ✓ Brand colors
- ✓ Typography
- ✓ Core layout structure
- ✓ Navigation pattern
- ✓ Tech stack
- ✓ Data model

**Rationale:**
[Why are we keeping these unchanged?]

Example:
"Brand colors and typography are fixed by brand guidelines.
Core layout structure works well and changing it would
require extensive development. We're focusing on content
and interaction improvements only."

2. Create Update Specifications

For each screen/feature being updated:

File: C-Scenarios/XX-update-name/Frontend/specifications.md

# Frontend Specification: [Screen Name] UPDATE

**Type:** Incremental Update
**Version:** v2.0
**Previous Version:** v1.0 (see: archive/v1.0-specifications.md)

---

## Change Summary

**What's different from v1.0?**

1. [Change 1]: [Brief description]
2. [Change 2]: [Brief description]
3. [Change 3]: [Brief description]

---

## Updated Screen Structure

### Before (v1.0)

[Describe old structure]


### After (v2.0)

[Describe new structure]


---

## Component Changes

### New Components
- [Component name]: [Purpose]

### Modified Components
- [Component name]: [What changed?]

### Removed Components
- [Component name]: [Why removed?]

### Unchanged Components
- [Component name]: [Still used as-is]

---

## Interaction Changes

### Before (v1.0)
1. User does X
2. System responds Y
3. User sees Z

### After (v2.0)
1. User does X
2. **NEW:** System shows guidance
3. System responds Y
4. **NEW:** System celebrates success
5. User sees Z

---

## Copy Changes

### Before (v1.0)
"[Old copy]"

### After (v2.0)
"[New copy]"

**Rationale:** [Why this change?]

---

## Visual Changes

### Before (v1.0)
- Hierarchy: [Description]
- Emphasis: [Description]
- Spacing: [Description]

### After (v2.0)
- Hierarchy: [What changed?]
- Emphasis: [What changed?]
- Spacing: [What changed?]

---

## Success Metrics

**How will we measure if this update works?**

- Metric 1: [Before] → [Target]
- Metric 2: [Before] → [Target]
- Metric 3: [Before] → [Target]

**Measurement period:** 2 weeks after release

3. Design New/Modified Components

If you need new components:

File: D-Design-System/03-Atomic-Components/[Category]/[Component-Name].md

# Component: [Name]

**ID:** [cmp-XXX]
**Type:** [Button | Input | Card | etc.]
**Status:** New (for Update DD-XXX)
**Version:** 1.0

---

## Purpose

**Why this component?**

Example:
"Inline tooltip to guide users through Feature X on first use.
Needed because analytics show 40% drop-off due to confusion."

---

## Specifications

[Standard component spec format]

---

## Usage

**Where used:**

- Screen X: [Context]
- Screen Y: [Context]

**When shown:**

- First time user sees Feature X
- Can be dismissed
- Doesn't show again after dismissal

4. Update Existing Scenarios

If modifying existing scenarios:

File: C-Scenarios/XX-existing-scenario/Frontend/specifications-v2.md

# Frontend Specification: [Scenario Name] v2.0

**Previous Version:** v1.0
**Changes:** [Summary of changes]
**Reason:** [Why we're updating]

---

## What Changed

### Change 1: [Name]

- **Before:** [Description]
- **After:** [Description]
- **Rationale:** [Why?]

### Change 2: [Name]

- **Before:** [Description]
- **After:** [Description]
- **Rationale:** [Why?]

---

## Updated Specification

[Full updated specification]

---

## Migration Notes

**For developers:**

- [What needs to change in code?]
- [Any breaking changes?]
- [Backward compatibility?]

5. Create Before/After Comparison

Visual documentation of the change:

File: C-Scenarios/XX-update-name/before-after.md

# Before/After: [Update Name]

## Before (v1.0)

**Screenshot/Description:**
[What it looked like before]

**User Experience:**

- User sees: [Description]
- User feels: [Description]
- Problem: [What was wrong?]

**Metrics:**

- Usage: 15%
- Drop-off: 40%
- Satisfaction: 3.2/5

---

## After (v2.0)

**Screenshot/Description:**
[What it looks like after]

**User Experience:**

- User sees: [Description]
- User feels: [Description]
- Improvement: [What's better?]

**Expected Metrics:**

- Usage: 60% (target)
- Drop-off: 10% (target)
- Satisfaction: 4.5/5 (target)

---

## Key Changes

1. **[Change 1]**
   - Before: [Description]
   - After: [Description]
   - Impact: [Expected improvement]

2. **[Change 2]**
   - Before: [Description]
   - After: [Description]
   - Impact: [Expected improvement]

3. **[Change 3]**
   - Before: [Description]
   - After: [Description]
   - Impact: [Expected improvement]

Design Validation

Before moving forward, validate your design:

Self-Review Checklist

  • Does this solve the root cause?
  • Is this the smallest change that could work?
  • Does this align with existing design system?
  • Is this technically feasible?
  • Can we measure the impact?
  • Does this create new problems?
  • Have we considered edge cases?

Hypothesis Validation

# Hypothesis Validation: [Update Name]

## Hypothesis

[What do we believe will happen?]

Example:
"If we add inline onboarding to Feature X, usage will
increase from 15% to 60% because users will understand
how to use it."

## Assumptions

1. [Assumption 1]
2. [Assumption 2]
3. [Assumption 3]

## Risks

1. [Risk 1]: [Mitigation]
2. [Risk 2]: [Mitigation]

## Success Criteria

- [Metric 1]: [Current] → [Target]
- [Metric 2]: [Current] → [Target]
- [Timeframe]: 2 weeks after release

## Failure Criteria

If after 2 weeks:

- [Metric 1] < [Threshold]: Rollback or iterate
- [Metric 2] < [Threshold]: Rollback or iterate

Next Step

After designing the update:

[C] Continue to step-8.4-create-delivery.md

Success Metrics

✅ Change scope clearly defined ✅ Update specifications created ✅ New/modified components designed ✅ Before/after comparison documented ✅ Hypothesis validated ✅ Self-review complete ✅ Smallest effective change identified

Failure Modes

❌ Scope creep (changing too much) ❌ Not documenting what's staying the same ❌ No before/after comparison ❌ Can't measure impact ❌ Creating new problems ❌ Not validating hypothesis

Tips

DO ✅

Be surgical:

  • Change only what's necessary
  • Keep scope tight
  • One improvement at a time

Be clear:

  • Document what's changing
  • Document what's staying
  • Show before/after

Be measurable:

  • Define success metrics
  • Set realistic targets
  • Plan measurement

DON'T ❌

Don't scope creep:

  • "While we're at it..." ❌
  • Stay focused ✅

Don't redesign:

  • Complete overhaul ❌
  • Targeted improvement ✅

Don't guess:

  • Use data to validate
  • Test hypotheses
  • Measure impact

Remember: Kaizen is about small, focused improvements that compound over time!