How to make subscription activation a pain
When we engage with a web application, the interaction is something like a conversation.
A click is not unlike asking a conversational partner a question. We expect confirmation that the listener heard the question (a head nod, a verbal cue) and some sort of answer. Even if the answer is “I don’t know.”
This leads to a key heuristic for web (and mobile) design: making system status visible. That’s a fancy/engineering way of saying that applications need to provide feedback, to respond after we, figuratively, ask a question.
The web application in this case study violates both concepts.
Seattle Times subscriber account creation
I recently subscribed to the paper/online Seattle Times. The paper sent me an email reminding me to activate the online subscription.
It’s been a while since I had a print subscription, but I’ve had an online account (for commenting) for a long, long time. I used the same email to subscribe that I had been using for commenting.
It wasn’t clear from the email what “activation” meant, but the link led to a page with two options: “log in” or “activate account”.
Since I was activating an subscription, I started on the right. But when I tried to create an account using the email associated with my subscription, I was informed that the email was in use.
The “activate your account” email did not acknowledge that I already have an account with this email address at the Seattle Times. Neither does the landing page.
And yet the two databases appear to be linked.
Given that linkage, the activation landing page could have pre-populated my email address and prompted for password.
If using a different email with the account is an important feature, how might subscriber services have provided an option for using a different email address? Here’s one (although I believe that a change like this should be managed after activation):
After logging in, I was greeted by this confusing set of options:
I had clicked a link titled “Activate my account” to get to this screen.
After clicking that link, I should have been greeted by a “success” or “thank you” or “we need more information” message. Not an warning complete with yet-another-activate-link! Moreover, how in the world could a non-subscriber reach an activation page?
After I clicked this second “Activate” link, more hoops. Note, if activation is a multi-step process, this should have been the screen that greeted me after my first “Activate account” click.
Given that this a multi-step process, it would be helpful to add that information to each step. Think Amazon checkout.
Next, missing feedback
I provided subscription details in the above screen, which led to this confirmation summary.
It’s at this point that the application stopped talking to me.
I clicked “Finish” and nothing happened. Well, I could see bits were being exchanged, but the page status didn’t change.
I clicked again. Nothing.
Am I finished, ie, is my subscription activated?
I can’t tell because system feedback has ceased. The page (system status) is unchanged.
This is not unlike having someone hang up in the middle of a telephone (or IM or text) conversation.
It’s critical that web (and mobile) applications finish the conversation!
When customers are left hanging, like I was, we don’t know whether or not we have been successful. It’s the application’s responsibility (ie, the web devs, PMs and so on) to complete the conversation.
It is possible that this is “the end” — that I have successfully activated my subscription.
But it’s also possible that the application doesn’t like my browser. Or that the backend was busy. Or something. In any of those cases, the application should have told me that it was having problems.
But by its remaining silent (the page remaining unchanged), I just can’t tell.
The system had not activated my account.
I started over with Safari. This time instead of remaining “silent”, that “Finish” click led to this:
When I logged in to manage a vacation hold, I got this double-message: