Listen to what users do, not what you built

The most reliable signal in your product is not what users say. It is what they do. If you only take one thing from this, watch the behavior, because behavior does not flatter you the way a polite answer does.

I learned this from one user opening one screen the wrong way.

The screen that corrected us

One of our early users, Julien, opened the product and looked at his oldest transactions first. We had built the view to lead with history. He went straight past it looking for what was happening right now.

To us it read like a small bug. But it was telling us something bigger. We had assumed people wanted to study the past. What they actually wanted was the present. The current state of their spend, today, before anything else.

That is the whole trap with your own product in one moment. You design around what you imagine the user wants. Then a real person shows you, without saying a word, that you imagined wrong.

Why what users say is not enough

Ask someone if they like your feature and they will usually be kind. People do not want to hurt your feelings in a call. So they nod, they say it is nice, and you walk away thinking you validated something.

You did not. You collected politeness.

The honest signal sits in what they reach for. Which screen they open first. Where they slow down. What they ignore completely. We saw another version of this in a customer meeting when one person got confused on the business registration step. He did not file a complaint. He just stalled. That stall was the feedback.

So we changed how we treated these moments. One confused user became a reason to fix the design, not just a ticket to close. If a single real person tripped on something, we assumed others would too, quietly, where we could not see them.

We stopped asking users to do our thinking

The other thing watching behavior taught us was that we were asking too much of people up front.

At one point our onboarding asked users to rank a set of options before they had even seen value. I flagged it to the team. As I put it, the important callout was to reduce the number of questions we ask of users. We did not have fifteen options for them to weigh, but we were still asking them to rank three things before they got anywhere. All we really needed to know was what mattered most to them.

The same lesson showed up in a smaller choice. We had a screen where some options were marked “coming soon.” A user is not going to click something that says it is not ready. So putting those in front of people at a decision point just gave them dead ends. If you would not click it, do not make the user stare at it.

Even our error messages became a place to listen. When the product could not match a user’s subscriptions automatically, we did not show a cold system error. We wrote it the way you would actually say it to someone. Something close to, “We weren’t able to find any subscriptions in your bank transactions that we could match right away. Please review these to see if any fit.” That is still listening. It meets the user in the moment they are actually in, which is mild confusion, not failure.

Write the requirement as the user’s job

One habit tied all of this together. When we wrote what to build, we wrote it as the user’s job, not the feature’s spec.

So a requirement did not read, “build a spend graph.” It read, “I want to view my current spend over time so I can catch any trends or changes I need to review.” That sentence tells you what the thing is for. It tells you what success looks like from the user’s side. A feature name tells you none of that.

When you start from the job, you are far less likely to fall in love with a screen the user never asked for. The job keeps you honest.

You can hold a strong opinion about what users want. I do. But the opinion is a hypothesis, and the user’s behavior is the test. When the two disagree, the behavior wins every time.

Watch what people do. Treat one person’s confusion as a signal, not a one off. Ask them less and observe them more. And when you write down what to build, write it as their job, so the product stays pointed at them instead of at your own idea.

What did your last confused user actually do right before they got stuck? In my experience, that moment is worth more than a dozen times someone told you the product was nice.