A while ago I discovered a new app called Swell, which is a way to listen to and discover new audio content such as podcasts and radio shows. The more you listen to and rate, the better the app gets are recommending content to you.
There’s something that I love about audio content. For some reason, listening to content feels like I’m more focused. I feel less distracted and I feel like I understand and retain more.
I’ve been using Swell at the gym and I really love it. A few nights ago I listened to a Freakonomics Radio Podcast on Swell that talked about the idea of failing and why failing is a good thing.
The podcast had a lot of UX lessons in it that I think are really relevant to user experience design and product development. You should definitely listen to it yourself, but I wanted to point out two key UX lessons.
Lesson 1: Do not catch “Go Fever”
In the podcast, they tell the story of the Challenger space shuttle and how ultimately what lead to the crash in 1986 was the fact that the people who had the final say had “go fever” and ignored multiple attempts that engineers made to warn them of the risks involved in the launch.
Incase you don’t know the full story, the short version is that the temperatures in Florida were forecasted to be very very cold the day of the launch. The very cold temperatures were of concern to the engineers because a certain part of the shuttle, called O-Rings, had never been tested under such temperatures and the engineers were not confident that it was safe.
The engineer in charge of signing some type of “go” paperwork was so concerned that he refused to sign it and he made his boss sign it. Unfortunately, the worst happened and the Challenger blew up. If you’re interested in reading more, check out the book Truth, Lies, and O Rings by the engineer Allan McDonald who was on the Challenger project.
The moral of the story is that you shouldn’t launch just for the sake of launching. Don’t launch just to make a deadline. Don’t launch just to get some press. Don’t launch just to beat someone.
Launch when you are ready.
Lesson 2: Stop having post-mortems, start having pre-mortems
In the podcast, they interview Gary Klien who is the author of a book called Seeing What Others Don’t: The Remarkable Way We Gain Insights.
Gary makes a great point that in the medical setting, post-mortems benefit everyone involved (family, physicans, etc) except for … the patient.
So, Gary had a cool idea to develop the notion of pre-mortems. In a pre-mortem, the idea is that everyone is to assume that the project has launched and then create a list of what did go wrong. This is very different that operating under the assumption that something might go wrong.
In a postmortem, the goal is to come up with as many reasons as possible concerning what did go wrong.
Then, whoever is in charge walks everyone through all the ideas and the product or launch plan is adjusted accordingly based on the findings.
I think this is a really great exercise for product teams. I imagine if product teams did pre-mortems a lot of problems could be avoided. I think this would only work if all teams within an organization were represented (eg. marketing, business development, tech, product, design). The reason for this is that so many times, problems arise from miscommunication between these teams. So, having all these teams conduct a pre-mortem could likely get the teams talking sooner and help avoid big projects during or after a product launch.
Incase you missed it here are the key links from this post: