Manual Override

I recently had an unexpected experience with Airbnb. I was served with violations and potential fines of over $40,000 by New York City after hosting a guest in my room for 3 days while I was traveling. I learned a few lessons from that saga, one of which was to do with designing customer support tools.

Here’s what happened after I contacted Airbnb to tell them about my situation. First, someone from customer service responded to my message telling me that they were sorry to hear about what happened, but that it was my responsibility to know the law and they couldn’t do anything to help. I wasn’t surprised by this response, but it obviously did not put a smile on my face. So what happened next piqued my curiosity as a user experience designer.

A day or so later I received an automated email cheerily asking me to rate their customer service:

Hello Nigel Warren,

We’d love to hear what you think of our customer service. Please take a moment to answer one simple question by clicking either link below:

How would you rate the support you received?

Good, I’m satisfied

Bad, I’m unsatisfied

To recap: facing potential fines of over $40,000. Thousands in lawyer’s fees. Dealing with an unhappy landlord and building board. Months of stress. Any human could guess what kind of reaction this email would invoke. The customer service rep who dealt with me should have had some way of manually overriding this automated followup.

This seems obvious, but it’s hard to plan for all the potential edge cases when making the internal tools that companies use. Doubly so because they rarely go through as much design and testing as consumer-facing products.

The kicker to this story is what happened after a few more days had passed. I was contacted again by Airbnb, this time from someone on a different team who left me a voicemail and sent the following email:

Hi Nigel,

I hope this message finds you well. My name is [redacted] and I’m a part of the Host Consultation Team here at Airbnb. We’ve noticed you’ve been a great host on the site, and we still have a huge demand for accommodations in the New York area. Are you still interested in hosting?

Please feel free to reach out if you are interested in renting your property again with Airbnb. My direct line is [redacted] - I look forward to hearing from you soon!

Cheers,

[redacted]

I should point out that by this time, the New York Times had published my story[1] and Airbnb customer service had then reached out to me directly to apologize. The timing of this last email couldn’t have been more comic had Mike Daisey invented it for a one-man show. My girlfriend received the same message, so clearly Airbnb reps were working from an automatically compiled list of hosts in New York.

The lesson here isn’t that customer service is hard – that’s a well known fact. The lesson is that automated CRM systems need a manual override switch. It’s impossible to design for every possible edge case in an unpredictable world, so there needs to be a flag that says “the normal rules don’t apply here – shut this machine off” for when things get extreme.

---

1. Although at the time of publication the violations had been dismissed, they have since been reissued and the case is ongoing. A mighty stress.  ↩

Addendum: Switching Apps

It occurred to me after the last post on the confusing gesture shortcut to switch apps on the iPad that there's another potential issue at play. Going backwards through your app history means moving from left to right. This is the reverse of what happens in a web browser, where navigating backwards goes from right to left.

It seems inconsistent that ordering by time goes in one direction in Safari and in the other direction system-wide, especially when similar swipe gestures can be used for both. Maybe these two models need to be reconciled.

Sweat the Details: Switching Apps

Apple gets a lot of credit for pioneering the use of animation in UI design. For the most part it's thoughtful and helpful. Having elements slide on and off screen gives a strong sense of physical space that helps users understand their place in an app and how the interface reacts to what they are doing.

Unfortunately the iPad has a subtle problem with one of its system-wide animations. When using the app switcher (revealed by double tapping the home button) to toggle between apps, the app you were just using moves backwards and to the left, suggesting that it is now residing to the left of the app you switched to.

This conflicts with the four-finger shortcut to swipe between apps. If you use the app switcher to switch to an app, then use a four-finger swipe to get back to the first app, the animation suggests that you should push the screen to the right to reveal the original app sitting to the left. However, the opposite is true.

Even after months of using the iPad I still get caught out by this issue. The subtle spatial cue in the app swapping animation causes me to push the screen the wrong way almost every time.

It seems an easy fix would be to change the direction of the app swapping animation triggered when using the app switching bar. I don't think this would conflict with other parts of the OS, but if anyone can think of any issues I'd be interested to hear.

Update: There may be another issue at play here as well.

Easier Colors

Thibaut Sailly shared some interesting thoughts today on the value of using CSS preprocessors like LESS and SASS. One item that stuck out to me was his comment about using the system-wide color picker on OS X:

[...] Referencing colors by "blueGreen_4" is more efficient than "fourth blue from the right in the system palette I set you up last week".

This reminded me that many UX designers, visual designers, and developers I've worked with are unaware of the color palettes tab in the system color picker. Using it can save a lot of time if you work solo and a lot of headaches if you work in a team.

Most people are familiar with the default view of the color picker. There is a color wheel. Beneath it is an area for saving color swatches for re-use.

However, as Thibaut mentions, trying to pick out "the fourth blue from the right" in the swatches area at the bottom is difficult and tedious. One of the color picker's useful tricks is the ability to create palettes with named colors. These days, I spend most of my time here:

Not only can you create your own palette and name the colors, but you can quickly switch between different palettes:

Even better, you can send these palettes to other people. Create a new palette and you'll find it saved in ~/Library/Colors/. Send all the palettes you've created to your team and you'll never have to count those tiny swatches at the bottom of the color picker again.

Anyone needing detailed instructions on how to work with this part of the color picker should reference Robin Wood's instructions.