Posted on: June 11, 2015
Violating User Expectations
“Mom, I’m going to have to call you back. I need to call 911.” I announced suddenly in the middle of my phone call. In retrospect, this maybe wasn’t the best way to inform my mother that I had just seen a motorcycle accident, but after sorting out that I wasn’t about to die, I quickly punched in the three digits on my phone for the first time in my life.
Even though I’d never called this number before, I was feeling pretty prepared. In addition to my childhood training, I’d even seen a ton of movies where protagonists dialled 911. They were going to ask me what my emergency was and I was ready with a good concise response.
The call connected and a lady on the other end asked, “Fire, Police, or Ambulance?”
I was completely caught off guard. “I’ve just seen a…” I began, before realizing that I hadn’t been asked the question I was expecting. My next response was a little slow, “Ambulance,” I began, “and police”, I added quickly, as the motorcyclist was sprawled in the middle of the intersection. I finished with more of a question than anything else, “Not fire?” It didn’t look like the motorcycle was about to combust, but what did I know about sudden motorcycle combustion?
Fortunately, the conversation continued more smoothly after that. I was asked a few more questions and instructed about what to do until emergency services arrived.
For something that I felt really prepared for, it seemed like quite the rocky start. This event isn’t singular to 911 calls or me though, the same experience I had, is experienced by your users every time you violate one of their expectations.
What are User Expectations and Where do They Come From?
A user expectation is anything that a user thinks is going to happen when engaging in an experience. For me, it was expecting to hear “911, what’s your emergency” after someone answered the phone. For others, it could be expecting a document to be saved after pressing an icon with a floppy disk on it.
These expectations are formed from prior experiences users have had in the real world, with other systems, and within your experience. People expect things that look the same to act the same as they did in prior experiences.
The Real World
The ‘shopping cart’ in an online store, serves the same function as a shopping cart in a traditional store. Users have expectations that it will function the same way a ‘real world’ shopping cart would.
If users were to put items in their carts and then by the time they get to checkout find that another customer has bought the items, their expectations would be violated (unless the user lived in a lawless society where shopping cart theft was common).
One very recognisable icon in computer systems is the ‘X’ icon in the top of the window. Users have encountered this icon many times before in other systems and have come to expect that this icon will close the window it is attached to.
If your system were to use this icon to mean something else, like add an ‘X’ symbol to the document, users expectations would be violated.
You don’t just have to remain consistent with other experiences users have had before encountering your design, you also have to remain consistent within your own design.
If you designed a video game where users would press ‘Y’ on their controllers to delete content when in a particular menu, users would expect ‘Y’ to delete in all menus.
(These three areas where expectations are formed are also some design principles)
It is best to try to avoid violating user expectations when you are trying to improve usability. User expectations provide a quick way to speed up your system’s learnability by allowing users to use their prior knowledge to quickly adjust to a new experience. It is easier to use them to your advantage, than to fight them.
So, why did 911 choose to violate my expectations? If we look at the old expected question “what’s your emergency?” vs. the new question “fire, police, or ambulance?” we can see a subtle shift towards efficiency. Rather than hearing a detailed story and deducing the services needed from that, it switches to getting the big picture to send the needed services as quickly as possible and then getting the details.
This switch though comes at a cost. The first time users encounter this unexpected question, their response time slows down, thus reducing their efficiency. Is this slowdown significant enough to counteract any time gained by asking a more efficient question? As I don’t have any data to look at, I would be just speculating at this point, but even if the cost and the gain were the same, 911 would ultimately gain by making this switch.
Why? Because users adapt.
When the first word processors came out, users would just close the program expecting their files to save automatically. These users were used to a different system: the typewriter. When using a typewriter, users never had to save their work, so they expected the new word processers to behave the same way the typewriters had. Eventually, with the help of some warning messages, users got used to saving their work before closing and a new expectation was formed. Then, more recently, came autosave. Users are now shifting away from expecting to manually save, to again expecting the system to save for them.
User expectations changed twice in this time period. Now, this is certainly not to advocate that violating user expectations doesn’t matter (many hours of work were lost in the first few years of the word processer) but rather to show that if you are forced to violate user expectations, users are capable of adapting. Users will be more likely to do this when there is no alternative. This makes 911 a perfect system to adapt to. However, if you decide to violate user expectations in your calendar app you will find that users will be more likely to abandon your app then learn to adapt to it.
So, run some user tests, check for expectations, and respect them.
In the end I’m pretty sure the man was okay; we were about two blocks from the nearest hospital.
Michelle believes that good design is like silence. You never seem to notice when it’s there, but its absence is always missed. With a thorough understanding of end users, Michelle Brown creates these silent designs that support users through every step of their journey. She delights in crafting pleasurable experiences through a variety of research and design methods and is always pleased to use her knowledge to take designs to the next level. Her experience spans wireframe creation, usability testing, persona development, design feedback, and card sorting. As an Experience Architect, she has proven that she can meet aggressive schedule objectives and deliver actionable results. Michelle has a MSc. in Computer Science with a specialization in Human Computer Interaction and is an Experience Architect at Akendi, a firm dedicated to creating intentional experiences through end-to-end experience design.
Sign up for our UX Blog
Don't miss an article! We'll notify you of each new post.