Notes

Part 2 of 2 — Part 1, on the discipline behind the tool, is A Tool That Never Gives the Same Answer Twice.

1. Mark the maker

Let it be known, at a glance, which decision came from a machine and which came from a human. A distinct color, a distinct label — attribution isn’t decoration, it’s how someone calibrates how much to trust the thing in front of them.

2. Show your reasoning

Every output earns a “why,” grounded in actuals. Genericness is the tell that nothing real is behind it.

3. State it honestly

Say how sure you are, in words the data actually supports. “High confidence” that isn’t backed by anything is the same lie as a fake “+7%” — precision and confidence are one discipline, not two.

4. Leave the door open

Every step can be skipped. Every flow can be exited. Every action can be walked back. A system that forces a path through itself is optimizing for its own completion, not the person using it.

5. Guide, don’t command

Suggest. Don’t instruct. The tone of an output should sound like someone who respects that the human still decides — not someone who expects to be obeyed.

6. Close the loop

Don’t just act and vanish. Say what happens next — “we’ll check back in later” — so a completed action feels acknowledged, not dropped into a void the moment it’s done.

7. Less, louder

Show fewer things, and make the important one unmistakable. Two competing outputs, both shouting, teach a person to ignore both. One clear output, quietly followed by a second, teaches them to trust the first.

8. Show the seams

Trust isn’t earned by hiding how the system works — it’s earned by making the seams visible enough that no one has to wonder.

Part 1 of 2 — Part 2, on the side of the tool a person actually sees, is Designing With AI.

1. Name

Everything that repeats gets a name. An unnamed value is a decision waiting to be made again, slightly differently, every single time it’s asked for.

2. Prove

Avoid abstracting too early. A pattern earns its name through use — not through anticipation of a use that hasn’t happened yet.

3. One truth

Two places that describe the same thing will eventually disagree. Pick one. Make everything else a pointer to it, not a copy of it.

4. Reuse

Look before you build. Most of what you need already exists — the work is checking, not creating.

5. Check

Trust breaks quietly, not loudly. Check the whole list every time, not just the part you remember being wrong last time.

6. Remember

A mistake explained once should not happen twice. Write the lesson down at the exact place the next attempt will find it — not in a note no one will reread.

7. Isolate

Some things must never touch. Draw the wall before you need it, not after something has already leaked through.

8. Stop

A guess that looks like an answer is worse than no answer. When the system doesn’t know, it should say so, plainly — not round up to something that merely looks like confidence.

9. Narrow, not perfect

You cannot make a non-deterministic tool consistent. You can make the space it’s allowed to work in smaller — and say plainly what still varies inside it.

I’ve coded here and there in the past. The interest was always there, but somewhere between the setup, the frameworks, and the unfamiliar syntax, momentum would stall. It was too slow, and too far from the actual making of the thing.

Claude Code changed that. For the first time, I could describe what I wanted and watch it take shape — not as a mockup, but as something real, on a device, that actually worked. The gap between idea and execution collapsed in a way I hadn’t experienced before.

I used it to build Kotodama — a Japanese learning app. Meetings, presentations, phone calls, the doctor. I’ve been in Japan since 2020, and those moments trip me up more often than I would like to admin. So I just wanted to build something to help me level up.

But the app almost isn’t the point. What stuck with me was the experience of building itself — having an idea in the morning and holding something working by the afternoon. Native iOS, real interactions, exactly the way I’d have designed it. No half-way happy compromises on the design.

That’s the part that feels new. As a designer with some technical knowledge, I’d always been close to the build — but never fully in it. Now that gap has closed.

Now I’m thinking, what else is possible? Tools I’ve always wanted but that don’t exist. Utilities built exactly for how I work.

Edit: since this first project, I’ve been actively building with Claude — a React app, Vercel for hosting, using the Claude API and Google Places API.

Get better at communicating on paper.

In product development, not every problem deserves to be solved.

There’s the shiny new thing — a capability someone saw at a conference that suddenly feels like a strategic priority. There’s the problem the team created for itself by patching the wrong thing last quarter. There’s the sudden spike in complaints that looks alarming but disappears on its own in two weeks. And then there’s the genuine, real customer pain that — if you’re honest — won’t actually move the business.

The hard part isn’t identifying these. Most experienced teams can spot them.

The hard part is having the conversation that says: we’re not doing this one.

WYSIATI - What you see is all there is.

“This is the essence of intuitive heuristics: when faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution.”

“People tend to assess the relative importance of issues by the ease with which they are retrieved from memory—and this is largely determined by the extent of coverage in the media.”

“A reliable way to make people believe in falsehoods is frequent repetition, because familiarity is not easily distinguished from truth.”

Notes

• Small habits compound over time. Just 1% better will result in 36 times better after one year.
• Visualise as a plane shifting a few degrees, will result in a very different destination
• Positive compounding: productivity, knowledge, relationships
• Negative compounding: stress, negative thoughts, outrage
• There is a critical threshold for habits to appear
• Forget goals (results..can be shortsighted, forced, success or fail), focus on systems (process that leads to results…reliable, long term, commitment)
• Identity-based habits - when offered a cigarette “no thanks, I am trying to quit” vs “no thanks, I am not a smoker”
• Pointing-and-calling raises level of awareness
• Habit scorecard to raise self-awareness
• Implementation intention I will BEHAVIOUR at TIME in LOCATION (specific commitment beforehand)
• Habit stacking and the Diderot Effect - spiral of consumption that leads to additional purchases. Each action becomes a cue that triggers the next behaviour.
• Environment matters. Cues in your environment affect your behaviour.
• Habits can be easier to change in a new environment as it helps you escape the triggers that nudge you toward your current habit.
• Once habits are formed, they are difficult to break. Making it invisible helps, avoiding is better than resisting
• Dopamine is not just pleasure but motivation, learning, memory, punishment, aversion and anticipation.
• “You’re more likely to find a behaviour attractive if you get to do one of your favourite things at the same time” - temptation bundling
• …
• Humans are wired for instant gratifications and inability to think about long term effects of habits. As a result, it is important to build instant gratification into habits to build for a long term goal. E.g. cooking at home instead of eating out and putting aside the saved money for a trip

Notes

1. Communicating - low-context or high-context
2. Evaluating - direct negative feedback or indirect negative feedback
3. Persuading - principles-first or applications-first
4. Leading - egalitarian or hierachical
5. Deciding - consensual or top-down
6. Trusting - task-based or relationship-based
7. Disagreeing - confrontational or Avoids confrontation
8. Scheduling - linear or flexible

My Tendencies

Communicating - Low (1) <-> High Context (10)

“Simple, verbose, and clear OR rich deep meaning in interactions”

• Japan - 10
• Self - 4 - In the past, maybe this is lower…but I think this has gradually changed and I am somwhere in the middle now.

Evaluating Direct Negative Feedback (1) <-> Indirect negative feedback (10)

“When giving negative feedback, does one give it directly or prefer being indirect and discreet?”

• Japan - 10
• Self - 3

Pursuading Principles First (1) <-> Application First(10)

“Detailed holistic explanations OR specific cases and examples?”

• Japan - 1
• Self - 5

Leading - Egalitarian(1) <-> Hierachical(10)

“Are people in groups egalitarian or prefer hierarchy?”

• Japan - 10
• Self - 4

Deciding Consensual(1) <-> Top down(10)

“Are decisions made in consensus or made top-down?”

• Japan - 1
• Self - 3

Trusting Task based (1) <-> Relationship (10)

“Do people base trust on how well they know each other or how well they work together?”

• Japan - 10
• Self - 4 - I am not entirely sure about this one..!

Disagreeing Confrontational (1) <-> Avoids Confrontation (10)

“Are disagreements tackled directly, or do people prefer to avoid confrontations?”

• Japan - 10
• Self - 7

Scheduling - Linear Time (1) <-> Flexible Time(10)

“Do people see time as absolute linear points or consider it a flexible range?”

• Japan - 1
• Self - 2

Most teams save prototyping for near the end. By then, the direction is set and there’s too much invested to change course. The prototype becomes a formality — built to confirm, not to question.

That’s a waste.

Prototyping works best when you still don’t know the answer. A rough prototype early in a project does something no meeting or document can: it makes assumptions visible. You stop arguing about what might work and start watching what actually does.

And it doesn’t need to be digital. Walking a colleague through a sketch is a prototype. A scripted conversation simulating a new onboarding flow is a prototype. A paper journey taped to a whiteboard is a prototype.

The medium isn’t the point. The point is getting something in front of a real person before your team has become too attached to defend it.

Build earlier. Build rougher. Learn faster.