A few weeks ago, I had the mortifying and frustrating experience of missing a flight that I was very, very early for. How does one go about missing a flight after sitting for a few hours in the terminal? It turns out that it’s a relatively easy process.

• Step One: Arrive early, then have your flight delayed.
• Step Two: Hear the announcement that your flight will be boarding soon. Make a brief trip to the facilities so as to avoid the uncomfortable experience that is using one of the tiny bathrooms on a regional aircraft.
• Step Three: Walk back to your gate, see that the agent is gone, and that your flight status hasn’t changed on the airport’s digital signage. Assume that you’ve been delayed again.
• Step Four: Look up at the digital signage just in time to watch your status change from “on time” to “departed.”

As best as I can tell, the flight only had a few passengers on it, they boarded quickly and then took off post-haste to try and avoid further delays. They claim that they paged me, but I never heard them. There was a flight from another airline that was boarding at the same time, so it’s very possible that my page got drowned out by the other gate agent.

Most people would have fumed for a bit, had a glass of wine in their hastily booked hotel room, flown home the next day and then forgotten all about it. I work on UI for a living, so I’m still thinking about what this incident can teach us about the user experience. I think that there are a few takeaways.

1. Beware your customer’s expectations, especially the ones that don’t get verbalized.

I might have had a chance of making my flight if I’d flagged down an airport employee as soon as I realized what had happened. Instead, I made the (in hindsight) silly mistake of going by the flight status on the terminal’s digital signage. My expectation when flying is that the signs will say “boarding” once the boarding process has begun. They might even say “Paging Passenger So-and-so.” You could make a reasonable argument that the fact that my flight never showed up as delayed and that I’ve never seen a flight at that airport listed as “boarding” should have been a pretty big tip-off that I needed to ask a real person instead of going with what it said on the TVs. But that’s the thing about sub-conscious decisions… they don’t get a lot of mental scrutiny. I didn’t think about my assumptions until *after* I’d missed my flight. And, by then, it was too late.

If any aspect of your UI relies on your end users thinking too hard about how it’s all supposed to work, you are not providing the optimal experience. The best UIs are intuitive. And some of the most important features to include might never got mentioned in an SOO meeting. There are certain things about how systems work that some users may have internalized to the point where they don’t even mention them to you. That’s why it’s so important to ask a lot of questions and ask for examples. I will always do my best to get my hands on a user’s existing system. It’s only by pressing all of the buttons and seeing what happens that you can really see what they’re used to. They very likely have expectations that they don’t even know that they have.

A good example of this would be mute and privacy buttons. I never want to be on the receiving end of an angry phone call after someone heard something they weren’t supposed to on a conference or video call because their audio wasn’t properly muted. Mute and privacy mean very different things to different people, and it’s important that your interface makes it clear what state the system is in. There’s also the question of feedback on the buttons. Does the icon change? Does the color change? Personally, I hate the look of flashing buttons, but that’s what you might need to do in order to avoid multiple service calls for “audio problems” in rooms where the system is muted. And, finally, if your system does any auto-muting or un-muting, it’s important that your users are expecting it. If they were already expecting it, you’d better hope you’ve covered that in your discussions and implemented it properly.

Many of these issues can be solved with a well-formulated scope process and with good documentation. I also find that it works well to create a dummy UI so that users can click the buttons and see what happens. The act of seeing things move on a screen will often help to drill down to issues that you might not have found if you just sent over a bunch of screen shots. And then, at the end of the day, your system still needs to be easy and intuitive for someone who *didn’t* spend 15 hours in meetings discussing button and slider placement.

This is why the people who are really, really good at UI (I am not including myself in this category, at least not yet) get paid so well. It’s a difficult, and often thankless job.

2. Base your system on the premise that some of its users will abuse it horribly.

If my gate agent paged me, it was likely lost in the noise of another delayed flight with a lot of passengers boarding very, very quickly. Technically, she paged me. Functionally, it was like she had just sat there and said nothing. I am not an expert on paging systems, but it seems like this could have been avoided by only letting one gate agent use the system at a time (and providing some sort of feedback that they need to make their announcement when they are clear to use the system). It’s quite possible that there is a logistical limitation because it was different airlines. It’s not my place to criticize a system that is outside my area of expertise. I am merely using this as a lesson in how our end users might interact with our systems.

There’s an old joke about someone who goes to see their doctor and says, “It hurts when I do this.” The doctor looks back and says, “Well, then stop doing that.” Groan all you want, but if your answer to a user saying, “The system does [bad thing] when I do [something maybe not so bright]” is, “Well, then don’t use the system like that,” you are probably not doing such a great job yourself. People don’t always pay attention to the buttons that they’re pressing. They get frustrated when things don’t happen right away and start jabbing at buttons repeatedly. If your system relies on your ends users to police their own behavior, you are borrowing trouble. You should be locking out certain functions while a projector warms up. You should  prevent your system from queuing up commands while someone hits buttons and then letting them all go through at once. People hate it when the lights won’t stop flashing, or when the volume suddenly jumps from “barely perceptible” to “ear-bleedingly loud.” While we’re at it, unless there is a valid reason that your users need an “ear bleeding” mode, I think most of us know to lock them out of that function as well.

One thing that I’ve found that’s really helpful in defensive designing is to ask other people to mash buttons on my panels for me. If you don’t have a dedicated QA staff at your shop, you can either find the least technical person in your office… or the most inquisitive one to push buttons for you. Either of them will very, very quickly help you locate the ways in which an end user might “break” your system. Really, you just need someone who will say, “I wonder what happens if I do this” over and over again.

I program the same way I drive a car. I assume that everyone out there is about 10 seconds away from running me off the road.

My final takeaway is less about UI and more about big data.

3. Big data doesn’t always tell the whole story. Beware the law of unintended consequences.

As we were straightening out how I was going to get home, my gate agent very indignantly told me, “We waited three whole minutes for you.” At first glance, that seems rather uncharitable of her. Especially when you factor in the fact that I was 16 *hours* late getting home. But then, when you put it into context, a very different picture emerges. Airline departure times are assiduously tracked these days. Just a few minutes can be the difference between a good rating and a poor one. If you rank airlines on how quickly they can get their planes to their destinations, they are going to start doing everything they can to get their planes into the air as quickly as possible. Not even two weeks after I missed my flight, I was on a different airline’s plane and watched a flight attendant tell the man in front of me that they just couldn’t wait for the rest of his family and we’d be taking off without them. Not 30 seconds later, another flight attendant announced to the plane that we would be arriving 30 minutes early at our destination. I thought the suddenly solo traveler’s head was going to explode.

Flight delays are annoying. We all want to get where we’re going on-time. But they factor into ratings in a way that “angry passengers stranded at the gate” do not. That’s the price we pay for the technological advances that have allowed us to track just about everything. And, for the most part, this is a great thing. It means that we can all avoid hospitals that have high mortality rates. It means that UPS drivers are now instructed to never make left-hand turns, because they crunched the numbers and avoiding left-hand turns is both faster and safer. But it also means that a lot of us have had the experience of being rushed off the phone when calling tech support because their metrics are based on how many calls they can handle in an hour.

When you introduce metrics into a system, you just might be incentivizing less than optimal behavior. Try and think about how your employees might end up attempting to game the system. And always be prepared to make changes if you discover a way that they’re doing it that you hadn’t even thought about. It’s the law of *unintended* consequences, after all.

By far, the biggest takeaway from all of this is clearly:

4. While waiting for your small, regionally based flight… go ahead and use the facilities about 10 minutes *before* you’re scheduled to board.

You’re just going to have to trust me on this one.