Choose product→Choose control→Confirm
Working practice / AI methodology
Human judgment · AI leverage · Evidence
Human-led.
AI-amplified.
A repeatable design methodology for exploring wider, materializing faster, and making better-informed human decisions.
Living methodologyVersion 01 · Safety Shield example
AI expands the option space.
Evidence narrows it.
Human judgment commits.
The operating loop
Six phases. One accountable designer.
This is not a linear production line. Each phase can expose uncertainty that sends the work back to framing or context.
01Frame
→Define the decision
02Build context
→Separate evidence
03Expand
→Generate perspectives
04Materialize
→Make it testable
05Challenge
→Find failure
06Decide
Own the trade-off
New evidence creates another loop
Example challenge
How should a customer enter a safety system when they don’t know what happened?
Safety Shield provides a bounded example of how the method moves from an ambiguous question to a traceable product decision.
Decision to make
Choose the entry model for customers in an uncertain, high-stress security moment.
Inputs available
Problem framing · domain constraints · existing journey logic
Unknowns
Customer comprehension · operational feasibility · safe disclosure level
Non-negotiables
Immediate protection · clear consequences · safe recovery
Success criteria
Speed · comprehension · confidence · operational feasibility
Risk level
High — a wrong interaction can delay protection or expose security logic.
01 / Build context
Better context beats a clever prompt.
Before generation, I construct a controlled context pack and label what is known, inferred, assumed, and decided.
Problem briefDecision and scope
Research evidenceOnly supplied or traceable sources
Domain constraintsRisk · regulation · operations
Product principlesProtect first · recover clearly
VocabularyCustomer language before product language
Open questionsLabeled before exploration
Privacy rulesNo sensitive customer data
Evaluation rubricDefined before generation
Information hygiene
Not everything plausible is true.
Every important statement keeps its epistemic status. AI-generated inference is never allowed to silently become research evidence.
Source
Verified input
Only statements tied to supplied research, product data, or domain documentation enter this layer.
Source reference requiredInference
Interpretation of evidence
Customers may understand incidents more easily than banking product architecture.
Must be traceableHypothesis
Needs testing
An incident-first entry could reduce time to an appropriate protective action.
Not a findingDecision
Human commitment
Explore incident-based entry alongside a universal Shield route.
Owner · Buse02 / Expand
I don’t ask AI for an answer. I assign thinking roles.
Each role has a narrow purpose, a defined boundary, and a different design artifact as its output.
Explorer
Reframe the problem
Generate materially different interpretations—not UI variations.
Output · ReframesResearch partner
Find patterns and contradictions
Organize supplied evidence without inventing participants or findings.
Output · SynthesisSystems thinker
Expose dependencies
Map states, actors, constraints, and edge cases.
Output · System mapChallenger
Attack assumptions
Argue against the preferred direction and identify hidden risk.
Output · CritiqueMaker
Materialize alternatives
Turn directions into flows, copy, prototypes, and working code.
Output · PrototypeEvaluator
Apply the rubric
Compare outputs consistently; never define and grade success alone.
Output · Scorecard03 / Expand directions
Three different models, not three different skins.
The same question is deliberately expressed as three product models so their strengths, risks, and assumptions can be compared before visual polish.
Choose incident→Answer questions→Targeted action
Know / unsure→Incident / Shield→Recovery
04 / Materialize
The value is visible in the intervention.
The method keeps the initial output, the human critique, and the designed response visible as one chain of reasoning.
AI starting point
Select what to lock
A product-control model is generated quickly, but transfers the diagnosis burden to the customer.
Human critique
- Assumes the customer understands product risk.
- Turns panic into a configuration task.
- Does not communicate immediate safety.
- Ignores customers who cannot diagnose the event.
The critique reframes the problem around certainty, urgency, and the need for a safe default.
Designed response
Do you know what happened?
The final direction separates known incidents from uncertainty and keeps universal protection within reach.
05 / Challenge
Every output must survive four checks.
The rubric is defined before final generation so the AI is not allowed to invent the work and its own definition of success.
Evidence
- Can every claim be traced?
- Is inference presented as fact?
- What remains unknown?
Product
- Does it solve the actual problem?
- Does it respect constraints?
- Is it simpler, not only fuller?
Experience
- Is the mental model clear?
- Are error and recovery designed?
- Is user control preserved?
Adversarial
- How can this be misunderstood?
- What happens when AI is wrong?
- Can it leak or create harm?
Failure & recovery
Design the failure before trusting the success.
I explicitly look for hallucination, shallow consensus, missed edge cases, generic output, and unsafe handling of context.
FailureHow I detect itDesign response
Invented research findingSource trace failsReject; return to evidence
Premature convergenceDirections share one mental modelReframe with opposing lenses
Missed edge caseAdversarial reviewExpand state model
Polished but generic UIDomain and usability rubricRework hierarchy and interaction
Sensitive context includedPrivacy checklistRemove, anonymize, isolate
06 / Decide
AI proposes. The decision record has a human owner.
- What we chose
- Incident-first guidance plus a universal Shield route.
- What we rejected
- A product-first control list and a purely incident-first route; both make the customer diagnose too much under pressure.
- Evidence
- Problem framing, customer-language principles, security constraints, and the edge-case review.
- Trade-off
- More back-end orchestration in exchange for lower customer diagnosis burden.
- Confidence
- Medium — the interaction logic is coherent; operational feasibility and comprehension still require validation.
- What would change this
- Evidence that broad containment creates unacceptable harm, or that customers misread the two-route entry model.
Practice boundaries
Speed is useful only when trust survives it.
AI can
Explore possibilities
Organize supplied material
Generate alternatives
Surface inconsistency
Accelerate prototypes
AI cannot own
User truth
Research validity
Product trade-offs
Ethics and privacy
Final quality judgment
I remain responsible for
Problem framing
Evidence integrity
Interaction quality
Decision ownership
Consequences
Method outcomes
What changes when I work this way?
The value is not the volume of generated output. It is a broader, faster, and more inspectable decision process.
01Broader option space
Compare mental models before polishing screens.
02Faster materialization
Turn ideas into flows and interfaces early.
03Earlier risk discovery
Challenge assumptions before build.
04Clearer ownership
Record why a human committed to a direction.
Method reflection
AI is most useful when it expands the work I can inspect—not when it hides the reasoning behind a polished answer. It speeds up reframing and materialization, but increases the importance of source discipline, critique, and explicit decision ownership.
Practice references