Often times I find myself using a piece of software thinking, “this wasn’t built for me.” Not in the sense that I’m not the target market. In the sense the person who created it is extracting a significant amount more value from the process than me.
I’ll give you an example. Not to pick on Amazon… but they are at the top, so it comes with the territory. (I’m just sure Bezos will cry himself to sleep on a pile of cash tonight.)
Now, money tends to flow through my fingers much like water. So the other night, during a little belt-tightening that’s been going on around these parts, I went to cancel my Amazon product subscriptions.
When you cancel an item you get this confirmation nag. I’m asked to select a reason for the cancellation and then to click a button. It’s an extra step. This is kind of annoying, but I could make an argument for it myself. Require confirmation before destructive action is common and warranted.
My issue is with the list of cancellation reasons I’m to select from. Here it is on two different items. Check it out.
I was in fact subscribed to two different flavors of birdseed, don’t worry about it.
The list is randomized. I was cancelling about 15 items all at once. So every time I had this list pop up, I had to read through from the beginning to find out where my actual reason was.
Now, I know why they do it. Amazon’s business is notoriously data driven. It’s not surprising (and smart in a scientific way) that when collecting their subscription churn data, they want to control for the order of choices given the user. But smart for them and good for their data is sucky UX for me. But this interface isn’t for me.
It’s not quite a dark pattern. Their site is mostly easy to use, particularly considering the dizzying array of features and services that Amazon offers. You can buy bird seed, watch a movie, provide data security for your web startup, or get your furnace fixed… all at Amazon.com. Come on now, gang, let’s focus.
I applaud them for making sense of all that mostly well. But this purchase process vs. the cancellation process is the equivalent of getting the red carpet treatment by sales and the proverbial poo sandwich from retention. It’s all about them at this point.
The first couple that I had to select were annoying, then it got frustrating, and by the last handful of items I was literally just opening it, selecting a random answer, and confirming. When people use interfaces that are designed well in a task-oriented manner, they tend to build momentum. This is because good design is much like programming, in that you should use repeatable patterns. So randomizing a menu that I need to use in a repetitive manner is super obnoxious.
Big caveat: it isn’t even required. You can leave it blank and just hit the confirm button! Argggggggh. I didn’t even discover this until AFTER I’d gone through the process (15 times) and cancelled all my items. I only found out it was optional, because I’m a UX nerd and I went back and played with it while thinking about the premise of this article: interfaces for the benefit of people that aren’t the user.
Maybe I’m dumb. Or maybe along with their obnoxious randomized menu, their affordances for what’s required in their web forms is hot garbage. I’ve been designing systems like this for 10+ years. I was using it wrong, and getting frustrated, and providing them bad data. (And sorta-kinda building a mini grudge along the way.) What chance does the non-technorati stand?
I am not one to complain without offering at least a half-baked solution or two… or three. What is one to do? How could this interface be made more about the customer?
- Add some affordance to make what’s required and what’s not obvious.
- Only do the randomizing between sessions, instead of every time the menu is generated. Let users cancelling multiple items still build that momentum by utilizing a repeating interaction pattern.
- Go ahead and randomize your menu, but allow for batch cancellation of items. (If you listen carefully, you can hear a bean counter in the distance scowl into his latte.)
This is all assuming that Amazon wants this interface to move closer to my side of the me/them equation. They may very well not. It is a negative interface for their bottom line. Someone completing it efficiently is less of a priority. So maybe make it harder to use and see if they can extract some good data for the retention department to analyze. That’s the tension of business-centered design, after all. You have to find the middle ground between you and the customer. You have to provide value and extract it.
In this situation, they were extracting too much and providing too little. The tension broke. It didn’t work for either of us. I got frustrated and started entering random answers just to get on with it, because I could tell the interface wasn’t for me.
It was for them.
Wade Meredith has been designing, writing, and programming since 2005. All opinions expressed are his own and do not reflect those of his employer, friends, acquaintances, or other associates. His personal website is WadeMeredith.com.