SPARK Framework

A practical review framework for useful, accessible AI experiences.

SPARK is the framework I use to evaluate product decisions in AI-powered experiences, especially when teams need to balance automation, trust, accessibility and human judgment.

Explore the principles See it in the cases

Why it exists

Make the trade-offs visible before automating decisions.

Automation can feel like pressure

Users need clear control over suggestions, defaults and final decisions.

Confidence is easy to overstate

AI outputs should communicate uncertainty, limits and recovery paths honestly.

Accessibility cannot be cosmetic

Reading support, cognitive clarity and assistive settings need to shape the product from day one.

The model

Five principles, one practical review lens.

S

Support, do not solve

AI should help people move forward without pretending to own the final answer.

  • Can the user edit, reject or compare the suggestion?
  • Is the AI output clearly separate from the user's final decision?
  • Does the interface reveal what changed and why it matters?
P

Protect the person

Design choices should avoid pressure, dark patterns and unnecessary disclosure.

  • Are defaults respectful and easy to change?
  • Is sensitive context minimized, anonymized or optional?
  • Can the user recover from a mistake without penalty?
A

Accessibility from the start

Access needs to be a product strategy, not a late compliance pass.

  • Does the flow work for different reading, motor and sensory needs?
  • Are labels, states and hierarchy understandable without guesswork?
  • Can users adjust the experience without losing functionality?
R

Reduce cognitive load

Complex systems need visible structure, not more instructions.

  • Are tasks grouped around user intent instead of internal logic?
  • Does each screen make the next action obvious?
  • Are edge cases handled before they become support tickets?
K

Keep it human

Responsible AI keeps human review, context and care inside the workflow.

  • Where does a person need to approve, intervene or escalate?
  • Does the interface make accountability visible?
  • Are automated moments balanced with human judgment?

How I use it

Use SPARK to structure product questions and design decisions.

  1. Map the risk. Identify where AI, accessibility, data sensitivity or uncertainty could affect user trust.
  2. Define the human role. Clarify what the system can suggest, what the user controls and where review is required.
  3. Design the states. Cover loading, confidence, empty, error, escalation, permission and recovery moments.
  4. Test comprehension. Validate whether people understand what is happening, what they can change and what happens next.
  5. Document the pattern. Turn the decision into reusable guidance for design, product and engineering.

In practice

Related decisions across my work.

A retrospective reading of existing work through SPARK. The examples below connect documented decisions to the principles; they do not imply that SPARK was used during the original projects.

Worked example · retrospective review

Reviewing credit limits in AI Companion

The documented design separates trial, registration and subscription states. This review uses SPARK to identify what those states should make clear and what still needs user testing.

AI Companion interface illustrating the product reviewed through SPARK.
Support, do not solve
Can someone understand what they can try before deciding to register? Keep trial conditions visible at the point of use.
Protect the person
Are credit costs and saving restrictions clear before an action? Verify that people can anticipate the consequences without discovering them through a blocked task.
Accessibility from the start
Can credit balances and account states be understood with a keyboard and screen reader? Review text labels, focus order and status announcements.
Reduce cognitive load
Can someone compare the three access levels without remembering scattered rules? Present credits, continuity and saving permissions together.
Keep it human
Can someone decide whether to register or subscribe without pressure? Explain the options and let the person control the next step.

Next validation: ask participants to explain what they can try, save and continue in each state before acting. These are review questions and proposed checks, not completed research findings.

See the documented access states →
Nebula Research-informed reading, clearer navigation and parent visibility in a self-initiated product prototype. AI Bot Operations Dashboard Operational hierarchy, status visibility and investigation paths for conversational AI teams. AI Companion Experience Chat, voice, prompts, personas and account states reorganized into a clearer product architecture. Inclusive Digital Banking Research-led strategy for trust, comprehension and accessibility in high-stakes financial tasks.