If Apple’s password creation process is a model for how to create good user experience using context and progressive disclosure, its password recovery process exemplifies what you shouldn’t do using those same tools.
It’s Sunday morning and I want to update my podcast subscriptions.
I’m a dual platform human. For me, iTunes runs on the Windows machine – mostly because it came first but also because my Windows machine has a much larger storage capacity than the Macbook.
Normally this is a seamless process:
- turn on the computer
- open iTunes
- it checks for new episodes of the podcasts I am woefully behind on listening to and downloads them
Not this Sunday morning.
This Sunday morning, iTunes wants my password, which I changed sometime in the past two weeks for some reason I only barely remember.
I enter what I think is my password. Denied. I enter a variation. Denied again. I enter a third possible variation. Still denied.
I select “Forgot Apple ID or password?” and my nightmare begins.
The only thing marginally good thing about this process is the link in iTunes takes me directly to a form I can interact with instead of to the multipurpose landing page Apple has created for their ID system. I say marginally good because form it presents me with fails on the link’s promise.
Yes, I can start a process to change my password, which is likely the most common reason people follow that link. While it does provide functionality to start a process to recover my Apple ID, it minimizes that functionality to such an extent I would have to hunt for it if that was my task.
Here’s where the process breaksdown completely.
The next step is to enter your phone number. It’s a fairly safe assumption at this point that someone comfortable with downloading media to listen to from a computer or mobile device has a phone capable of receiving text messages, but it’s still an assumption.
Once I enter my phone number I am almost instantly given a screen that tells me a text message has been sent and provides me with a box to enter the verification code I received. Except my phone, sitting right there on my desk is silent. So I wait a minute, maybe two, and lo comes my verification code which I dutifully enter into the box on screen.
Except Apple tells me my session has timed out and my verfication code is no longer valid.
Back to step one I go.
Rinse and repeat two more times before I notice wait, I have the option of resetting my password from a “trusted device,” except the only trusted device it lists is my Macbook, which is sitting quiet and off on my desk. Now I have to turn the Macbook on except…there is no message.
There’s nothing in the notification bar, there’s no pop-up, there’s nothing.
At this point I think, OK, maybe this process will be smoother if I try it using an Apple device.
I open the App Store on the Macbook and nope, I’m not signed in there either.
Again, I select “Forgot?” above the password box and am told I can reset my Apple ID password after I enter the password for my device yet when I use the “Reset Password” button I’m presented with no option to enter that device password.
Back to step one I go where I decide to engage the account recovery process.
To give them credit, Apple is up front about how long this process will take but even this process is faulty.
The account recovery process requires having three pieces of information:
- my Apple ID
- the verification code Apple will send to my “trusted phone number”
- the credit card number associated with my Apple ID
This means I need to find my wallet which, unlike my phone and my Macbook, is not on my desk.
Can you guess what happened next?
By the time I found my wallet my session had timed out and I had to start the account recovery process over again.
After waiting 24 hours for the Account Recovery process to complete Apple offered me same two choices to reset my password I was offered 24 hours prior: Reset my password using a trusted device or go through the Account Recovery process.
Perhaps the 24 hour waiting period is to enable to users to change their own context by looking up the split, spread out help documentation that will allow them to enter a device password on a trusted device or find the notification message the “use a trusted device” option sends.
Whatever the reason, Apple’s password reset process stands as a shining example of what of the ways to ruin a user’s experience with your product.
Why these processes are both dismal failures
Both processes makes unreasonable assumptions about context
While many people have abandoned landlines and now are no more than an arm’s length away from their cellphones at any time of the day or night, this isn’t true for everyone. Beyond that, Apple makes significant assumptions about the speed with which data travels on systems it does not control.
Even if someone is using an iPhone, multiple factors like provider and physical location affect how fast she receive a text message, which makes Apple’s short time out for the verification code a significant flaw in their process.
Apple also makes an assumption that a user will have enough familiarity with their systems to know where to find notifications or how to enter a device password. This assumption of knowledge creates an undue burden on the user when Apple should be guiding him through the process.
Both processes obscure vital information
Both the password reset and account recovery processes are perfect examples of the difference between progressive disclosure and withholding information.
Hiding the fact that a user will need to verify a stored credit card provides only the tiniest bit of protection for users who have had their devices stolen. Revealing this information only when the user needs to enter it could be considered progressive disclosure but not when combined with a short session time that makes assumptions about context and how handy that information will be when needed.
Information about how to interact with these processes – where to find password entry boxes and notifications – is buried in Apple documentation that isn’t available contextually from inside the process. This increases the cognitive load yet again by putting the burden on the user to find the information he needs to adequately complete the process.
Apple offers multiple paths to reset your password…except not really
According to Apple’s password reset documentation there are multiple ways to reset your password, yet their internal cues offer you a path to only one of these options.
Since Apple’s Account Recovery process takes 24 hours (yes, that’s right, 24 hours on the clock), providing these alternate ways to reset a password would help users avoid the pain of that delay.
Apple offers no cues to the user who is locked out that settings inside her account determine which process they present, and why certain processes might not be available. This failure creates more frustration for the user who bothers to look up the documentation before engaging in the process.
- A user who forgot a password is trying to get something done but can’t. The context for her is most likely to be some combination of annoyed, embarassed, and frustrated.
- Take context, level of knowledge, and latency in systems, such as cellphone networks, into account when designing processes that require interaction with multiple pieces of information.
- Protecting users’ data with a secure process is an admirable aim, but not at the expense of users being able to complete their tasks.