Things I figured out
with my hands

FIELD NOTE 01 the hospital project · a Tuesday

The default is the design

how one half-laughing sentence rerouted a whole study

I almost walked past it, because it was so boring.

A hospital had hired me to find out why older adults weren't getting their flu shots. Everyone on the team arrived with a theory, and every theory was about belief — hesitancy, mistrust, the usual suspects. So that's what I went hunting for.

I didn't find it. What I found, sitting beside people and their phones, was that almost nobody had decided no. They'd just… never reached the moment where “yes” became an appointment. The booking link was three taps deep. It wasn't top of mind. One woman told me, half-laughing, “I'd do it if it just told me when to show up.”

So we stopped trying to change minds and changed the default instead: book the appointment for them, one tap to move or cancel. Almost nobody opted out. Most simply showed up.

The pre‑selected option is never neutral. It is the design.

And it scares me a little, because it cuts both ways. The same move that got people their flu shots is the one that quietly signs you up for a subscription you'll forget to cancel. So I keep one question taped next to that sentence: would the user thank me if they understood exactly what this default does? If the honest answer is “only if they don't notice” — I already know I'm building the wrong thing.

The theory has a tidy name: choice architecture — Thaler and Sunstein's Nudge is the field guide for it. It works because most of us, most of the time, run on the fast, automatic “System 1” Kahneman describes: we take the path that's already laid out.

further reading — the canonical proof: Johnson & Goldstein, “Do Defaults Save Lives?” (Science, 2003).

FIELD NOTE 02 NVivo open · Claude open

The confident wrong answer

letting AI into my research without letting it lie to me

An AI once told me, very confidently, that sixty people wanted the same thing. They didn't.

These days my qualitative workflow is half NVivo, half Claude. I'll hand an LLM a stack of interview transcripts and ask it to surface the themes — the same first‑pass coding I'd do by hand, but in minutes instead of an afternoon. Used well, it's the biggest speed‑up my craft has had in years. I'll also vibe‑code a rough, clickable prototype in Cursor to test an idea before a team commits a whole sprint to it.

But here's the trap I walked into early. Asked for “the main theme” across a batch of interviews, the model handed me one tidy sentence: users want speed above all. Clean. Quotable. Wrong. Two camps were hiding in there — power users who wanted speed, and newcomers quietly begging for guidance. The AI had ironed the tension flat, and it did it in the exact same confident voice it uses when it's right.

The danger isn't that AI is sometimes wrong. It's that it's wrong in the register of certainty.

So I let AI accelerate the work, never close it. It drafts the codes; I read the transcripts. It proposes a theme; I check the quotes behind it. Jakob Nielsen called generative AI the first genuinely new interaction paradigm in sixty years, and we're still writing its manners — Microsoft's Guidelines for Human‑AI Interaction even devote a whole group to the moment the system gets something wrong. Under it all sits an old Don Norman idea: the gulf of evaluation, the gap where you can't tell what just happened. A confident wrong answer is that gulf, gift‑wrapped.

further reading — Jakob Nielsen, “AI: First New UI Paradigm in 60 Years” (NN/g, 2023) · Microsoft, Guidelines for Human‑AI Interaction.

FIELD NOTE 03 Tel Aviv · the “My DigiTel” portal

A generic hello

what a city app taught me about the first half‑second

People opened a city app that knew their address, their parking, their kids' classes — and still felt like strangers in it.

I ran mixed‑methods usability research on Tel Aviv's “My DigiTel” resident portal — payments, parking, transport, city services, classes — across mobile and desktop, with moderated interviews and unmoderated Lookback sessions segmented by age and device. The brief was about findability. What kept surfacing was something earlier than that: expectation.

Residents assumed an app the city built for them would feel personal — surface their neighborhood, their open requests, the things they actually use. Instead they met a generic municipal index, and every external redirect into some other system chipped away at the trust. Several just abandoned the task — not because they couldn't find the button, but because the first glance quietly said “this isn't really for you.”

That first glance is the whole game — so I test it directly. Show someone a screen for five seconds, take it away, and ask who it was for. You're not testing usability; you're testing the gut reaction that decides whether they lean in or leave. Try it on a generic city portal:

What people keep from those five seconds is the loudest thing, not the most important one. For My DigiTel the loudest thing was “generic city website,” and that impression set the ceiling on everything after it. The fix was never more features — it was making the very first screen say this one knows you.

People decide who a product is for in about the time this test gives them.

There's a number under all this, and it's faintly insulting: in a 2006 study, people formed a stable judgment of a page's visual appeal in about 50 milliseconds (Lindgaard and colleagues). Fifty. Steve Krug built a whole, kinder book on the everyday version — the title is the thesis: Don't Make Me Think.

further reading — Lindgaard et al., “You have 50 milliseconds…” (2006) · NN/g, first‑impression testing.

FIELD NOTE 04 Boston · GlassesUSA's first store

Two screens that never spoke

a journey map of one store that was secretly two

A customer held up a pair of frames, squinted into the mirror, and admitted she had no idea whether they suited her. With her prescription, she literally couldn't see them.

GlassesUSA had sold eyewear online for years and was opening its first physical store. They brought me in to map the experience before the doors did. I ran in‑depth interviews with insurance‑holding customers and built a full journey map — pre‑visit, eye exam, choosing frames, checkout, and the days after — coding all of it in NVivo.

The map made one thing impossible to unsee: this wasn't one store, it was two bolted together. The eye exam was medical — clinical, careful, a little anxious. Choosing frames was emotional — playful, identity, “is this me?” The handoff between them was a cliff, and a pen‑and‑paper insurance form sat right in the middle of it, leaking trust by the minute.

And the cruelest detail: strong‑prescription customers couldn't evaluate frames without their lenses in. We were asking people to fall for something they couldn't actually see.

The bug wasn't in any one screen. It was in the seam between two of them.

It's textbook Don Norman: when the user's mental model and the system's drift apart, you get a gulf — and the gulf is where people quietly give up. A journey map is just the tool that makes that gulf visible before your customers find it for you.

further reading — Don Norman, The Design of Everyday Things · NN/g, “Journey Mapping 101”.

FIELD NOTE 05 Arduino Studio · seed stage

First researcher in the room

making the case for discovery while learning embedded systems at night

I've been the first researcher a team ever had more times than I can count.

Arduino Studio was a seed‑stage startup building a “no‑code” platform for hardware. Everyone was lovely, and everyone wanted to start building tomorrow. I made the unpopular case for discovery first — then spent my evenings teaching myself embedded systems just to follow the engineers' sentences. (I will not get those evenings back. Worth it.)

So I ran the unglamorous trio: user interviews, a competitive analysis, and cognitive walkthroughs. The finding that reframed the product was almost embarrassing in how clean it was — the “no‑code” tool still demanded real code at exactly the moments users felt least capable, and the cognitive load was crushing.

Underneath it sat one mismatch: people wanted to describe behavior — “when this happens, do that” — while the tool kept forcing them to think like developers. That single sentence became the product: a behavior‑based interaction model of visual trigger‑condition‑action flows, with templates covering about 80% of use cases and plain language where there'd been jargon.

You earn the right to do research by showing — fast — that it moves the product.

Building a practice where none exists is half method, half stubbornness — mostly I just refuse to let a team quietly build the wrong thing. Two books basically wrote my job description, and I hand them to anyone starting out: Erika Hall's Just Enough Research — rigor without the ceremony — and Teresa Torres's Continuous Discovery Habits, for keeping it alive once you've earned the seat. The mismatch I found, by the way, was textbook Norman: two mental models that had quietly drifted apart.

see it live — arduinostudio.com ↗

further reading — Erika Hall, Just Enough Research · Teresa Torres, Continuous Discovery Habits (2021).