Before we write any code, we ask one question: what is this person trying to do, and what's in their way?
Not "what features should we build." Not "what does the competitor have." The question is always about the person — and what's happening in their head when they reach for our tool.
Most software adds. Good software removes.
Every button, dropdown, and modal is a decision. Every decision costs attention, time, and confidence. Psychologists call this cognitive load — the invisible tax users pay every time they interact with your product.
Try it yourself:
Cognitive load test
Glance at each panel for 2 seconds. How many dots are in each?
Both panels have 21 dots. Panel B felt easier.
Panel A uses different sizes and colors — your brain processes each dot individually. Panel B uses identical dots — your brain groups them instantly. Same information. Wildly different cognitive cost.
This is what we mean by designing for how people think. The data didn't change. The presentation did.
Hick's Law: why more options slow users down
In 1952, psychologists Hick and Hyman measured something intuitive: decision time increases logarithmically with the number of choices.
This isn't a metaphor. It's measurable:
Hick's Law in action
Hover over each panel. Notice how your eyes behave differently.
Every option you add costs time — and worse, confidence. Users who hesitate start to doubt. Users who doubt leave.
What cognition-driven design looks like in practice
The same action — saving a document — designed two ways:
9 options. The user wanted to save. Now they're reading labels.
1 action, 1 escape hatch. The user saves and moves on.
The first design showcases the product. The second serves the person.
The questions we ask before building anything
- What is the user trying to do right now? Not eventually. Right now.
- What's the minimum they need to see? Everything else is noise.
- Where will they look first? Put the answer there.
- What would make them hesitate? Remove it.
We don't add features because we can. We add them when they reduce the distance between intent and outcome. Sometimes that means building less. Sometimes it means building something invisible — like NoxKey's Touch ID flow that completes in under 2 seconds, or Blindspot's single-click bug capture that requires zero context switching.
Software should adapt to people — not the other way around
That's not a tagline. It's an engineering constraint we apply to every component, every flow, every interaction. Every product we ship starts with a question about people, not about technology.
Technology is how we answer the question. It's never the question itself.