At 4Point we have a refrigerator. It's pretty fancy, with double doors, an icemaker, and a water filtration system. It beeps at you if you leave it open too long. Inside, you'll find all kinds of beverages: fruit juices, milk, mineral water (sparkling or flat), V8, various types of soda, and of course beer (for Fridays after 4:30PM only, sadly). If you're thirsty, chances are that you'll find something in there that you like, for free.

In the eBay Town Hall (where I recently attended 360|Flex), right by the washrooms there is a Coke machine. It's identical in every way to any vending machine you'd run into in the wild. It's big. It's red. It just sits there, humming expectantly. There's only one unusual thing about it: it is free. Free as in, "Don't insert coins and select your beverage."

When I Drink, I Get Emotional

After obtaining my first Coke from this blessed machine, I was immediately struck by how good it felt to be able to just walk right up, push a button and hear the chilled can drop into the slot. Even though we get Coke (and many other drinks) for free in the magical fridge at work, the whole experience using the vending machine was completely different. I asked my colleague Brad (who was also at the conference) what his take on this was and he laughed and agreed: it just feels better to get free drinks from a vending machine than from a fridge. It isn't the fact of getting a Coke for free that is important emotionally, it's that you didn't really expect to get it for free.

As is my wont, I started thinking about how this emotion, the "Free Coke Effect" as I call it, applies to user experience design.

Great Expectations

Anyone above the age of 5 probably has some sort of expectations coming into a new user experience. By that age, we've already pretty much seen it all. For instance, when faced with a login dialog, users already know how it will behave and what is expected of them. The contract between them and the application is clear: "You provide a valid username and password and I will provide access in a timely manner (or warn you if your credentials are wrong)."

Taking the case of your average Coke or other vending machine, we have the following contract:

  1. User inserts an amount equal to or greater than the price of the product
  2. User selects a product
  3. Machine outputs selected product and (optionally) the correct change

As long as both sides hold up their ends of the contract, the result is a satisfied user. If, however, the machine has run out of the desired beverage or—even worse—accepts the money and provides no beverage, then the contract is either only partially filled or completely broken. Everyone knows the frustration of having thrown money down the black hole of a broken vending that has failed to live up to its side of the bargain.

The fact that vending machines have been known to fail means that users often come into this particular contract a little wary of disappointment. Unfortunately, with all of the badly designed and unreliable software that's out there, this wariness also holds for many software-based user interactions.

Don't Miss Your Cue

We go through our everyday lives guided by cues. Many of the things we do most often don't require us to think—they aren't cognitive, but are rather emotional or instinctive. When the brake lights on the car in front of us go on, we slow down without having to think about it. Through subtle cues in their body language, we instantly know our spouse or close relatives' moods and act accordingly—no thinking required. Pretty much anything we do that is familiar or repetitive is driven in large part by these ingrained, subconscious responses.

When designing a user experience, we often work on building in cues (or inherited familiarity), sometimes even without realizing that's what we're doing. The most important involve telling a user to act, or reacting to a user's actions.


To tell a user he can/should do somethingright arrowApply a glow filter around a button or field that's in focus
To tell the user that his input has been receivedright arrowProvide audible feedback, change the appearance or label of a button, or display a progress bar
To confirm that the system has completed some taskright arrowProvide a timed "toast" pop up or audible feedback


Each and every cue is an implied contract between the user and the software. An important part of how users perceive their overall experience is how well all of these individual contracts are fulfilled by the system. I can tell my user, even with the subtlest of signals, that if he does A, I will reciprocate with B. If I hold up my end of the bargain (and make it clear to the user that I have), then we move on to the next interaction. If, however, I fail to hold up my part of the contract or fail to let him know there's a problem, then the user might be confused, disappointed, or frustrated.

In a recent RIA project, we used an animated "loading circle" liberally throughout the client-side application to indicate that it was waiting for a server-side call to complete. Due to some instability in the early user acceptance builds, this circle, though benign, became a harbinger of negativity. If a server-side error occurred and wasn't handled properly by the client, testers would be stuck watching a loading circle that would never, ever go away. The testers even playfully gave it a name ("Sully"). This was definitely not a good sign.

In this unfortunate case, the cue that was meant to communicate to the user that the request was being handled instead became a cue that the request might fail catastrophically. When "Just a moment" becomes "Prepare to be disappointed," you are in deep, deep trouble.

Software as Minefield

For most interactions, software users have likely been through both good and bad experiences and outcomes in the past. Therefore, like vending machine soft drink imbibers, that emotional baggage—their expectations and misgivings—color the user experience. It's up to us as designers and developers to meet or surpass those expectations, i.e., to fulfill every implied contract between the software and the user.

Furthermore, when entering into a new custom business software development project, the tool you are developing is very often meant to replace at least one existing process or piece of software. This means that your user base already comes loaded with prejudices, both good and bad. Users know better than anyone (including the original developers) which cues in the old system led to disappointment and which didn't.

I must make it clear that I am not talking about conforming your UI design to the old design. I, as much as anyone, despise the idea of being shackled to someone else's legacy. The important point is to identify the hot spots in the old design to avoid stepping on a live mine. You can't just stroll along pretending that they don't exist.

Boxing With Ghosts

The first key to surviving a minefield is to know that it's there. You must make yourself aware of users' pre-programmed emotional responses—the contracts previously filled or broken that you are inheriting. Ask your users about the existing process/software: "What contracts were always fulfilled and what contracts were sometimes broken?" By maintaining or improving on the first and eliminating the second, you will win the experience battle between your new system and the old one. I call this "boxing with ghosts" because sometimes your software isn't only being judged by explicit, contractual requirements, but also by the shadowy, unstated expectations left behind by its predecessors.

You will never win the emotional struggle between an old and a new system if you don't first nail down what made up the old system. It can be death to the user acceptance of your software if you fail to do this because even well-conceived, functionally complete software starts with two strikes against it if it emotionally disappoints its users. The key to avoiding that danger is to identify and target the emotionally risky parts of the old user experience.

It's not all bad news, though, because many of the imperfections in your new design will be well nigh invisible if, on top of meeting the functional requirements, you are consistently fulfilling the contracts that the old system used to break.

The "Free Coke Effect"

Emotion may well be the key to creating engaging user experiences but that fact is no help if you can't identify what actually triggers emotion. Why is it so much more pleasant getting free Coke from a vending machine than from a fridge? In short: expectation is key.

The strong emotional response that I got from the Coke machine arose from an expectation (good or bad) built up over time. Such expectations cannot be broken without some emotion being triggered. In this case, the Coke machine surpassed (by far) its usual half of the contract, eliciting a strong positive emotion. Had I put money in the machine and received nothing in return, an equally strong negative emotion would have been triggered instead.

It isn't enough for software to be purely functional anymore. These days, software rightly has to compete against every other user experience that's out there in the wild. Therefore, if you are looking to add emotional impact to your software, it isn't such a bad idea to take a cue from a Coke vending machine: it isn't that you get your Coke for free that matters, it's all about how you get the free Coke.

I don't know about you, but I'd take a free Coke machine over a fridge any day of the week.


I think it’s just the marketing strategy. We need to address the situation from where you are getting the free drink. In an open mall the free thing will work. For employees, the DEAL will give more EMOTIONAL feeling than over FREE, I guess…

Thanks for the nice artickle.

This comes under the general heading of Lagniappe ("Lan-yap") which is a word few outside of Louisiana may have heard of.

It is basically a 'little bit more', a gratuity, exceding the users expectations, under promise and over deliver, unlike many sites which work to do the opposite!

As designers, we should all work to give that little bit extra in every way possible.

Hi Drew,

I totally agree. You know the mints they give at certain restaurants after a meal? It's a pleasant little token, the cost of which we know intellectually is hidden in the price of the meal. I think that the whole dining experience would be very different if you got home, looked at your receipt and discovered that they had charged you 5 cents a piece for the mint, even if the meal itself had been 5 cents cheaper.

If the restaurant gives you a mint for free, it's a small gesture that feels good. Who knows, you might even leave a bigger tip. If the restaurant instead dares to charge you 5 cents for the same mint, it might somehow feel like a slap in the face.

I think that as developers/designers, it's best if we keep all of our mints free but charge the full price for the meal (plus parking) ;)

couldn't agree more. to take the coke metaphor a step further:

a ny agency i worked for in the 90s had a coke machine that offered cans for 25 cents.

overheard the CEO of the agency talking about it one time. I paraphrase, but this was the gyst of what he said:

"We could offer the cokes for free, but after a while people would stop appreciating them because they're free. They'd get used to it and attach no value to it. By charging 25 cents, the cokes might as well be free--and people will always feel like they're getting a deal.

His rather mercenary (not to mention skinner-box-ish) take on user attitude + behavior aside, he was right. The contract a user has with a device that asks for nothing and gives something in return is different than the one that asks the user for very little and gives more back each time.

Hi Haydn,

I agree that in "real life", if something is always free, eventually people develop a sense of entitlement. This follows in software. There are certain interactions that users take for granted (even if we know it sometimes takes a lot of work to pull off). For instance: if I indicate that a specific text field has focus, most users reasonably expect that anything they type will appear in that field. If nothing happens when they type then you've broken the spell and risk confusing or frustrating your users.

There are many other examples of ubiquitous behaviors that users assume are "free", such as tab ordering, a progress bar that completes at 100%, full-text search that returns relevant results quickly (blame Google for that one). Users can get spoiled into thinking these transactions are free and it's left up to us not to disappoint them.

Back to the idea of something that's always free. As I try to convey, the key is expectation. If you expect something to be free, then you will be disappointed with anything less. These are the interactions you absolutely cannot afford to fail at. For interactions that can sometimes be taxing on a user, the prejudicial expectation is negative so you can really hit it out of the park if you do it right. These are the best opportunities to engage your users and purchase some goodwill. It's pretty easy to over-deliver when people assume you will fail to satisfy them.

Thanks for your comments!