The Role of Expectation in Design

Just as you should have a clear vision and clear expectations for your product, your product should convey a vision and clear expectations to your customers. People work better, and are generally much happier, when they know what’s expected of them and when they know what they can expect.

Managing expectation is a big part of product design. Especially when things don’t go as they should. Having something work is just the beginning.

The amazing escalator. And Mitch Hedburg. #

Recently I was reminded of a great “design joke” by Mitch Hedburg. (Thanks to Roman Mars and the awesome 99% Invisible podcast!)

The Joke goes something like this:

I like an escalator, man, because an escalator can never break, it can only become stairs.

There would never be an escalator temporarily out of order sign, only an “escalator: temporarily stairs.”

Sorry for the convenience.

Escalators are a great example of having a smart backup plan for when things are broken. In this case semi-broken is better than not working at all, but, if you really think about it, sometimes broken and inaccessible is the better choice.

A broken experience makes for a poor experience, even if you can make it work. Have you ever stepped on a broken escalator? You might know it’s broken, but it’s never the less a very a strange and disturbing experience. Just yesterday I stepped onto a clearly un-moving escalator. It was super weird.

Apply that same theory to almost anything. When things dont work as they are expected to, they feel broken, regardless of if they’re actually broken. Even worse, there are times when something is semi-broken might actually cause harm. Stepping onto a broken elevator unaware could actually cause you to fall, for example.

In those cases, and others where the behavior and experience is going to trigger something unexpected, it’s best to take the time to explicitly set expectations, even if you have to interrupt the experience to do so.

Think back to the escalator; if you know its broken and you step on, you might still have a weird feeling, but you’re going to be ready for it, and probably not too disappointed. If you step on not knowing; you’re going to be shocked, or startled, and you may actually hurt yourself!

(This video is related and pretty funny.)

With a broken escalator, for example, it’s probably a good idea to put a sign in front letting people know its broken. And I think it makes sense to put that directly in front of the entrance. Especially a down escalator. You don’t want someone who’s looking down at their mobile phone to misjudge and go tumbling down.

How this applies to digital products and experiences. #

A good example of this with a web experience is A Book Apart’s handling of PayPal’s long time problem of mixing up addresses. When you place an order for a book, and you’re getting kicked into PayPal’s system, they remind you, not once, but twice—a necessarily heavy handed decision, in my opinion—that you should double check your shipping address. It’s far to easy to accidentally pick the wrong address. The folks at A Book Apart know that, and have set expectations accordingly with a warning and a reminder:

This protects against miss-delivery that, regardless of who’s fault it is, could reflect poorly on their products. It’s also a nice example of how setting expectations can not only limit error and provide a safety-net for when things could go wrong, but can also bring a small nugget of delight.

As someone who’s had a few PayPal address snafus, I know it brought a small smile to my face.

It’s also useful to explicitly set expectation when a designed experience goes against expected convention. Take this message at the bottom of iDoneThis emails.

iDoneThis is a part of the slow web movement. After you email us, your calendar is not updated instantaneously. But rest up, and you’ll find an updated calendar when you wake.

It clearly states that your completed tasks won’t be reflected in the calendar right away. Aside from the mention of the “Slow Web” movement here, which I find intriguing, you’ll note that they are very clearly setting the expectation that their customer’s data isn’t going to be updated right away.

This is key. Had they not done that, they’d surely have a boatload of people hitting them up asking why the information they’d just sent into the system wasn’t there.

There is also the added benefit of instilling a sense of peace and confidence in their customers. The “rest up and wake” bit is really nice. Especially in a world that’s always demanding attention. Assuming the information is available when they say it’ll be, that’s delightful. And a really great example of how setting expectations should work.

Bottom-line: make sure your product is setting expectations if something is broken, or an experience goes against accepted convention, and think carefully about what functionality you leave exposed when parts of your product aren’t working.