Justin French – Notebook

"Do Not Reply" Email is Lazy

2013-01-11T03:49:10Z

When you think about it, sending automated email to your customers from a “Do Not Reply” email address is a really odd thing to do, yet most online business do it. Why?

At first glance, it seems like a very cheap way to solve a very visible problem — allowing replies would mean someone has to read all that email and deal with it. If you’re the person dealing with all that email, or paying the team that does, your natural bias would be to treat this email as a cost. With the mindset of reducing costs, “Do Not Reply” is pretty appealing:

it’s cheap — a few hours to configure the email server and change the “From” address in the template
it’s effective — all that email will stop immediately
it’s accepted — everyone does it, we’ve all seen it before, we’ve been trained that this is normal

Of course, thinking about the customer’s experience, there’s nothing appealing at all:

it opens the conversation with a negative statement
it rejects the idea that the customer may need to reply, or may have a question
it creates a dead end, not a conversation, breaking the basic concept of email
it requires the customer to start a new thread in a new email or support system if they need to continue the conversation
it can only cause angst and frustration, rather than satisfaction and delight

It’s also important to realise that when we cut off all that noisy email, we also cut off the conversation with the customer — a valuable source of product feedback:

was this email clear?
was this email valuable?
was this email missing important information?
was this email timely?
was this email solving a problem for our customers?

So, dealing with all that email is a bad idea, and cutting off the email with a “Do Not Reply” is a bad idea. When faced with this type of problem, look for the constraint that’s hiding the most detail. In this case “we don’t want to reject replies” seems pretty solid, while “we don’t want to deal with all that email” seems to have some wiggle room. Maybe we can get better at dealing with all that email.

If we allow replies, what kind of emails will we have to deal with? What smaller problems can we find to solve? When we break out these smaller problems, there’s a much higher chance we can find simple solutions that don’t suck for customers.

This isn’t an exhaustive list, but it’s a start:

We’ll see a high number of “bounce” emails where the customer’s email address no longer exists, or their inbox is full.
We’ll see a high number of automated replies from customers that are out of the office, on leave, etc.
We’ll see some replies which are legitimate support questions highly relevant to the original email. A great example might be replying to an order confirmation email to check if it’s too late to cancel or modify the order.
Some replies will be routed to product managers that are a little off topic (like replying to the shipping confirmation email to get help with recovering your password).
Some customers will send new support emails to this address by mistake.

A lot of these can be solved with automated email filtering and redirecting rules on our mail server or within our support system. Here’s a start:

We can set-up filters to detect most of the bounces, and improve them over time. We can simply delete these or file them away.
We can do the same for the auto-replies.
We can use the subject line (“Re: …”) or reply-to email address in the replies to detect the source of the original email and automatically redirect it to someone who can help — the relevant support department, or better still, the relevant product manager. By helping the customer directly, they’ll be motived to improve the experience in order to avoid dealing with similar email in the future.
We can quickly read the off-topic replies and forward them into the regular support system. An pessimist would consider this a chore, an optimist would consider this an opportunity to learn more about what confuses their customers, or to develop further filtering rules for automation.
We can easily detect emails sent to the wrong address because they’re not replies (they also don’t match any of the previous rules), so they can automatically be forward into the support system, where they belong.

At worst, this is a few conversations, a few hours of configuration, a few days of watching the inbox to set-up new rules, and a few hours a month to monitor and review. Speaking of review, there’s value in the data we collect from accepting these emails:

We can monitor the bounces, feeding this data back into our product (marking accounts as abandoned or suspicious when it comes to fraud or spam, reminding customers to update their email address when they next login).
We can see which emails and parts of our product are causing the most questions and confusion, and need the most attention.

Yes, all this is more effort than a simple “Do Not Reply” address, but it’s not an outrageous cost, and not unreasonable given the massive upside — engagement with customers, faster product improvements, deeper insights, actionable data, better alignment with tools & behaviour, and of course, an improved overall customer experience.

Nearly everything gets better when you insist on a better user experience.

Provide Insight, Not Data

2012-10-14T20:37:00Z

When designing digital products and services, we need to find places where we can push beyond the Minimum Level of Service (the oven should cook my food, the car should start reliably, the phone should make and receive calls, the waiter should get my order right) in order to make something that our customers will value and love.

A great place to start is the places where you’re providing raw data — basic facts and figures, records from a database, or data without context. With a few rare exceptions, your customer is never looking for these atomic pieces. They’re looking for insight that they can help them make great decisions. Raw data is the least you could possibly do — asking your customers to decide what’s relevant, perform their own analysis, draw their own conclusions and filter out the noise for themselves.

I recently received a text message. Here’s the interesting part:

You’ve reached 80% of your 1GB data limit. Excess charges apply from 100%.

While I’m thankful for the heads-up (anything is better than a nasty surprise on my bill), this pretty lazy design. The onus is now on me to decide if I care. In order to make that decision, I’m missing a second piece of information — when will my quota reset? If I’m 50% through the month and 80% through my quota, that’s a problem. If there’s one day left, no problem. If I have 5–7 days left, I’ll need to be careful. By combining multiple relevant pieces of data, we can increase the value of the message:

You’ve reached 80% of your 1GB data limit with 5 days remaining. Excess charges apply from 100%.

With this iteration, I have everything I need to draw my own conclusion and take action, but can we do better? After reading this message, my conclusion would be to “take it easy for the next few days”, drawing an insight from the data. What if the system could offer me the insight instead of the data?

Your average daily data usage this month could lead to excess charges. Take it easy until Oct 5 or purchase a data pack.

Maybe we’re taking it too far, or being too imprecise, but the same thought processes can be applied to whatever you’re working on.

Let’s say you’re designing a software issue tracking system. The number of open tickets is usually vomited onto the project dashboard somewhere. In isolation, this number is barely useful. However, when combined with the average number of tickets closed per day, the system can tell me roughly how many days of work remain. When combined with the average number of new tickets created each day (or a comparison to last week, or last month) we now have insight into something much more valuable — are we keeping up, or are we drowning in tickets?

This high level information feeds directly into hiring and planning for a software team. It’s important, it’s someone’s job. Sure, they could crunch the numbers themselves if you give them the raw data, but if we focus on the customer and the information they need to do their job, it becomes clear that we should crunch those numbers for them, proving the insight instead of the raw data.

Context gives data meaning and value. You can dump raw data onto the screen and pretend you’re doing great work, or you can design something that truly helps your customers. This seems so obvious (it is), but take a look at the tools you use every day — there is so much room for improvement.

Metro on the iPad

2012-09-19T06:56:15Z

“Track 8” by Enderlabs is an intriguing new music player alternative for iOS . Here’s how they pitch it:

Your music library doesn’t have to look ordinary. Track 8 brings the Metro experience to your iPhone, iPod touch and iPad with an exciting music player. Browse and play your music in an immersive visual experience of album artwork and artist images.

I’ve installed it on my iPhone and iPad, and my only real complaint so far is that it’s a little sluggish on my old hardware. The experience is otherwise pretty great so far. The iOS and Metro (or whatever they call it now) user interface conventions are worlds apart, but I was able to adapt quickly. I have complaints and niggles, but that’s true for almost all of Apple’s apps as well. There were also moments of surprise and delight.

I’ve been fascinated by the Metro UI for a long time, and this is a chance to dig far deeper than I could with a demo phone in my local store. My first real Metro experience was far more personal, positive and effective because it’s my own music library, on my own device, with everything is presented to me in a new way. This is the Metro way, Microsoft’s way.

I’d like to think this is some covert Microsoft manoeuvre to expose millions of iOS users to the Metro UI. It should have been.

Either way, it feels like Enderlabs shipped Metro onto a tablet device long before Microsoft did, and that raises an interesting question:

If Apple beat everyone with the complete hardware, software and content ecosystem, would this have been a better way for Microsoft to pry open a tiny wedge in the market?

What about the stuff you’re working on?

Great Design Goes Deep

2012-03-07T02:40:14Z

You’ve probably already seen this quote from Chris Moseleym (Samsung’s AV Product Manager), discussing the threat of an Apple branded television:

TVs are ultimately about picture quality. Ultimately. How smart they are…great, but let’s face it that’s a secondary consideration. The ultimate is about picture quality and there is no way that anyone, new or old, can come along this year or next year and beat us on picture quality.

This is exactly what’s wrong with nearly every consumer electronics company. It’s why Apple’s loyal customers, incredibly successful product launches and awesome profit margins are the envy of the entire industry.

I purchased a new TV about five years ago, and I haven’t thought about picture quality once since we plugged it in. What do I think about every day? How frustrating this TV is to own and use.

The manufacturer won the battle on the showroom floor, but they absolutely lost the war. I don’t love their product, I feel no loyalty to their brand, and I’ll be wary of their products in the future. The next showroom battle will be much more difficult for them, and it should have been easier. We want to fall in love with your products and we want to feel great about our purchases.

If you can sell me one great product, then you will likely sell me many great products over the coming years. I’ll bond with you. I’ll sell your products to friends and family for you. I might even do something crazy like pre-order your stuff the day you announce it, sight unseen.

I don’t know what a great TV looks like yet, but I’m certain it won’t compete on picture quality or any other technical specification that seems to matter right now. The battle ground will shift from the showroom to the lounge room. Facts to emotions. A great TV will change the rules, reframe the problem and show us what’s important.

The solution (and indeed the problem) will be so clear and obvious in hindsight. This is great design, and it goes deep. It’s been done before in nearly every market from $650 phones to $20 project management software. What are you working on?

A Better iPhone Mute Switch

2012-01-29T21:16:00Z

Two weeks back, many of my favorite tech bloggers were covering the story of a switched-off iPhone’s alarm stopping a performance at the New York Philharmonic.

It should be smart!

John Gruber argued that this is an edge case — while Apple’s design is more complicated than simple “Off” and “Mute” switches, it’s far more likely to do what the user expects in most cases:

I think the current behavior of the iPhone mute switch is correct. […] if the mute switch silenced everything, there’d be thousands of people oversleeping every single day because they went to bed the night before unaware that the phone was still in silent mode.

I mostly agree with this sentiment.

It should be dumb!

Andy Ihnatko argues that Apple’s design made it hard for the user to prevent the interruption:

No. I should slide the switch to “Mute,” and then the phone goes SILENT. If I miss an appointment because I did that, it’s completely on me. If my phone disrupts a performance despite the fact that I took clear and deliberate action to prevent that from happening…that’s the result of sloppy design. Or arrogant design, which is harder to forgive.

My phone is almost always switched into silent mode (usually deliberately), and I rely on the alarm to wake me every day. The interesting thing here is that I learned that this is how the iPhone works, and have now become accustomed to it. If I interrupted this performance, I’d argue that the fault was completely on me — I could have ensured that there were no active alarms, or left the phone at home.

In the case of the Philharmonic, this was a brand new iPhone, and the owner learned the hard way how it works. It’s hard not to fault Apple here, despite Apple’s overall design being much better most of the time.

Recap

Here’s the requirements I’m hearing so far:

It would suck to miss an important alarm, no matter who is at fault
It would suck to be that guy, no matter who was at fault

As Marco Arment succinctly points out:

The user has issued conflicting commands, and the iPhone can’t obey both.

What about a preference?

Dan Benjamin also argued for a dumb switch, but in a later update, raised the idea of a preference:

Know what would be really cool? Let users decide for themselves what the switch does. They could call it a “side switch” like they do on the iPad, and give us choices about what it controls.

A preference or user configuration is a pretty obvious and valid design crutch when faced with requirements that contradict each other so drastically, but in this case, I think it raises more questions:

What would the default preference be? If it defaulted to Apple’s existing behavior, the conductor was still going to get interrupted, and if it was the other way around, I would have missed quite a few important alarms by now.
As they choose their preference, would users understand the design trade-offs and spend as much time thinking about this as Apple, John, Andy, Dan, you or I have?
Would this preference still result in people being surprised and disappointed?

What else could we do?

I think Apple has solved most of the problems already with a great design – the alarm does the right thing in the majority of use cases. At this point, with millions of iPhone customers now relying on how this stuff already works, it would be a shame to either go back to something dumb or offer a preference between smart and dumb without first answering a simple question:

Given this new information, could we improve the experience by making the smart stuff smarter, instead of dumber or configrable?

I think the answer is yes! Let’s take a look at those two opposing requirements again:

It would suck to miss an important alarm, no matter who is at fault
It would suck to be that guy, no matter who was at fault

What about this: When the iPhone is in “silent” mode, all alarms start off with vibration only. After a minute or so, the audio gradually fades in, increasing to full volume over the course of another two minutes.

Most mornings, I think the vibration of my iPhone alone would be enough to wake me. If not, I’d much prefer I wake up a few minutes later than completely miss the alarm because of a dumb switch (or a dumb user!). I think this satisfies this first requirement just fine.

For the second requirement, that guy would have had 60 seconds of silent vibration in his pocket to realise something’s going on, and another 60–120 seconds before the alarm was at full volume. Not as perfect as a dumb switch, but a significant improvement.

Maybe I’ve missed something, maybe it’s already been mentioned elsewhere, maybe it’s already built and tested by Apple, but this sure is an interesting design problem I enjoyed thinking though over the weekend!