Crunch Network

How Startups Should Use Behavioral Economics

Next Story

Backed Raises $1.5M To Tackle Credit By Letting Sponsors Vouch For Thin-File Borrowers

Imagine you’re a professor. You have assignments that you release at the start of the semester but they don’t need to be turned in until the end. How should you design your curriculum?

Putting yourself in your students’ shoes, you would likely let each student choose how and when they turn in each assignment. Since students intimately know their unique schedules, they should best be able to decide when to complete the work. Makes sense, but is it correct?

In 2002, psychologists Dan Ariely and Klaus Wertenbroch tested this question.

They split students in the same class into three groups. The first group had freedom to choose their own schedule for turning in assignments. The second group was given a specific schedule: they had to finish each paper by a certain date, spaced out over the course of the term. The third group was given the same assignments, but told they could set their own deadlines for completing them.

What happened?

To answer this, let’s first put ourselves in the viewpoint of the professor. It would be difficult to dictate when students turn in papers, when in reality there is no actual deadline. To create a deadline out of thin air would feel unfair. But if slightly manipulating students will actually help them in the long run, does it make it better?

This dilemma has come up time and again with the numerous companies I’ve worked (big and small including Google, Netflix, Lyft to Expedia, Fidelity, VolunteerMatch, etc)   During almost every engagement, we’re asked:

Behavioral Economic principles sometimes feel manipulative. How can they play a role in user-centered product development and marketing?

To understand this, let’s see what happened with our professor.

The first group with no deadlines generally got very little done and turned in papers late, earning worse grades. The third group who set their own deadlines did considerably better with both timelines and grades.

But the winner? The second group—the students who were handed a schedule from someone else. Instead of endless choices for when to start writing the papers, external deadlines enabled the ability to plan. Instead of burdening students to remember when to start each assignment, the deadlines helped curb procrastination.

The well-meaning professor who doesn’t provide deadlines still ends up influencing his “users” – just not intentionally.

This lesson is the  essence of what behavioral economics research has found time and again. It is the person who designs the environment in which we live in who has the most influence on our decisions as opposed to the person  who is actually making the decision.

It is the person who designs the environment in which we live in who has the most influence on our decisions.

The conflict between behavioral economics and product ethos arises because this notion of  influence through design many times conflicts with a typical product team’s mental model of the user.

The product team’s mental model goes something like: “It is not our role to make decisions for the user.  It’s our role to design a product that empowers the user to do what’s right for them.” This mental model is the heart of all debates around limiting choices, defaults, and other behavioral economics tactics.

This mental model seems strong because it feels good. It feels like we’re on the righteous side of the argument to fight for the user and against manipulative design.

But the problem with this mental model is that it’s impossible. One of the major lessons of the past half century of psychological research is that it’s impossible to design a system in which the user has full agency on their decisions.

By being the one who designs the system (however we choose to do it) we are inherently designing decisions.   Sadly, a typical product team’s high ground stance that neglects this responsibility may actually be making the user worse off  – a little like our idealistic no-deadlines professor did to his students.

But we can agree, the professor example is easy. We know that it’s good for students to get better grades.  A harder dilemma arises when we don’t know what’s best for a given user. Or, when what’s ‘best’ for a user may actually widely vary across different users.

The question becomes: Can we use design to influence a user when we’re not 100% sure what’s best for them?

Imagine a world where we don’t know what is the exact method that would help you prioritize your emails. In this case, it’s tough. Do we as product designers help you prioritize and risk being a little wrong or should we  put the full responsibility on you?

We’d give you all the emails at once, with no priority distinctions, in hopes that you would test different approaches and over time and many attempts, land on the optimal email organizational system.

By being the one who designs the system (however we choose to do it) we are inherently designing decisions.

The Google inbox team has thankfully instituted features, and seems to be continuing to do so,  that help users prioritize their email. Instead of making us contemplate the pros and cons of responding to each email we receive, Google’s product team has tried to design the system in a way that could decrease email stress and increase productivity and confidence.

Even if Google doesn’t’ know the 100% correct method of prioritization for you personally, they are 100% sure that sitting back and doing nothing to help you is not the right answer.

For a second, more extreme example, think back to the start of mobile App stores. How should developers decide the price of their apps? Both Google and Apple didn’t know.

The product team’s mental model would say that every user (in this case, developers), may want to charge something different. It would say that it is not Google or Apple’s role to control the marketplace. As such, neither App store instituted a policy regarding free vs. paid.  Instead, they left it up to each developer to set a price.

So, when one  app developer in one category decided to go  free in order to attract customers, all other developers in that category had  to compete at the free level. One app regresses to free and no one in the group gets upfront revenue.

70% of apps are free on the Play store and the large majority of top apps are free. While this may be compelling to end users, it destroys the app developer’s ability to earn a living wage.

By not designing the system actively up-front, Google and Apple still designed the system. Developers now can’t charge and still expect to attract users. This is not a defined preference for the developers – developers had no choice in their pricing strategy.

By not designing the system actively up-front, Google and Apple still designed the system.

These are two cases where guidance on what to do in the face of uncertainty is vital.  By every measure the engineer, marketer or product designer has more knowledge than the user, even if it’s not perfect knowledge.

They have more time to indulge in  the process of deeply considering what the user can or should do. Users are busy humans, without the depth of knowledge of the specialized product team.

In these cases the product team’s high ground moral stance should be to spend time to narrow on what behavior the user is likely trying to achieve with their  product and then aggressively remove all barriers in the way of achieving it.

When teams spin discussion cycles arguing if they should include a default or not for fear of influencing the user too much, they are forgetting the counterfactual. By not including the default, they are still actively influencing users.

This decision forces the user spend their time and effort figuring out the best choice and thus makes it much harder (maybe impossible) for them to do the behavior they hired the product to do.

As social scientists we believe that there are fundamental reasons to ensure that we actively create the choice architecture in order to be helpful rather than harmful—and that it makes people’s lives better and longer. It’s on us to design the system that does this.

As a product team you get to decide if you’re the professor that sets deadlines, knowing it helps students learn more and achieve higher grades, or if you are the professor that chooses to leave it up to the students to decide how to optimize their schedules.

In both cases we are designing the system on behalf of the students – but in one case it’s not intentional.

Featured Image: Tax Credits/Flickr UNDER A CC BY 2.0 LICENSE