Designing experiences that your users will love.
User behavior
By Stine Dorner, Head of Design
You build fast. But are you building for real people?
When digital solutions are not used as intended, the challenge is rarely communication – it is almost always behavioral. And that's actually good news. Because that means there is something very concrete to do about it.
This article is written for you who work with digital solutions and recognize the frustration of building something good that doesn't work in practice anyway. It is rarely the solution itself that fails. It is the language of what actually happens and what can be concretely done about it.
The pattern we see over and over again
We live in an age where AI makes it possible to build faster than ever. More, with fewer resources, in less time. This does not just apply to products and platforms –, it also applies to the way we implement AI solutions in organisations.
But that doesn't change the basics: people still make decisions based on habits, friction and what feels easiest at that moment. The most important discipline going forward is therefore not speed, but the ability to build for real people.
Research indicates that approximately 7 out of 10 digital initiatives do not deliver the business value expected.¹ Poor project management, unclear requirements and technical challenges are part of the explanation, but one of the most overlooked reasons is another: the solution is there, but people don't adopt it, rarely because they are reluctant, but because we systematically build to intentions and underestimate everything else that affects behavior.
In the work we do with companies across industries, there are four scenarios we encounter with striking regularity.
Scenario 1: People find ways around it.
Approval is still done by email, although there is a workflow for it. It's just easier. And then everyone does, but there is no data in the system – and thus no need to use it.
Scenario 2: Adoption starts well, but people drop out.
The first two weeks are going really well. People try it, they think it's fine. And then everyday life takes over. And then the old workflow is slowly back.
Scenario 3: Only the most committed are involved.
It is always the same three people who use the solution to the fullest. The rest are waiting to see if it lasts.
Scenario 4: The problem is visible – no one reports it.
No one complains. The system looks fine. But the numbers show that no one really logs in. And no one says that because no one wants to be the one to complain about something that cost so much money.
Common to all the scenarios is that the challenge is rarely technical in nature, but rather behavioral.
What it costs to ignore it
We once met a company that wanted to make everyday life easier for their customer consultants. The goal was simple: shorter calls, better quality, less administrative hassle. The solution was ambitious, an AI system that could listen in on the conversations, guide the consultants along the way and automatically write the statutory minutes afterwards.
When the system was presented, the consultants were actually motivated. They wanted to do their job better. And then we followed them through their working day to see what happened.
The AI system was not integrated into the consultants' other systems. They had to remember to turn it on themselves, which they quickly forgot as the day progressed. The guides that the system suggested during the interviews were not followed because it required the consultants to multitask between listening to the customer and reading the screen at the same time. And the reward of getting rid of the minutes also failed to materialize. The system could well extract points from a complex conversation, but never wrote the basic information: date, consultant's name, customer's name. They still had to do that themselves.
The management had good intentions. Users were motivated. And yet it didn't work.
The reason was methodical: no one had made field observations before the system was designed. The consultants' tasks were known on paper, but not the actual work rhythm, the cognitive requirements in the middle of a conversation, or the micro moments when an extra click is one too many. Contextual inquiry is not a nice-to-have in that phase. This is the basis on which the rest is based.
And the price for that is not abstract. It is an expensive system that is not used as intended. These are consultants who still spend time on manual documentation. It's an organization that lost confidence in AI as a tool – not because the technology was wrong, but because no one had asked what actually happened before building. And that's the probability that version 2 starts with the same assumptions because you were looking for the wrong problem.
What is most often overlooked – even when you know the models
The Fogg model³ says that behavior only occurs when three things are present at the same time: motivation, ability, and a trigger. Habit loop⁴ describes what it takes for the behavior to last: a signal sets a routine in motion, and a reward makes it worth repeating. Together, these are two of the most used frameworks in behavioral design. Yet we see them failing in exactly the same place over and over again: namely the trigger element.
It is not accidental. Trigger is the only element that requires insight into what the user is already doing – not in what they are about to do. When are they already doing something adjacent? What happens in those seconds just before the desired action should occur? You cannot answer those questions by reading a requirements specification. You can only answer them by observing people in their actual working day.
Habit loop fails for the same reason. Signal and routine can be designed within the system and the reward can be made visible and fast. But if the trigger assumes that the user actively remembers to change context to the new system, in an everyday life that already requires its own, the behavior does not last when the pressure increases.
It is not a human weakness to design around. Approximately 45% of our daily actions are initiated automatically, by habits and context rather than conscious choices.² As designers, it is not a limitation that we have to compensate for –, it is the mechanism that we have to design with.
An example from reality:
In collaboration with SENS Innovation, we worked with COPD patients during and after hospitalization. The group knew they should move more, but they didn't. It was not an information problem and it was not a motivation problem in the traditional sense. It was a trigger problem.
The Fogg model states that behavior only occurs when motivation, ability, and trigger are present at the same time. In this case, two of three elements were already in place: patients wanted to recover faster, and the very act of getting up and walking did not require new skills. What was missing was the third factor: something that set the movement in motion at the right time and in the right context.
The classic answer would have been to communicate more, a reminder, a poster in the hallway, a talk with a nurse. But that does not change the structure of everyday life. The bed is still near. The hallway is still long and boring. There is nothing that makes the next step the most natural next step.
Instead, we asked the question differently: what would it take to make the movement visible, meaningful and rewarding the moment it was to happen? The answer came from the behavioral design and habit loop logic, signal, routine, reward, translated into a concrete user experience.
The result was an app that translates the patient's movement into progress on a virtual route through Copenhagen, Aarhus or another Danish city via data from an intelligent patch. The reward is not abstract or deferred. It is visible and instantaneous: the route moves and the progress is confirmed in real time.
This is exactly what distinguishes this solution from a reminder or an information campaign. The trigger is not external and arbitrary, it is rooted in the movement itself. The reward is not a theoretical gain in the future, it occurs the moment the action happens. And the actual everyday life at the hospital is not designed around it, but taken as a starting point.
The result was 51 minutes more movement per day on average in the patients.
Five questions you can ask in your next project
You don't have to start with new features or large relaunches. You can start with the questions you ask yourself. They draw on the same knowledge base as field observation, task analysis and usability testing, and they are relevant much earlier in a project process than they are typically asked.
1. What is the one concrete action you really want the user to do?
Not “users must use the system more”, but the “project manager must approve the report within 24 hours of submitting it”. It is task analysis in its simplest form: the more precise you are on the action itself, the easier it will be to build something that supports it.
2. Suppose the motivation is there and look for the friction.
In most organizations, people actually want to do the right thing. Ask yourself the question: what makes the action difficult? Where does the solution require too many clicks? Where does it break with existing workflows? The greatest effect almost always lies in removing friction, not in explaining the solution better.
3. When does it actually make sense?
It's a matter of task flow: what does the user do right before and right after? Behavior that occurs naturally as a next step in something the user is already doing is almost repeating itself. Behavior that requires a conscious change of context rarely does so.
4. Is the reward visible and fast?
Behavior is not repeated because it has been thoroughly explained. It is repeated when you can see or feel that it is working. It doesn't have to be more advanced than a status field that switches from pending to approved, a progress bar that moves, or a message that confirms something has been received.
5. Observe what people do – not what they say.
That's the core of any good usability session: users often say “I could easily figure that out”, and don't do it in practice anyway. Observe first: where do people stop, where do they find ways around them, when do they fall away? And then test small. One thing at a time.
Back to the four scenarios – now with a language for them
The four patterns we described at the beginning are not just symptom descriptions. With the conceptual apparatus we now have in place, we can make a more accurate diagnosis on each of them.
If people find their own way around it, it's rarely reluctance. The action is simply too difficult or too foreign in the context in which it is to arise. Something is missing that lowers the threshold. It is a friction and ability problem.
If the adoption starts well but falls away, nothing keeps the behavior going when everyday life takes over. No trigger that reminds people of it at the right time. No reward that makes you want to do it again. It is a signal and reward problem.
If the solution is used, but not as intended, there is a mismatch between the flow built into the system and the flow users are actually in. The trigger hits the wrong time or the wrong context. It is a timing and flow problem.
And if you don't know what's going wrong, that's actually the most honest starting point of them all. Behavior is invisible if you don't actively look for it. It is not a sign of error, but that the language is still missing. The five questions above are a place to begin.
¹ McKinsey & Company (2018): Unlocking success in digital transformations
² Wood, W. & Neal, DT. (2007): A new look at habits and the habit-goal interface, Psychological Review, 114(4)
³ Fogg, BJ. (2009): A behavior model for persuasive design, Proceedings of the 4th International Conference on Persuasive Technology
⁴ Duhigg, C. (2012): The Power of Habit: Why We Do What We Do in Life and Business, Random House