Design Engine And Product Improvement

Design Engine And Product Improvement

Run a disciplined Kaizen loop for the design-system engine and for the websites, apps, documents, games, dashboards, and visual systems it helps produce.

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

Use When

• Auditing the design-system engine itself: doctrine, routing, skill contracts, references, examples, evidence, currency, and handoff quality.
• Auditing a product or design system across screens, states, platforms, components, documents, game visuals, or AI interfaces and converting findings into a measurable improvement plan.
• Planning a post-critique or post-release improvement cycle where a small reversible experiment must become a documented standard only after evidence supports it.
• Reviewing a book-derived upgrade and deciding whether the source is usable, current, complete, and sufficiently translated into an actionable design capability.

Do Not Use When

• You need a one-screen diagnostic only; use design-audit.
• You need a multi-surface scored product diagnostic without an engine-improvement backlog; use product-design-audit.
• You need a final ship verdict; use design-qa-and-pre-launch-review after the improvement work.
• You need to invent anatomy facts from an incomplete source; stop and record the evidence gap.

Required Inputs

Stop if the target, scope, or primary artefact is missing. A screenshot-only review may proceed only as a qualified visual audit; it cannot claim interaction, responsive, accessibility, or engine conformance.

Workflow

1. Observe. Inspect the current engine or product. For an engine, glob the live skill tree, read the router and applicable doctrine, and check references, examples, validators, and routing. For a product, cover the named surfaces and critical, empty, error, loading, recovery, responsive, keyboard, and AI states. For premium or client-facing work, also load references/purpose-fit-premium-ux-patterns.md and inspect the purpose-fit brief, originality rationale, real-content slice, and refinement evidence.
2. Baseline. Score the applicable dimensions and record evidence, confidence, and gaps. The reported audit score is hard-capped at 65/100: reported = min(raw score, 65). The cap is a reporting ceiling, not permission to ignore defects.
3. Select. Rank the smallest high-leverage change using user impact, risk, effort, and reversibility. State a falsifiable hypothesis, owner, measure, and stop condition.
4. Experiment. Make the smallest authorised change: a prototype, wording variant, token adjustment, reference addition, workflow change, or limited production trial. Preserve the prior version and record the change boundary.
5. Check. Re-run the relevant visual, readability, accessibility, interaction, performance, routing, or source checks. Compare before/after evidence. Separate observed result from taste, interpretation, and unverified assumption.
6. Standardise. If the evidence meets the acceptance condition, update the owning skill or doctrine reference, add a worked example or test fixture, and record provenance. If it fails, roll back or narrow the change; do not standardise a preference.
7. Teach. Update routing, handoff, critique prompts, or audit evidence so the capability is discoverable by the next agent and downstream domain engines.
8. Re-measure. Produce the next audit record and an improvement plan targeting 95/100. Stop release if required evidence remains unavailable; recover with the narrowest qualified plan.

Decision Rules

Capability Contract

Read, search, inspect, and compare are required. Rendering, measurement, accessibility checks, source verification, and repository validation are used when available. Editing is allowed only for an authorised improvement request. This skill may create an audit and plan but may not publish, delete source evidence, change production, claim certification, or override an accountable owner.

Degraded Mode

Without a build or render, return a qualified specification and mark visual and interaction checks unverified. Without source verification, quarantine current-year claims. Without a validator, run manual contract checks and state the missing gate. Without a baseline, create a provisional baseline with explicit assumptions; do not label it a measured improvement.

Quality Standards

• Every finding names the observed artefact, state, location, evidence, severity, confidence, owner skill, and next measure.
• Every improvement plan targets 95/100 and includes gap, root cause, change, hypothesis, owner, evidence, risk, rollback, acceptance condition, and due cadence.
• Product audits cover value/readability, narrative or task flow, typography, layout, contrast, accessibility, interaction states, AI disclosure/control where relevant, performance, responsive stability, purpose-fit authorship, originality, and handoff/reuse.
• Engine audits cover doctrine, routing, skill contract, references, worked examples, source provenance, validator coverage, degraded mode, and user-facing output evidence.
• Current, legal, regulatory, platform, market, and accessibility claims use verified authority; book-derived principles are attributed without copying source text.

Anti-Patterns

• Kaizen as a slogan. Correction: require a baseline, experiment, measure, standard, owner, and re-measurement.
• Scoring without evidence. Correction: cite the render, file, test, measurement, or source; otherwise mark the dimension unverified.
• Standardising taste. Correction: distinguish a human design decision from a requirement and record the reason rather than laundering taste as research.
• Ignoring failed states. Correction: inspect loading, empty, error, recovery, keyboard, responsive, reduced-motion, and AI uncertainty states before a pass.
• Improvement without rollback. Correction: preserve the previous contract and define a stop/rollback trigger before the experiment.
• Using incomplete books as authority. Correction: quarantine unreadable or unavailable chapters and route verification to Digital Research.
• Calling a copied visual reference premium. Correction: preserve the user problem and transferable principle, then require a client-specific thesis, signature decision, and context demo before standardising.

Outputs

Examples

• examples/design-engine-audit-worked.md - a worked engine audit that caps the report at 65/100, selects a silhouette-readability experiment, and plans the route to 95/100.

Mandatory Digital Research currentness gate

Every Kaizen cycle must begin with digital-research-engine source evaluation and source verification. Record scope, dates, freshness class, support status, uncertainty, and review date for current design, accessibility, browser, platform, security, document, and lifecycle claims; quarantine unsupported claims as NOT_ASSESSED. Apply the portfolio Kaizen currentness gate.

References

• references/kaizen-audit-contract.md - audit dimensions, evidence matrix, score cap, and 95-target improvement-plan schema.
• references/purpose-fit-premium-ux-patterns.md - Eleken-informed friction, dashboard, authorship, and finish patterns translated into evidence-bearing design decisions.
• ../../../docs/continuous-improvement/design-engine-book-upgrade-2026-08.md - provenance, extraction limits, and decisions from the supplied books.
• ../../../governance/design-quality-gate.md - required evidence before declaring visual work done.
• ../../../doctrine/design-doctrine.md - authored visual choices and anti-slop charter.
• design-audit, product-design-audit, and ux-remediation-and-redesign - compose diagnosis, product coverage, and execution without duplicating their domain logic.
• ../../../doctrine/references/book-driven-brand-story-and-visual-evidence.md - durable brand/story synthesis with visual evidence and current accessibility gate.
• Book-driven Kaizen Wave 3 - task-first communication, perceptual integrity, image quality, text alternatives, and current accessibility/performance verification.