The User Experience (UX) Of My Microwave's "Add 30-Seconds" Button
Over Christmas break, I needed to thaw-out some Ben & Jerry's Chocolate Fudge Brownie ice cream. And, since waiting a few minutes for it to warm-up on the kitchen counter is entirely unacceptable, I popped it in the microwave for 10-seconds. I did this by hitting the Add 30-Seconds button, waiting 10-seconds, and then hitting the Cancel button. When it comes to microwaves, I only ever use two buttons: "Add 30-seconds" and "Cancel". But, my microwave has loads of additional buttons and advanced settings. As I was standing there with 10-seconds to kill, I started to wonder what kind of user experience (UX) lessons I might learn from the large gap between what the science-oven offers; and, how I actually use it.
UX Lesson: My Brain Loves to "Chunk" Work
If I need to heat something for 5-minutes (such as popcorn), I quickly hit the "Add 30-seconds" button 10-times. This incurs absolutely no friction from an experiential standpoint - I don't even have to move my hand. I just position it over the button, and rapidly and repeatedly tap it. I don't even have to count how many times I hit it because the microwave immediately turns on and the Timer shows me how much time is left. So, I just keep tapping the button until the timer reads something like "4:56" (5-minutes minus the 4-seconds it took me to tap the button 10-times).
If I were to, instead, use the "Time Cook" feature, I'd have to maneuver my eyes and my hand around the microwave keypad, locating several different buttons and tapping them in the right order. This choreographed dance is simple and requires fewer button taps overall; but, it has more steps and requires more cognitive load.
In a multi-step process, my brain loves "chunking" work. That is, my brain prefers to repeat something easy many times before moving onto another chunk rather than repeating a sequence of different steps over and over.
A great example of this is sending out Christmas cards. One approach would be to repeat the entire card-writing sequence 10-times:
- Repeat 10-times:
- Write card to a loved one.
- Put card in envelope and add address.
- Add postage to envelope.
- Add return-address sticker.
The other approach would be to "chunk" each step into its own separate workload, like an assembly line:
- Repeat 10-times: Write card to a loved one.
- Repeat 10-times: Put card in envelope and add address.
- Repeat 10-times: Add postage to envelope.
- Repeat 10-times: Add return-address sticker.
Physically, both algorithms require the same amount of work. But, mentally, the later approach incurs much less cognitive load because there are many fewer context switches. In the first approach, I have to mentally "switch tasks" at each step. That's 40 context switches. In comparison, the second approach only requires a context switch at the start of each "chunk". Then, each subsequent operation within a chunk can, more or less, be performed on auto-pilot. That means just 4 context switches!
ASIDE: I don't actually send out Christmas cards in case any loved ones are reading this and wondering why they didn't get one. This was just a good example of a chunkable workload.
UX Lesson: My Brain Prefers Confidence Over Efficiency
A big part of why I use the "Add 30-Seconds" button is that I know exactly what it does. It is familiar and comfortable and dependable, like an old friend. When I need to heat something for 5-minutes, I know ahead of time that I'm just 10 easy taps away from solving that problem.
Other button combinations, while potentially more "efficient" (the above section not withstanding), leave me feeling less confident. Is "Time Cook", for example, really the button that I want? After I hit "Time Cook", is the next value in seconds? Or minutes? Do I actually need to care about the Power setting? If I tap the wrong button, is there a delete button? Or, do I have to hit Cancel and start over?
The fact that I have any questions at all about how the "more efficient" workflow works means that, on some level, I'm gonna be scared of that workflow. Scared of making a mistake. Scared of feeling like a fool. Scared of wasting my time. So, instead of trying to use the more efficient approach, I use the brute force approach that I can execute with perfect confidence. After all, my brain would rather be "right" than "clever".
UX Lesson: My Brain Prefers Existing Solutions
The "Add 30-Seconds" button is an existing solution. I've developed patterns and practices around this button. I can use it thaw-out ice cream. I can use it to cook hot dogs and chicken nuggets. I'm not sure if microwaves do anything else; but, I'm pretty sure that I could use the "Add 30-Seconds" button to cook other things should the need ever arise.
If I have a problem and I don't know how to solve it, I am eager to find a solution. Which means, I'm open to the opportunity of trying new things. However, if I have a problem and I already know how to solve it, I'm much less eager when it comes to new solutions. Moving from "failure" to "success" feels fun and exciting. Move from "success" to "success" just feels like unnecessary work; even, if the new "success" is a better place to be.
At this point, even if I was able to purchase a microwave that came with "Thaw Ice Cream" and "Cook Hot Dog" buttons, I'm pretty sure I'd still use the "Add 30-Seconds" button. Because, moving to a new solution from an existing solution is, at this point in my life, just unnecessary friction.
A wonderful example of this is trying to teach someone to use the CMD-C and CMD-V key-combinations to Copy/Paste on a Mac. If that user has no existing solution to this problem, they will quickly and enthusiastically learn the keyboard short-cuts. However, if you try to teach this to someone who already uses the Edit Menu to perform "Copy" and "Paste" operations, there's a good chance that they will never fully embrace the keyboard short-cuts. Because, they already have a strategy for success; and, moving to yet another strategy for success is, for them, unnecessary friction despite the clear efficiencies.
Applying This to Web Application Development
Reflecting on these personal observations, I think about how all of this may relate back to web application development. And, how I might use these insights to improve upon my own product design strategies:
Simplicity over efficiency: Software should be as simple as possible, even if that means that is has inefficiencies. Simplicity offers an enhanced feeling of confidence; and, I believe users will happily do anything that requires "work" as long as they feel confident in the outcome.
Gold-plating is counterproductive: "Better" is usually not "better". Meaning, once you have a solution that works for a user ("works" in so much as it gets the job done well enough), attempting to improve upon that solution is likely going to add more friction than it is efficiencies. Because, once a user has a "strategy for success", forcing the user to change that strategy is problematic regardless of the practicality. Time would likely be better spent creating new solutions to existing problems rather than trying to make better versions of existing solutions.
Embrace "work modes": Users don't consume software in a single mode. Different moments call for different focus - different "chunking" mindsets. Rather than trying to make every user interface (UI) cater to every possible need, it would likely be good to create specialized interfaces that address specific "modes" of work. Bulk operations, achieving "inbox zero", processing tasks - these are all "modes" that could benefit from their own "vastly simplified" interfaces.
Obviously, every user is different. So, there are no "one size fits all" rules about what does and doesn't make sense in web application development and user interface (UI) design. But, I do think that KISS (Keep It Simple) generally makes sense; and, dovetails nicely with what I'm talking about here.
Reader Comments
Interesting observations, especially because my OH and me frequently "discuss" whether "time cook" (her) or "repeatedly press +30 seconds" (me) is the better way to approach this 😂
On a more serious note: this is why almost every UI/UX refresh is initially decried by existing users - even if it's objectively a huge improvement...
@Michael,
You can rest assured that we (you and me) are in the correct camp -- the 30-seconds button is the way :P
Good point about UI refreshes. Basically, when you "move someone's cheese" they get angry. Period. You really have to make changes gradually / incrementally to make sure people don't freak out.
You make an interesting point, but I do appreciate finding new shortcuts to make OTHER context switches easier. My case in point is moving my hand from the keyboard to the mouse. I'm typing, but now I need to see a different part of the window, or see something on another window, etc. I can either use a keyboard shortcut (and do, a lot), or I can take one hand away from the keyboard to the mouse, do what I need to do there, and then bring the hand back, re-orient / find home keys, etc.
So many UIs force you to use the mouse, when what I want to do is be typing, then switch to [something] (e.g. "find on page" or "scroll a little") - but without a good way to use the keyboard for it, I end up with hand calisthenics - keyboard-to-mouse-to-keyboard, repeat. It's like I'm doing burpees!
@Prosthetic,
As someone with long-time wrist pain from years of programming, I can definitely relate to wanting to find ways to keep your hands on the keyboard (switching the mouse can feel janky sometimes). I'm also a huge fan of
CMF+Fas a way to move around websites. Which is why it drives me crazy when a site overrides the nativeCMD+Fto divert focus to a search input or something to that effect. Yo! Just let me use the browser, please!