How I think / Working through uncertainty

When the answer isn't obvious yet.

I start with what people are actually trying to accomplish. Then I look at what is happening in reality, find the gap, and change the part of the system that is getting in the way.

The premise

The solution is a hypothesis.
The goal is the goal.

A proposed answer is useful only if it improves the outcome. When reality contradicts the answer, the answer changes.

A recurring way of working

Follow the problem, not a predetermined solution.

“System” is intentionally broad. It might be a product, workflow, information architecture, tool, knowledge, training, authority, policy, organizational structure, or environment.

  1. Understand the goal

    What is supposed to happen? What are people actually trying to accomplish? Before solving anything, find out whether the people involved even agree on the goal.

    The outcome is the anchor.

  2. Observe reality

    Look at the actual workflow, not only how it is documented or described. Ask people to show what they do. Notice hesitation, repetition, workarounds, escalation, abandonment, and unnecessary dependency.

    Hesitation is data.

  3. Understand why

    Unusual behavior does not automatically mean someone is doing something wrong. Ask what purpose it serves and what constraint, capability, information, or recovery path may be missing.

    Don't optimize away behavior before understanding what purpose it serves.

  4. Find the actual friction

    Determine whether the problem belongs to the product, process, knowledge, training, tooling, authority, policy, staffing, environment, or some combination of them.

    Don't automate confusion.

  5. Change the appropriate part of the system

    The intervention follows the problem. Sometimes I build something. Sometimes the capability already exists and the work is making it usable. The answer might instead be documentation, enablement, workflow redesign, clearer authority, or deliberately preserving useful friction.

    Useful friction and accidental friction are not the same.

  6. Test against reality

    Completion alone is not success. Did the change accomplish the goal? Did it introduce unnecessary steps, anxiety, confusion, or new dependencies? Can people recover when something goes wrong?

    Technically functional isn't the same as successful.

  7. Refine

    Edge cases and failures are information. If the intervention misses the goal, revise the intervention rather than defending it.

    Measure the outcome, not just the intention.

  8. Operationalize

    The final question is whether people can continue succeeding without unnecessary dependence on the person who built or fixed the system.

    Capability beats dependency.

The outcome

Clarity.Capability.Confidence.

People understand what they are doing, can accomplish what they need to accomplish, and know what happens next or how to recover when something goes wrong.

Confidence comes from knowing you can recover.

See the work