Case Study and discussion

This blogger has moved!

I want to invite you to my new gig over at Light Thinking. We are devloping light gadgets for photographers. You can't be a designer and not be into photography at some level. Maybe you know about the whole off-camera strobe movement that originated over at at strobist? Maybe you even know about the new HDSLR cameras and all the amazing stuff people are doing with them? Visit Light Thinking

 

Case: Malmö Aviation

Booking airline tickets from a mobile phone

Screenshot from app

Daniel Taylor goes to town on engineers in his blog post "This is what happens when we let engineers run the show." I have to admit that I had a few thoughts like that when working on the Branova mobile application for buying airline tickets.

Now, there is nothing as rewarding as criticizing a user interface. ANY user interface is a compromise. There are all kinds of technical constrains, context issues, etc, etc and it always shows. A user interface is easy to criticize and I love doing it.

Anyway, lets start... 

The task at hand

We were hired by Branova, a company that makes reservation systems for airlines. The task was to design and implement their Mobile eTravel Suite, an end user application for buying, changing or canceling tickets, and checking in. Their pilot customer is a Swedish airline called Malmö Aviation.

The current process

 

 

First page (click to enlarge)

Second page (click to enlarge)

Third page (click to enlarge)

On the web, booking a flight is a fairly standard type of procedure across airlines. It is quite a number of steps: you have to choose one way or round trip, to, from, departure dates and the number of adults, children and infants. After that, you are presented with a number of flights to choose from and what type of ticket you want. At this screen you can also change the details you entered in the first screen. If you accept the booking details you go to the checkout screen where you enter names, billing details. On the last screen you get a receipt.

The challenge was not to get all of this onto a mobile phone. The challenge was to decide what subset of this functionality that made sense on a mobile phone.

Scenario

What scenarios are relevant in this case? Booking a vacation with your family? No. In that scenario you probably want to spend some time in front of your PC, maybe researching alternative destinations, comparing prices etc.

The primary scenario is a business traveler booking domestic flights. This type of traveler makes up a large portion of Malmö Aviations customers. Most people who have some amount of job-related travels have an established relationship with the airline. So payment was not an issue we had to deal with in this case.

Most of these travelers book single person tickets, so we were able to avoid the added complexity of booking multiple persons; entering their age and names, provide alternative delivery methods for getting the travel documents to them, etc.

Booking from a phone

Usually, when booking an airline ticket from a website, you fiddle some knobs and dials (dropdown lists, calendars, checkboxes etc). When you are satisfied with your settings, you hit a button labeled "Search" and the system will contemplate your "query" for a while and then show you available flights. 

Detail from application structure. Click for overview.

A more linear structure that supports back and forth movement is better suited for a mobile environment. A linear "interview"-type interaction is easier for the mobile user if it is not too long. It is also a lot better approach if the user gets distracted. You only have to consider one question at a time.

Background shows ticket

There is only five pieces of information we needed from the traveler: From, To, Date, Time and Ticket type. This was laid out in a manner where the user could easily see the progress.

We moved the One Way/Round Trip question to the end of the process. Most flights are booked one way only. However it appeared that if the return time is known, the traveler is not comfortable booking the flights separately. If you are going on a round trip you don’t want to commit one way before you know that you can get a suitable return ticket. So at the end of the booking we gave the traveler the choice to either commit the one way ticket, or book a return flight before committing.

Interaction test

This is a quick Flash test of the interaction for the booking process. It is a "slide show" so you just click it to proceed.

 

This is a "slide show" I made in Flash to check out the interaction. Click the image to advance. Click the "please wait" screens too :-)

Fast and pray

At this point, the interaction design budget was spent. So it were more or less waiting and praying that the idea would survive the rest of the implementation (programming) phase. It did not. Well, some survived, some did not. The developers also have budgets and they love to "reuse".

How did it turn out?

Branova made a promotional video showing the product in use. What you see is more or less whet the release version looks likes. It shows a booking in real time, so you can see that it is quick. To pick out a few interesting questions relating to before/after:

1. The interaction feel is fairly different. For technical reasons, the entire screen transits instead of just the "question". This breaks the concept of building up the ticket on the background area. On the other hand, it shows very clearly that you can easily navigate back and forth. What do you think?

2. The idea was that when you click something it is transferred to the "ticket area". In the video you can see that the current selection is mirrored in the ticket area further breaking the concept. I don’t think this is good. Do you agree?

3. If you view the video to the end where she checks in, you see that the list showing "my tickets" looks the same as the booking ticket process. This is highly unfortunate in my opinion.

Conclusion

OK, I'm a problem-oriented person. The Branova Mobile eTravel product is, as you can see from the video, miles ahead of anything available elsewhere. It is not perfect, but it is definitely usable. In order to learn and progress in my craft, I tend to focus on what can be done better. Sometimes at the sacrifice of celebrating what we actually have achieved. 

Branova reports that there has been strong interest from other airlines, so we will probably get to work on a new version later this year. I'm looking forward to that.

• The product was built with the mBricks enterprise application development tool.
• The product owner is Branova. 
• The development was done by Branova and Teleplan.

Morten

Comments

[Morten Hjerde]

Barbara: You are spot on. The devil is in the details and the while the overall structure and navigation seems to work well, there is definite potential for improvement on the visuals (like highlighting and transitions).

I preferred the slide up version at first, but users seemed to prefer the sideways movement so thats what we went with. The sideways transition gives the impression that you can to back and forward.

Mark: Thanks for the pointer, I'll go check out ShopQwick.

[Barbara Ballard]

Given the context that I was viewing Flash demo and movie on a computer, I found myself processing the "ticket area" as simple header info. It took me quite a while to actually parse that as something that might be useful. That would probably change over time.

With that in mind, I'm unsure as to whether the decision to reflect the highlighted item in the ticket area is a problem. I'd want to observe actual users (but you did mention a budget ...).

Now your "slide-up" interaction I think shows the ticket-building more.

An interesting problem.

[Mark]

Have you had a look at ShopQwik.com

They have a complete flight mobile booking tool for over 100 airlines which allows you to select different carriers on the for outbound and inbound on the same screen. It's been running for 3 years and works on 150+ mobile phones.