Approach & tools

Before the answer, examine the question.

“Every problem is a technical problem” begins, in my work, with examining how the question is defined. Here is how I ask questions, test my own explanations, and choose tools to make an idea inspectable.

Three things help us start.

  • What you want to achieve

    Who will use the result? What decision comes next? What would make this useful?

  • What you have already tried

    Existing plans, observations, data, or a prototype help me understand the problem.

  • What we can work with

    Time, budget, access to users, available tools, and the people who need to take part.

Reframing changes what we can do next.

These are shifts I draw from my practice. A new question must still serve the original goal. Being easier to answer is not enough.

PROTOTYPE / TWO LAYERS
Experience before implementationThe frontstage preserves the start, task, and end of the user experience. A researcher simulates unfinished responses backstage. Test understanding before choosing implementation.FRONTSTAGE / EXPERIENCEBACKSTAGE / SIMULATIONSTART · TASK · ENDWizard-of-Oz
  1. Frontstage · ExperienceStart, perform the task, end
  2. Backstage · SimulationA person follows response rules
  3. Observe & decideTest understanding before implementation

Observe understanding · Simulate the responseConceptual model

Robot interaction

Starting questionHow do we test an unfinished feature?

Separate understanding from implementation.

Simulate key responses with a researcher. Observe how people begin, complete, and end the interaction.

Read the case
EVIDENCE ARCHITECTURE
A route back to the evidence254GB of research records organized by tasks and observations into 86 traceable issues in six categories. Lines show relationships, not data distribution.RESEARCH RECORDS254 GBInterviews · TestsORIGINAL CONTEXTISSUE INDEX86issuesSIX CATEGORIESTask contextObservationSource recordEVERY FINDING HAS A SOURCE
  1. Source recordsKeep tasks and context
  2. Tasks & observationsSeparate actions and interpretations
  3. Traceable issuesEach finding has a source

Records → Tasks & observations → Traceable issuesConceptual model

Research records

Starting questionHow do we organize all these records?

Ask which decision needs which evidence.

Locate observations by task, connect each issue to its source, then discuss what to change.

Read the case
DESIGN WITH FEEDBACK
Build the check into the processInsight informs design, design and observation iterate, and confirmation follows. Tracks show feedback relationships, not iteration counts, durations, or project progress.DESIGN ⇄ OBSERVESTILL CHANGEABLEInsightConfirmFEEDBACK RETURNS TO DESIGN
  1. InsightDefine the assumption to examine
  2. Design ⇄ ObserveReturn feedback while changes are possible
  3. ConfirmationCheck whether the question was answered

Insight → Design & observation in a loop → ConfirmationConceptual model

Design validation

Starting questionHow do we test once development is done?

Check while changes are still possible.

Observe use during design and implementation. Feed findings into the next version, then plan confirmation.

Read the case

Metacognition: examine how the question is framed.

  1. 01

    Separate goal from proposal

    “Hire more people,” “run training,” and “add AI” are proposals. What change do we actually want, and how will we know it happened?

    Output: an agreed question, scope, and criteria for judging the result.

  2. 02

    Inspect conditions and relationships

    What happens across people, information, tools, and handoffs? Is the obstacle within a step or between steps? Which constraints are fixed, and which are habits?

    Output: observations, possible causes, and the evidence we most need next.

  3. 03

    Test competing explanations

    Did the person misunderstand, or did the system fail to respond? Use a simulation, a recording, or a script to look for an observable difference.

    Output: a study plan, simulated experience, or tool prototype we can inspect.

  4. 04

    Check my own reasoning, too

    What result would change my mind? Does the reframed question still serve the original goal? What did the intervention change? Then continue, adjust, or stop.

    Output: results, instructions, open issues, and a plan for further checks.

Toolbox / Methods I have used

The problem determines the tool.

My toolbox includes measurement equipment, research methods, code, and AI. These are concrete jobs they have done. A new problem calls for a fresh choice.

  • OBSERVATION
    Eye trackingEEGBehavior

    Signals in the context of use

    See what actually happens

    Eye tracking · EEG · Interviews · Observation

    In packaging research, I examined visual paths, compared early responses, and observed handling and opening. I interpreted each within the same stage of use.

    Packaging research
  • PROTOTYPING
    Wizard-of-OzTask scriptsSimulation

    Test assumptions through experience

    Try an interaction before building it

    Wizard-of-Oz · Task scripts · Simulations

    In service-robot research, a person behind the scenes simulated unfinished responses so we could observe how users started, completed, and ended an interaction.

    Service-robot research
  • RETRIEVAL
    PythonChromaDBSemantic search

    From a question to sourced context

    Find context that answers a question

    Python · ChromaDB · Keyword and semantic search

    I maintain separate product and usability libraries, adjusting scope and passage boundaries so retrieval returns relevant context with a route back to the source.

    Personal knowledge and AI system
  • ORCHESTRATION
    OpenClawClaude CodeInstructions

    Bounded execution, checkable results

    Connect repeated steps

    OpenClaw · Claude Code · Reusable task instructions

    I combine a runtime, coding assistant, and existing tools for lookup, information handling, and filing, defining inputs, permissions, and checks for everyday use.

    Daily AI workflows

Before choosing a tool, I ask which uncertainty it can resolve or which obstacle it can change. If an observation or a table is enough, I start there.

Check whether the approach helped before investing further.

Research needs its source records, design recommendations need a follow-up check, and tools need real tasks. If evidence is missing, I explain the gap. A small check may be enough to answer the question; further investment follows from what remains worth solving.

Read the cases

Materials to use in your own work

These blank templates and instruction examples were prepared for this website. Download and adapt them to your task. They contain no client data and are not original project deliverables or evidence of results.