SETHJACOBS

Part 2 of 2 · August 20, 2026

Decision-Making in UX: The Two-System Concept, Part 2

Part one made the case for designing toward recognition. This one is about how you find the places you aren't, by putting a clock on the goal and reading where the time goes.

6 min readCognitive loadResearch methodsEnterprise UX

In Part 1 we looked at Daniel Kahneman’s two-system decision-making concept at a high level, and put some color around System 1. If you missed it, that one has the full context. We will do a quick recap here and then get into the harder half: finding System 2 in your own product, and getting rid of as much of it as you can.

The two-system concept describes two decision-making processes we all run every day. System 1 happens automatically and without effort, and it develops through repetition. System 2 is slower and more effortful, and it taxes you one way or another. Steering a car down a highway is System 1. Through repetition you hard-coded it. Doing complex maths in your head is System 2. Slow, taxing, deliberate, unless you happen to be very good at that sort of thing.

SYSTEM 1Automatic. Fast. No sense of voluntary control.Steering a car on a familiar roadReading a word you knowKnowing a button is a buttonRecognition. This is where intuition lives,and where you want the experience to sit.SYSTEM 2Slow. Effortful. Where reasoning happens.Multiplying 17 × 24 in your headA form that invents its own rulesHunting for a control that movedEffort. Sometimes unavoidable. Usually adesign decision nobody made on purpose.
Two processes, running all day, mostly without you noticing which one is doing the work.

Applying this to how we design software gets you fantastic results. You can see where intuition is doing the heavy lifting, and you can see where you've built a pitfall. Most pitfalls live in System 2.

So how do you find System 2 in your own product?

System 1 is the one we want. We want people to recognize the experience automatically so their cognitive load stays low and things stay easy. Which begs the question: how do you get there? How do you look at a design, proposed or already shipped, and say with any confidence how easy or how complex it is?

What we found is that testing an experience for task efficiency does a good job of sorting interactions into System 1 or System 2. Measuring speed tells you how quickly someone knows what to do next. Then, as you read the data, the inefficiencies surface on their own: goal completion times start climbing in specific places.

Tools and methods to measure task efficiency

How you measure will depend on your process and what your stack lets you get away with. That said, here is where to start.

Goal structure

Looked at from a bird’s-eye view, a user goal can be measured two different ways.

  • Full measurement. The time it takes someone to complete the goal, beginning to end.
  • Segmented measurement. The goal broken into pieces at each interaction point, the moment they pick a country in a form, for example.

The aim is to shrink the full number. But you get there by working the segments individually, which means you have to measure those too.

FULL MEASUREMENTStart → goal complete4:12Tells you there is a problem. Does not tell you where it is.SEGMENTED MEASUREMENTFind entry3:00Fill details3:30Pick country5:00Review2:10Submit1:32Now you know. One control is eating a third of the goal, and it's a dropdown with 240 entries in it.You can't fix 4:12. You can fix a country picker.
The whole-goal number tells you something is wrong. The segments tell you what to go fix.

Manual measurement

Shadow the user and hold a stopwatch. This is the hardest method, because segments arrive faster than you can write them down. Record the session if you can, so you can watch it back at a comfortable pace.

Tool analysis

Plenty of tools let you set goals inside your application and track metrics against them. Google’s, Optimizely, and quite a few others. They give you the raw numbers, but they won't show you why any of it is happening.

Find one that records sessions. That's the difference between knowing the what and knowing the why. We have used Inspectlet and Hotjar and both work well.

A custom component

If you have the flexibility to build session reporting into the product itself, do it. It can be as simple as a backend service collecting event stream data, baked in globally. Having that at the system level lets you re-render a session in its purest state, which is worth a great deal when you're arguing about what really happened.

Then the work is obvious

Once you've picked a method, the job is clear. Measure at the goal level and the segment level, find the big time sinks, and go make them smaller. Where a task takes longer, something in that interaction is slower and more effortful than it needs to be.

Some of those System 2 moments are unavoidable. Some are unintentional, which is the more interesting category, because nobody decided to put them there. The general goal is to commit as much of the experience to System 1 as you can.

SYSTEM 2Slow segments. Controls that moved.Patterns invented for this screen only.Where the time sinks show up.MEASURETHEN FIXSYSTEM 1Recognized. Repeated. Expected.The same action in the same place.Where you want the experience to live.Not every interaction can make the trip. The goal is to move the ones that can, one segment at a time.
The whole job, in one picture: move what you can across, and be honest about what won't go.
Improvements, no matter how small, add up. Every interaction you optimize makes the thing quicker, more effortless, more intuitive. Recognition is the point.

That's the series. If you skipped the first half, Part 1 covers intuition, priming, and why cognitive easing matters more than any trend you're being asked to chase.