TAKANOBU SAITO / PORTFOLIO Back to the central hub ↗

04 / How I work

Turn ambiguous problems into a form people can make decisions from.

I do not pretend to know the answer from the start. I observe, narrow the question, set criteria for comparison, build something that works, and test it.

Seven steps for documenting why I chose a particular sequence and structure, not just the finished screen.

  1. 01ObserveOBSERVE
  2. 02Define the problemDEFINE
  3. 03Set decision criteriaCRITERIA
  4. 04Compare optionsCOMPARE
  5. 05Build a working versionBUILD
  6. 06Verify and distinguishVERIFY
  7. 07Connect it to operationsOPERATE

Decision before decoration

A method is not the goal in itself.

The goal is not to move mechanically through each step. If the nature of the uncertainty changes, return to an earlier step. What matters is being able to trace the reasoning behind a decision at any time.

Seven-step decision loop

Connect the question to ongoing operations.

For each step, make clear what question to ask, what to document, and which case demonstrates it.

  1. 01

    Observe

    Look for where people get stuck before taking requests at face value.

    Instead of starting with “build a page” or “add a feature,” find who is uncertain, where they get stuck, and what they cannot choose.

    Ask
    At what point do people stop, and what are they unsure about?
    Document
    Observed facts, people affected, barriers, and unknowns.
    Understanding users in a pet-care UX project
  2. 02

    Define

    Narrow the problem until it can be stated in one sentence.

    Separate the people, situation, uncertainty, and desired change; define whether the issue is missing information, inability to compare, or emotional concern.

    Ask
    Whose decision should change, and what should it become?
    Document
    Problem statement, out-of-scope items, constraints, and success criteria.
    Concern-based entry points in a career assessment
  3. 03

    Criteria

    Set the criteria before generating ideas.

    Do not choose an idea because it looks exciting. First agree on whether users can understand it, compare options, and use it in practice.

    Ask
    What must this option satisfy to be adopted?
    Document
    Evaluation criteria, priorities, required conditions, and acceptable trade-offs.
    Defining comparable products
  4. 04

    Compare

    Document why alternatives were rejected, not only what was selected.

    Compare alternatives against the same criteria. Choose based on the problem, constraints, and effect on the next action, rather than visual preference.

    Ask
    What does this option improve, and what does it trade away?
    Document
    Comparison table, reasons for rejection, chosen structure, and assumptions at the time of the decision.
    Information design for assessment results
  5. 05

    Build

    Build far enough to uncover problems that only appear through interaction.

    Implement navigation, inputs, state changes, exceptions, and responsive behavior to uncover friction that documents cannot reveal.

    Ask
    Does the decision flow remain clear when someone uses it?
    Document
    Working interface, prototype, input conditions, states, and error handling.
    Importing Amazon Ads data
  6. 06

    Verify

    Keep what has been verified separate from what is expected.

    Separate functional checks, user responses, and business outcomes. Make unknowns visible and show what to check next.

    Ask
    What is known, what is a hypothesis, and what remains unknown?
    Document
    Results, observations, limitations, unknowns, and next validation steps.
    Prototype validation
  7. 07

    Operate

    Treat completion as a return to the next decision, not the end.

    Record outcomes, evidence, learnings, and blockers, then connect them to the next task or rule change.

    Ask
    Who should review what next, and what decision should they be able to make?
    Document
    Logs, approvals, next tasks, exceptions, resumption criteria, and operational learnings.
    Operating structure of the AI control room

Three rules

Three distinctions that protect decision quality.

Keep the problem, the choice, and the evidence distinct. This makes it easier to ground discussion and implementation in decision criteria.

01

Separate requests from problems.

Do not build a requested feature by default; first ask what it is meant to change.

02

Separate options from evaluation criteria.

Do not choose by preference alone; compare options against conditions agreed on in advance.

03

Separate outcomes from expectations.

Validate separately that the interface works, users understand it, and business outcomes follow.

The method in real work

The same decision process runs through five cases.

Across domains, the process remains the same: find uncertainty, set criteria, build a working version, and make it verifiable.

  1. 01Turn uncertainty into a sequence of actionsPet dental-care UXVIEW
  2. 02Bring emotions and practical constraints into one assessmentCareer transition guide for women in their 40s and 50sVIEW
  3. 03Define the product before comparing pricesPrice comparison service for unopened MTG productsVIEW
  4. 04Design the boundary between AI and human decisionsMulti-Agent AI Operations Control RoomVIEW
  5. 05Turn keyword wins and losses into the next testAmazon Keyword Win/Loss DashboardVIEW