Designing for behavior change has no 🍪 cutters
Just in case you are not yet aware, over the last two or three decades the ways we (I mean everyone outside psychology) understand human behavior has shifted considerably.
In the past when designing, we used to assume that the user would always choose whatever is most convenient for him. However we are not Homo economicus if you want to get yourself up to speed with this concept, you should check this article “Taking Behavioural Economics Into Product Design”. Years of academic research produced long lists of heuristics and biases about how humans behave when making decisions, a great asset to use in our projects.
- There are no canned solutions to change user behavior
- Applying the wrong technique will hurt your project
- Translating an example to your context, it might not be so easy
- Read the original papers. Understand why things happen
- Even when your bases are covered, you still need to prototype and iterate the mechanics
There are no canned solutions to change user behavior
There are loads of blog posts with titles like “Use this four cognitive biases to increase retention” or “How to use social proof to boost your sales.” In those articles, you can find examples, methods and simple definitions of such phenomena, things you might want to transplant to your projects. There is value on those articles -you might even find me tweeting and sharing some, but I want you to be aware of something that it’s not always clear; unfortunately, behavioral change has no cookie cutters.
The bottom line is that there isn’t a magic method, no silver bullet bias that will always work to change user behavior. Let me explain you why:
Everything seems like a nail
Some years ago, when gamification was all the rush, a client came to me looking to solve a problem with his product prototype. He had conducted the first fields tests, he knew he had a solid product, yet users stopped using it after a few days. It lacked retention. He is an entrepreneur; he’s not lazy nor slow, so he had made his homework before hand. “I want to gamify it” — he told me — “Create me a set of achievements, add points and leaderboards to the platform and let’s give prizes to whoever helps the most.”
He wanted to add the standard “Points, Badges, and Leaderboards” scheme over a collaboration platform where users help each other in a selfless manner. That will not work. Those mechanics are meant to drive retention through competition. But, who is the most selfless? It’s quite an unusual contest. In the end we boosted retention by redesigning the feedback users were getting and the communication methods between them.
This guy only understood the result; he wanted to apply a solution that would solve the retention problem without understanding where the foundations of the technique lays. Gamification as a concept, has had an enormous backlash for trying to use a one-fit formula to all kinds of contexts. So, if you want to apply behavioral techniques to your project understand the principles of that phenomena is supposed to work.
Biases are context dependent
We are on a new field. Using this sort of techniques can give you an edge, but that’s not without peril. Sometimes, even when we have the theory covered and are completely sure that we are using “the right tool for the job,” we are unable to replicate in a new in our context. There are lots of scientific studies that try to do that and fail to prove any effect. That’s not necessarily a bad thing! That what science is all about, but when it comes to your project, you would love that not to happen.
Unfortunately, there is not much you can do to mitigate this but to prototype fast and cheap. Try these mechanics as much as you can while developing the prototype and be ready to adjust them. When diving into uncharted seas, you must be aware that is a high stakes game.
Are you looking for a passionate team that can help you envision, design, and build amazing products? Drop us a line.
Ingenious is a distributed product design and software development agency with offices in Montevideo, Uruguay, and Denver, Colorado, and a team distributed in more than five countries. We create products and build software that people want to use for challenging industry segments like healthcare, education, and government.