For frequent fliers, having the ability to change or cancel a reservation is very important. Southwest has a fairly friendly cancellation policy where at the very worst you will be able to hang on to credit for a purchased flight and reuse it on a future flight. There’s a section on their site where a user can check how much credit a specific confirmation number has.
This flow is not designed for the most seamless user experience and can definitely be improved. To begin, three pieces of information are required of the user:
1. Flier’s name
2. Flier’s previous flight confirmation number
3. Entry of a captcha code
When I tried to go through this flow, I could not get past step #3 no matter how many times I tried. In fact, from the message below, I’m not even 100% sure if this is the reason why I cannot proceed, but I’m 100% certain my name and confirmation number are correct.
Thinking more about the captcha code, I realized how unnecessary it can be. The purpose of requiring users to enter a code is to protect against fraudulent users who attempt to obtain airline credits by doing a brute force program to guess millions of confirmation numbers.
The enhancement I propose can easily guard against fraudsters while not ruining the user experience for the 99.9% rest of the users who are not fraudsters. Since Southwest.com has an account system where users can sign in, the site can relax the captcha restriction and require that the user enter a captcha code only after 5 failed attempts of their name/confirmation number pair. The idea is that since Southwest knows which user has logged in, they can do a rate-limiting solution instead of a one size fits all solution.
Good users wont be slowed down. Bad users will be stopped.
As an iPhone user, one common user activity is to watch a video. While you’re watching a video, there are very few things that could occur that would justify the phone stopping the video and grabbing your attention. An example of something that would justify stopping the video would be an incoming phone call.
I noticed an example where I did not appreciate the phone stopping the video. This occurs when the phone is running low on battery. If the phone reaches 20% or 10%, you will see a dialog alert like this and your video will stop mid-stream:
I do recognize that it is important for the OS to get the user’s attention for this use case, but I think there’s a better way of doing this. To explore a better way of doing this, we can look no further than the iOS update to how text messages are treated. Previously, text messages in iOS, would be shown as a dialog alert just like above:
As of iOS 4.0 (or was it 5.0?), text message alerts are not as intrusive and can float to the top of the page:
So the idea for this enhancement would be the same. If the user is watching a video, simply show them an alert but have it exist in the background with a dismiss button. This way, the user can continue to watch the video without being interrupted and know that their iPhone is about to run out of battery.
Yesterday, I noticed something unexpected when I combined the following two very common user actions on an iPhone:
1. Listening to music
2. Swiping through photos
Eventually, I landed on a video and to my surprise, the music stopped playing.
At first, I was very confused. Had I played the last song in a playlist and had that song concluded? I navigated to the song and saw that was not the case. Then I came back to the video and thought some more and decided that this behavior is by design due to the OS preparing to play the video. And since it is preparing to show the video above, the music I’m listening to needs to be stopped.
But herein lies the problem. I hadn’t even clicked play yet. I may not even want to watch this video and may want to continue browsing through all of my photos and videos listening to my music uninterrupted.
The better user experience is to allow the music to continue playing until the user explicitly clicks on the Play command.