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:
- User inserts an amount equal to or greater than the price of the product
- User selects a product
- 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 something | Apply a glow filter around a button or field that’s in focus | |
| To tell the user that his input has been received | Provide audible feedback, change the appearance or label of a button, or display a progress bar | |
| To confirm that the system has completed some task | Provide 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.
