The more I put time into product management, since, that’s my day job, you know, I’m more aware of user experience.

I’m talking about small features or behavior that if you ask any reasonable person, and by that I mean non-programmer, you’ll get a WTF look.

Kevlin Henney shows this kind of photo, and now that it has happened to me, I thought I’d share. Let me set the scene for you: Frankfurt airport, the departure flight screen (bottom-right) goes BSOD. You can actually tell from the error what’s going on, only you need to be a programmer to enjoy it. For the rest of the people it’s a waste of  a good screen. For the airport, it’s a waste of electricity.

The whole purpose of the error is to help the lucky recipient something to handle or report. Yet somewhere down the line, the end programmer forgot that the end user doesn’t hold the “How to handle BSOD” guide book for happy life. The sad thing is that the reporting part also doesn’t happen. What do most people do when with a BSOD? Restart. Regardless of the error. They can’t really read the error, it’s in an alien language.

Another example of experience gone bad. I was calling someone (who shall remain nameless) in a company (that shouldn’t but will). Here’s the voice mail message I got: “You have reached the voice mail system of company X. The person Y does not have an account in the system. Try calling later”.

Let’s see: how does it help someone who wants to reach Y. Part I: Confirmation – I got to the right company. Part II: Useless information. Part III: A very helpful message for someone who just arrived at the 21st century, but not for many others.

How do these things happen?

I can take the easy way out: A programmer decision, rather than a product manager. Developers communicate in Developish (both occurrences apply). So a programmer happened to find an edge case, needed to do some “error handling” and logged the error.

Usually that’s the case. I know at Typemock we’ve journeyed from error logging to helpful suggestions. We’re still getting better at it.

But the voicemail message wasn’t just a developer covering an edge case. Someone actually recorded the idiotic message. So there were a few people involved in approving and getting the message to me, and none of them asked a simple question: Is this helpful?

If you want to drill a bit more though, you’ll get  a sense that either no one was thinking about it, or didn’t think it was important enough to make a fuss about it. Keep your head down, do your job, and don’t rock the boat.

In either case, professionalism lowers its head, waiting for the business storm to pass.

That’s sad. If we’ve learned anything in the last few years is that we can create good quality products that customers like, through proper development practices and discipline. Agile has told us that in order to make that happen, you need to be at least vocal, if not a boat-rocker.

But products like that are mediocre. They don’t put the customer experience first, but rather “do their job”, and “report”.

Much like quality, product experience is part of everyone’s job. If you code a feature, you need to understand the customer. That means, for example, that “DISK_NOT_BOOTABLE” is not helpful for a normal person. We’ve past the age where a product manage defines everything and the programmers execute the plan. It doesn’t cut it.

And sometimes you are the customer (in the voicemail case). Is that the message you want to receive?

Then be vocal. Shout “this is the most stupid message I’ve ever heard, and I seem to find it as helpful as a SysRq button on my keyboard”. (Really, what do we need it for?)

It’s called Responsibility.

If you consider yourself professional, it should be part of you.