Daniel Kahneman, the Nobel laureate psychologist perhaps best known for his bestselling book, Thinking, Fast and Slow, has shown that people have two distinct selves: the remembering self and the experiencing self.

• The remembering self: slow, rational, conscious. A storyteller who remembers peak experiences and who glosses over the details.
• The experiencing self: fast, intuitive, unconscious. Experiences each moment as periods spanning about 3 seconds and will forget most of these moments entirely.

Kahneman himself writes:

I am my remembering self, and the experiencing self, who does my living, is like a stranger to me.

When building products, you need to know that you’re getting a two-for-one deal for each of your users. You have an experiencing user who’s clicking buttons and filling in forms, and a remembering user who will tell you what actually happened (even if they’ve forgotten the details or rewritten history altogether).

The experiencing user

Your experiencing user is clicking, typing, and swiping through the moment-to-moment minutiae of all your product’s micro-interactions. If you took these moments and arranged them side-by-side, you can visualize the moments as frames in a film strip.

Let’s think about this in the context of a sign up form with a password field, simplified some for the sake of brevity.

To set your password when you sign up, you’ll need to:

• think of a password
• type it in
• and – unless you get immediate feedback that the password worked – click submit.

Each of the moments leading up to the click are pretty uneventful; your overall satisfaction is probably trending pretty close to zero. But as soon as you hit that error your sympathetic nervous system kicks in. You are, at this moment (and really at every non-reflective moment in your life), your experiencing self: fast, intuitive, unconscious. Reactive.

You fix your password and maybe your mood trends up again.

Your self-evaluation of how you feel at each of these moments is what Kahneman refers to as moment utility. This is a direct assessment of your real-time state.

If you were to ask your user about their form-filling experience, you’re likely to ask something like: “How was it?” But they won’t answer you with a time series of their moment utilities at each discrete moment. And they certainly won’t respond with an objective derived statistical aggregate of their collective moment-utilities (what Kahneman calls total utility). If you ever do get a user who answers this way, please email me!

Maybe you meant to get a simple summary of their experience, or the one thing that stood out to them. But if you wanted a play-by-play, the devil is definitely in the details of when and how you ask.

The remembering user

Before we learn what we’re actually asking when we ask the “How was it?” question, let’s look at how the remembering user thinks.

Fully 63% of Americans believe, according to a study conducted in 2011, that “human memory works like a video camera, accurately recording the events we see and hear so that we can review and inspect them later.” All 16 experts polled in the study disagreed.

That film strip of moments we saw earlier? That’s not how memory works. You can’t just replay the tape.

The remembering user is actually much more like a storyteller. The remembering self reflects on past experiences which seem handpicked to tell the experiences that stood out. If you were to illustrate the stories told by the remembering self, they would focus only on the key scenes.

This sounds strikingly similar to one popular way to design products – and plan movies! UX designers often use storyboards, which are a series of illustrations – sketches inside frames – that when woven together tell a story.

Whether you are explicitly designing with storyboards or not, your products do have an inherent narrative arc. They tell a story. Even if all you have is a list of features, there’s a story hidden inside.

Imagine, if you will, an invoicing app, retold as a (pretty barebones) adventure story.

• Sign up with email: you set out for adventure.
• Invite a teammate: you pick your sidekicks.
• Track hours: you prepare for the real fight ahead – invoicing!
• Send an invoice: boss fight! Will you get paid?
• Receive a payment: you live to fight another day.

Your users all have their own unique stories they can retell about their time with your product. And that story is constantly being rewritten.

Who are you even talking to?

When you ask for feedback, which of the two users are you really talking to? The vast majority of the time you’ll be talking to the remembering user.

Consider the Net Promoter Score (NPS) survey. If you’re not familiar with the precise term, you’ve probably received at least one such survey from a product you’ve used in the past.

NPS asks a simple question: how likely are you to recommend this product? You answer on a scale from 0 to 10 – not likely to extremely likely.

If you’re not careful, you might think you’re asking this question to the experiencing user. You might, for example, hope to glean some insight into their recent experiences.

But you won’t get such insights with NPS. The wording of the question itself puts a person into a reflective state. You’re talking to the remembering user, the one who reflects, who glosses over the details. The result? Overall feedback.

If you follow NPS with a why question – why did you answer that way? – you might get more useful data and may even stumble upon a recent event.

But remember again that you’re talking to the remembering user. So when you ask retrospective questions like this you’re likely to hear a peak experience or final experience, thanks to the peak-end rule: people often judge experiences based upon their feelings at the peak and at the end.

That’s the storyteller talking. We find it only natural to equate our experience of a movie with its climax or ending. So too with our other experiences, including when we use products.

We’ll cover peak-end specifically in more detail in a future post since it yields numerous insights into how to ask for feedback and design experiences.

In-app feedback

If you want to get closer to the experiencing user, you should talk to them in context. If you want to know how a marathon runner feels when they’re at mile three of their marathon, the best place to ask them is at mile three of their marathon, not once they’ve finished the race.

Why, then, are you mailing your user a survey long after they used your app? If you want to get some context, talk to them in context.

Imagine our example above where the user had to click in order to get any feedback that their password wouldn’t work. If we had asked them how important receiving that feedback would have been right at the point of possible frustration, we’re much more likely to have an accurate measure of their experience as it happened.

You might still end up talking to the remembering user, but if you talk to your users frequently enough in the context of their experience you might just talk to someone who’s present in the moment with you.

Admittedly, the example above is a bit contrived, particularly since as-you-type feedback is now considered table stakes for a good user experience. Think instead of some part of your app where you’re not quite sure what customers think.

What answers do you want?

When you’re doing customer development and gathering user feedback, your most useful starting point is actually to consider the desired outcome. In particular, what do you want to learn by talking to your users?

If you’re trying to determine with real specificity how your signup flow is perceived on the micro-level, you’ll need to get as close to the experiencing user as you can.

If you want to know about your product on a more macro level, then you should be perfectly happy to talk to the remembering user. But you should still time your questions well: learning about their remembered experience of your sign up flow is still best done right after they signed up, not some arbitrary time later.

People aren’t video cameras and they don’t even have full insight into their own experiences. Humans are messy. Asking about their lives is messy, too.

Opening Pandora’s box

The split between the remembering and experiencing user reveals some other interesting problems, which I’d love to tackle in some future posts:

• How a single bug can ruin an otherwise fantastic user experience
• Why people (including your customers) are particularly bad at predicting what they want
• The difficulty of asking questions that assess things like willingness to pay
• Why you must consider your competitors (because your customers do)

...and quite a lot more.