“What if the user wants to…”
is the beginning of many thoughts uttered around conference room tables in eCommerce departments all over the world. Sometimes what follows will lead to a brilliant idea, and other times (many times) it will lead down a long and winding road to peculiar user experience decisions that likely do not really help your users (and therefore also do not help you). So how do we tell the difference? We have plenty of tools: analytics, user interviews, beta tests, A/B tests, competitive analysis, industry best practices, and even good old fashioned Socratic questioning. Even with all of this—reasonable people disagree, compromises get made, and executive whims get developed. Every team intimately familiar with their website will know of a few features or workflows that will evoke a Jerry Seinfeld rendition of, “Who are these people?!” (pro-tip for younger readers: quoting Seinfeld will instantly ingratiate you with any team of mixed generations).
I’ll provide a few examples:
The Jealous Yet Generous Boyfriend
I worked on an iOS app that supported the workflow that follows from this user story: What if the user is the significant other of the person who owns the phone and wants to go into the app to surreptitiously purchase the contents of her cart as a surprise?
This app did not support guest checkout at the time, so it had to include the workflow to allow a user to logout of one account and register a new account that had the cart from the previous account transferred over to it. This was no small technical effort and this scenario raises so many questions—primarily: How and why does he have access to her phone?
The Right to be Forgotten
One user story I think is worth supporting is: What if the user has an account on the site, but cannot remember his password and would rather go through guest checkout? Any use case with the precondition—the user cannot remember a password—is almost certain to occur with relative frequency. Without logging in during checkout you lose the advantage of saved payment and shipping information, but maybe to the user re-entering some info is preferable to going through a forgot password workflow. Supporting this workflow is great (as opposed to forcing the user to log in or use a different e-mail address to checkout), but raises a question about order history: When the user eventually logs into the account, should these guest orders also appear in order history? They were all placed under the same e-mail address after all. In my narrative about the motivation for the guest order being temporary resistance to go through the login workflow I would think including all the orders would be a nice touch.
Alas, one site I worked on went out of its way to exclude these orders on the basis of: What if the user does not want the order to appear in order history? That is a pretty specific desire for a user to have. The full narrative was: What if the user shares an account with someone (do our terms and conditions even allow that?) and is buying a gift that they do not want to appear in the list? Again, this raises questions. Is this user also deleting the order confirmation e-mails we send to further hide evidence?
The (Half) Motivated Grandma
Many sites have public wishlists (other people can see the items you have put into your wishlist and hopefully buy them for you), and even allow users to search for a particular person’s wishlist. How do you manage searching for and showing a search result set of wishlists that one—allows you to positively identify the right person and two—does not reveal personal information to strangers? One of the simplest ways to manage this (and in my humble opinion the best way) is to simply drive the search off of e-mail address: I type in the e-mail address of the person who I want to buy a gift for and I either get 1 or 0 wishlists returned. Would this work 100% of the time?—no not at all. Would it work most of the time?—I think so.
As a counterexample, what do the user stories look like that poke holes in this method? What if the user has multiple e-mail addresses? That one is fair (most of us do), so then the wishlist searcher would potentially need to try more than one e-mail address. What if the user does not know the person’s e-mail address? It's possible, but it was presented as this story: Your grandma wants to surprise you and knows you love a particular brand, so she’s going to come to our site unbeknownst to you and buy an item off your wishlist. She doesn't know your e-mail address, but knows your name and home city. She seems pretty motivated though, so can't she ask someone else who knows you for your e-mail?
Now is a good time ask...
Is this the makings of a great eCom product, or are we writing eCom fan fiction? Who are these people? We like to think we’re spontaneous, but the worldview of these stories is couched in a lot of surprise versus the likelier reality of you sending your Grandma your Christmas list. There are certainly ways to build experiences to accommodate these hypothetical users, but the time we devote to the well heeled boyfriend who knows the passcode to his girlfriend's phone or the grandma who can work a wishlist search but is not familiar with e-mail gets a team’s energy away from experiences in which your users are more likely to derive value and joy.
Admittedly these are some crazy examples, but they are all real examples. If you look hard enough almost every site has some functionality included to support some outlandish (and likely non existent) user behavior. Sometimes they are small and appear innocuous: I also once worked on an apparel site that when arriving at the product page would auto select size medium because, “If you’re medium it’s one less click”. So in this instance we do know who these people are, but it still may not be in the best interests of your users.
In 2014, my colleagues and I started a dictionary that gave names for some of these practices we encountered regularly. Knowing our experiences are not unique, I decided to create this blog to share my experiences with others. If you work in eCommerce, UX, or digital product management you may find it highly relatable and hopefully at times insightful. If you do not work in these fields, this blog may change the way you think about websites as you go about your daily digital life. The topics covered are roughly relevant to anyone who uses the internet and shops (that’s you).
So in closing, I will leave you with this definition from my budding eCom dictionary:
eCom Fan Fiction n.
- User stories and workflows that are based on the literal realm of possibility of a what a user could do. Distinct from stories and workflows that based on what a user is likely to do.
- This blog