Flight Booking Concept: Step by Step Process

While mocking up the concepts for this flight booking system I was contemplating 2 different ways of presenting the same journey to the user. Naturally questions came up including which one seemed easiest to understand? Which one involved less steps for the user? Which one looked nicer? The best option to test these ideas was to create them both and use them on their native devices to get a feel for sizings and structure.

Creating concepts like these is great for visualising what works or doesn’t, but the real value comes in user testing and iteration from the feedback. As this task is only concept exploration I haven’t put this in front of any possible users, but please note that is a vital step that would be taken if this was being created as a real product.

I talked through my initial concept in my previous blog post, if you haven’t read that yet you can find it here:

https://medium.com/@mhaley/flight-booking-concept-design-bb8d4c163259

Concept Journey

This concept is focused on a more step by step user flow. Doing this makes each section clearer and allows the user not to be overwhelmed by busy screens and long forms to fill in before being able to continue.
Working with the same input fields as I had in the previous concept, the flow goes as follows:

1. User enters where they are travelling from.
2. User enters where they are travelling to.
3. User selects how many passengers are travelling.
4. User selects if they need a return flight.
5. User selects the dates they intend to travel.
6. User reviews selections before continuing with the next stage of the booking process.

This type of flow where the focus is on one question at a time is particularly common on mobiles and tablets to avoid cramming lots of input fields onto a device with a typically smaller screen.

Storytelling

With the extra space available here I have chosen to add to the description text to aim for more engaging and casual questions. This method connects with the user on a more personal level rather than asking the bare minimum to get by. It also allows for a greater understanding of the questions being asked. For example, ‘Passengers’ can be changed to ‘How many passengers are travelling?’, and ‘Destination’ to ‘Where would you like to go?’ A more descriptive and personable title is great if possible.

I decided to display all previously given data so that the user could see the selections they had made. This is displayed at the top in bullet points, keeping everything visible.

It’s also important that this information should be editable at any point so the user wouldn’t have to start the process again if they got something wrong and wanted to change a previous selection.

It’s worth noting in my concept I only allow a standard passenger to be included, whereas in reality there will be many passenger types such as children or concessions. The ability to select the type of ticket would need to be explored and added into the passenger selection screen.

In my previous concept I linked the return flight check box and the date select containers together. However in this version I have presented each option on separate screens as the step by step nature of this flow allows the user to progress to the correct date selector screen after they have chosen if the return flight is necessary.

The next question for me here was how should I display the return flight button? The decision was a between a toggle switch, Yes/No buttons or a checkbox like in the previous example.

The decision went the way of the Yes/No buttons as it gave the clearest visual of both choices, and as space wasn’t a worry I didn’t feel the need to use the smaller checkbox.

The user is then asked to enter their dates of travel before overviewing their selections. The screen I have included at the end of this journey may be a good addition to my previous design to give a final review before continuing.

These screens only capture a small section of the whole booking process. Going past this stage and choosing the flight itself will provide a more complex journey, which is what I intend to have a go at next.

Stay tuned for more interface experiments and if you have any suggestions of something you’d like me to look into, let me know!

Booking flights is a notoriously stressful activity, filled with hidden costs, countless add-ons and ever changing prices. I can’t do anything about the prices unfortunately, but a focus on the interface design can definitely make the experience a lot smoother. I’ve been working on some concepts for the booking process and it turns out, with a bit of attention to detail, it’s relatively simple. Or so it should be…

Applying interface design techniques correctly such as visual hierarchy allows the user to quickly see the key information on the screen. Too often major details like additional charges are hidden away in small print or quite simply have not been made obvious enough that they become overlooked, leaving the customer confused as to why their price has just increased.

In my example, I have made the important details in bold and deliberately increased the size of the text so that when glancing over the screen a user can take in all they need to know while not being interrupted by the unimportant data.

Similarly, comes the importance of the highlight colour which can be used for multiple things. One use is general branding and adding a theme of colour to the interface, or from a more interactive point of view they can be used to indicate what on the screen is interactive.

The ‘Edit’ icon in the ’Choose Airport’ section is highlighted showing that it can be selected to change the departure or destination location. Often these whole rows can be clicked anywhere to edit the text but having a noticeably interactive element in the container gives necessary confirmation and doesn’t leave the user guessing.

In the select number of passengers section, the ‘Plus’ icon is highlighted whereas the minus is greyed out. This is due to the number of passengers being at 1, the lowest possible option. However selecting the highlighted plus would take the count to 2 passengers and therefore the minus would become available.

Lower down the screen the circular highlight surrounding the 23rd text shows the date that has been highlighted, and the large search button at the bottom of the screen is the primary action button that takes the user to the next part of the flight booking process. All of these highlight colours have been used with reason, and it may confuse the users to randomly make headers and text this same colour if they are not also interactive.

Visual hierarchy also comes in the form of placement. The user will typically read from top to bottom, which means the flow must be worked out in order to determine the order of content on the screen.

Groupings also indicate which sections are linked and affect one another. For example, the return flight container in my concept is overlapping the date picker. This is because a user choosing to have a return flight will change the content beneath it, in this case they will have to pick a secondary date that the journey will be on. Placing this container elsewhere wouldn’t necessarily be wrong, but as much help has to be given to the user in understanding what they are reading on screen.

There are several layouts that allow the process of booking flights to be simplified and there is definitely not only one that is correct. The reason I settled on this particular structure is because it allows the user to review all the key information on screen at once before continuing to the next stage. Other layouts take this process screen by screen which allow more focus on each individual section, but don’t give as great an overview of all their selections at once.

With the introduction of more and more self service kiosks appearing into high street shops and supermarkets, I’ve been looking into how they are being used and why they often fall short of our expectations. The user journeys on these POS (Point of Sale) systems are more or less the same with the user making one or more selections, adding them to a basket, reviewing the order and finally completing a payment.

I have focused on these specific interactions in isolation and created some concepts of my own in order to become more familiar with the design thinking that comes along with a large touch screen interface. The aim of this post is not to find and choose the best design solutions for these Kiosks, but to explore the possible options available and bring to attention some of the things that must be considered before finalising a product design.

This post will focus on a customer reviewing their chosen order before proceeding to payment:

The main component on this screen is the order itself. At this stage the user’s main focus is on verifying that the selections on screen match what they want to order. Following this are the Call to action buttons: ‘Back’, ‘Proceed to payment’ and ‘Cancel order’. It is important to allow the user to stop at any point in the ordering process and delete all session information. The positioning of these buttons were something that caught my attention as they seemed to require a bit more thought than it originally seemed.

To me the obvious choice would be to anchor the CTA buttons to the bottom of the screen (with the exception of ‘Back’ which is logically positioned in the top left), allowing for maximum screen to be available for the main content to be viewed.

However in this particular screen there may not actually be that much content to display. If the user orders what Is considered an average order, it leaves a large section of white space between the order and the buttons at the bottom of the screen. Filling this section with pictures or adverts may seem like a good idea, but at this point the user has already made their selections and the goal is to pay and receive the order as quickly as possible. The problem with adding content in this space is that it may cause a discontinuation from the eye travelling between the order and the ‘Proceed to checkout’ button.

A way around this problem is to move the CTA’s up to just below the order, making it obvious the two are connected, and place the focused content together on the screen.

However, this solution brings in its own problems. If the user starts deleting items from their order the list will shrink, and therefore the buttons that are now sitting directly below this list will start to move position with very item that is deleted.

This may be an irregular occurrence, but is still something that has to be thought through. This may also go against the positioning of ‘Continue’ buttons previously used in the kiosk design. Consistency has to be maintained.

Another element on screen that I was uncertain about how to display was the ‘Remove from order’ button. The choice between iconography and text is always tricky and there are definitely pros and cons for either choice.

Option 1 leaves the icon with no description of function. It’s a good space saver but only if the user understands what will happen if they select the icon. It also has to be taken into account that hover states aren’t available on touch screen devices and everything has to be made as simple and easy to understand as possible.

Option 2 changes out the icon for a text description, in this case ‘Remove’ or ‘Remove from order’. The shorter the text field the better, but again the user can’t be left guessing.

A combination of both gives us Option 3 which displays both the icon and text but at the same time takes up more space and potentially makes the interface look a little clunky.

In my opinion, if the icon is well recognised it would be the best fit. This is a great example of something user testing would make very clear what people do or don’t understand.

A seemingly simple interaction can provide several sticking points and if not thought carefully about it can result in the user being unclear of what to do or leave them underwhelmed or not be able to complete their order.

In my next post I will focus on selecting a payment method and carrying out a transaction.

The space industry is full of projects, ideas and challenges that a lot of us may not have heard much about. Projects vary, and many aim to help those in need by using satellite imagery. These projects are funded by Space Agencies across the world, where data captured from space is being collected and used to help our environmental issues such as deforestation or pollution. There are many ways for young tech companies to provide value to others in such a comparatively unknown industry.

For the past year and a half I have been working as a design consultant through partnership in a small software company that develops web applications to allow users to easily consume their chosen data sets. My role was to help build digital products and design them in a way that provides the user value that they didn’t previously have. I’ve chosen to write down a few of the key insights I have taken from my time working within the space industry, which highlight the challenges and pitfalls associated with both a niche industry and being accountable to large external funding agencies:

Working in such an environment allows your creative mind to be opened to tackling new problems and overcome different barriers that may not be present in the world of say finance, or web design in general. Everything is new, and therefore incredibly rewarding from the creative point of view as each obstacle that was designed around came from new ideas and concepts. Inspiration of course was taken, but previous knowledge of how to tackle the issues we faced wasn’t there, making the work both exciting and engaging.

Another aspect to these projects was the focus on data visualisation. Just as ‘content first’ is the staple rule of design, the same applied here to the data being displayed. The challenge here was to balance an interface that allows users to consume data in the way they need, but also build the app to keep loading times to a minimum in order to make the product both usable and effective. A seemingly solid concept in practice may fall short of making it to production due to how we were processing and displaying data. Working alongside the development team to find solutions to these types of issue was a key factor in creating a quality product.

When developing a product, often the organisation funding the project are the ones you are building it for. In relation to the work that I have been involved in over the last year and a half, this has not been the case. Which definitely caused a few complications as a result. Large funding organisations often help the delivery of projects in order to provide aid to those in need. Due to this however, the internal processes and timelines for expected delivery, which are often present in large corporations, didn’t quite match up with how the agile software development was running in this project. This meant occasionally pushing features to production that weren’t ready or skipping greatly important research phases in order to meet deadlines. This led to more work by discovering bugs much later on, or simply choosing the wrong element to perform an action which would need rewritten. This proved tricky to balance.

Working in the space industry was without a doubt a rewarding challenge, one that came with its own complications as you would expect any working environment to have. The opportunity to design around different content types allows for unique products to be created, and new ideas to be developed. Definitely invaluable experience that forces design to look for new and creative solutions.

In reflection, these challenges are present right now, at the very beginning of such a niche industry which we all know is destined to become so much more. For instance, looking at the progress being made by both SpaceX and Blue Origin, the design challenges and best practices will need to progress just as fast. It will be intriguing to follow this progress, see more experience based posts come around, and learn from others as to what those best practices may need to be.