Originally published at: http://www.sitepoint.com/3-ux-errors-avoid-building-unsubscribe-flow/
As a follow-up to the original post about 3 Common UX Gaffes and Easy Ways Around Them, I’ve compiled a list of some UX errors in email communication with users.
In particular, I’d like to focus on the unsubscribe flow and what too many companies are doing wrong in regards to it. In a time when our inboxes are absolutely overwhelmed (I’m at around 200 new emails per day now, 150 of which are from people), it’s important for companies to take extra care not to get on our bad side, even though they are, at that moment, losing us as subscribers.
Having built a mass-emailing engine in the past and having used it to bombard millions of users per month with my employer’s offers, I’ve tweaked our approaches for years and found that, beside good email design and decent proxies, a fluent unsubscribe flow can also improve conversion rate – even though you’re losing subscribers.
Enter Your Email to Unsubscribe
I opted to unsubscribe from most services and companies that don’t offer anything worthy of my attention this past weekend. One such company was Motorola which keeps spamming me with US-only offers, even though I indicated I wasn’t based in the US during the registration process.
That’s bad enough, UX wise, but how about this unsubscribe procedure?
They already have my hash in the URL (I’m assuming one of those is a hash that tells them which of their recipients clicked the link in the email – otherwise, they have zero email analytics and it’s no wonder they couldn’t figure out I wasn’t US based), so why ask me for an email?
The procedure to spare your users this is simple:
- When storing subscriber information, generate a hash for them.
- When sending out email campaigns, append said hash to links in email. Optionally, alter hash for every campaign.
- When the user clicks a link (like the Unsubscribe one), load his information from the system as per hash provided in the URL. Activate system permissions for email-based modifications only. Do not under any circumstances treat the hash as a session ID or anything as serious as that – you want to help your user to notification-related operations only.
- Apply appropriate operation to user (depending on clicked link).
Simple, safe, and user friendly. No extra step for users, and better analytics for you.
Login to Unsubscribe
Ok, I suppose providing the email into a field isn’t that much of a nightmare – it’s just one autocomplete click away. What is a nightmare? How about this?
About.me is a ‘landing page for people’ service where you can make a sort of ‘abbreviation’ of yourself for others to see. They can then follow links on said landing page to other resources related to you, all curated by you, of course.
About.me also sends out Weekly newsletters in which the information about who upvoted or visited your profile is. More often than not, this is plain annoying – especially if you have two accounts by mistake, like I do. So I opted to unsubscribe.
Uhh.. what? What do you mean ‘users’? I was sent a newsletter, no one contacted me. Yes, I want to stop receiving all email, just let me do that! Argh, okay, let’s ‘Edit Notifications’.
The problem is that I now need to log in to a service I have long forgotten about, and I don’t feel like resetting my password just to unsubscribe from them (in case I’m not using a password vault like LastPass).
Heck, it’s easier to just click ‘report for spam’ and solve the problem that way, which is how a service unwittingly ends up on spam lists and gets negative WoT reports.
The first screenshot is an unnecessary gateway to a more unpleasant screen. You can see that certain notifications have been removed by just visiting the unsub link (‘Users will no longer be able to contact you’¦’), so some email-related permissions were tweaked, whereas everything else needs a full login – an indication of ad-hoc development and no real architecture around this feature.
The solution was mentioned in the previous section – just authenticate the user by the hash (notice how in the first screenshot above they even have my full username in the unsub link) for email-related operations. This is extremely easy if your app is using a good ACL approach (- and if it isn’t, what are you waiting for? Drop everything and get to work!) so just let the user tick off all emails he no longer wants to receive.
A stellar approach I don’t see a lot is using actions. Actions will let you embed buttons in your email that show up in Gmail (unfortunately only in Gmail) and perform a certain call to a certain endpoint of your definition.
While this has many applications outside unsub actions, imagine being able to just click an ‘Unsubscribe’ action and be done with it! User friendliness to the max – that’s some Monday morning watercooler talk material for sure.
The only company I know that does this currently is, predictably, Google – most notably with Google Groups – but it does one thing wrong.
Which brings us to the next point.
Unsub Confirmation Emails
It’s all well and nice when Google implements unsub simplifications methods like these, but confirming the action by sending yet another email – that’s unacceptable. Especially if the email has absolutely zero additional value.
The problem is psychological. This is something a user who is unsubscribing simply doesn’t want. Chances are you’re dealing with an irate or angry user to begin with, one who is intent on cleaning their inbox, and here you are telling them what they already know.
This is like dropping a note in your neighbours mailbox asking them not to shortcut through your front garden. So they respond by shortcutting through your garden to tell you they won’t do it again.
Don’t send unsubscription confirmation emails. Especially don’t ask people to confirm their unsubscription – never ask a person to click a link to unsub fully.
In 90% of the cases, they will report you for spam and lose all patience with you. When an unsub link is clicked, that’s where it should end. If you can use Gmail Actions to avoid opening a new tab – that’s the best approach – but opening a page with a simple, friendly ‘see ya’ message is perfectly fine, too.Continue reading this article on SitePoint