GateKeeper is a mobile app which has a subset of the boarding capabilities of the GoNow departure control system. The intent of GateKeeper is to provide gate agents an alternate means of boarding passengers during busy periods or when there are technical issues with the boarding gate readers.

Problem:

To facilitate quicker boarding times when a flight has short turn around due to delays or other issues, gate agents need an alternate method to quickly get folks on the flight. Another issue is that the boarding gate readers may be having technical difficulties and the gate agent needs a way to get people on the plane to keep everything on schedule.

Role:

My role on this project was to work with product management and development to define the scope, create task flows for basic boarding features, and take care of interaction design and visual design. I also acted as the facilitator for a mini design sprint and conducted user research.

Solution:

Conduct a mini design sprint to determine the scope of the app, create user flows, low fidelity prototypes, hi fidelity designs and a testable prototype. By the end of the sprint have design specifications and design assets for development.

Users and Audience

GateKeeper is squarely aimed at airport agents that work at the boarding gate. Due to time constraints for this project we decided to use the GoNow user personas to aid in design decisions and discussions.

Figure 1 – GoNow Personas

Scope and Constraints

The features of the product were limited and constrained to the most basic boarding scenario. It would allow boarding of passengers that met all the boarding requirements (e.g. has a seat assignment, no payments due). Time was also a big constraint for this project. A working demo was needed within several weeks to demo at an upcoming customer conference.

Sprinting Towards a Design

Due to the short time frame product management, development and UX decided to conduct a mini design sprint with the end goal of having a high-fidelity prototype that development could use as a design specification while building the app. We decided on meeting for half a day three days of the work week:

  • Monday – Figure out what features to include to have a viable app. Map the features to a flow.
  • Tuesday – Create low fidelity designs based on the flow. Create high-fidelity design based on the low-fidelity design.
  • Thursday – Review and tweak the high-fidelity design, create a prototype for user testing. Get some user feedback.

To Include or Not to Include

Two hours on Monday:  In full version of GoNow there are many things you can do during boarding (e.g change seat assignments, upgrade/downgrade cabins of service, view boarding history). We listed all the stuff that can be done, and each team member ranked them in order importance. We compared the lists that were generated and selected the top contenders and eliminated the items at the bottom of the list. We continued with this same process until a manageable number remained. We ended up with following items:

  • Load Flight
  • Boarding History
  • Manifest Overview
  • Scan Bar Code
  • Display Boarding Success/Failure

Go With the Flow

The second half of Monday was spent by having each person map at least two different flows for moving through the boarding process. Each of these flows was then discussed and voted on. We iterated through this exercise until a single flow remained. Made for some lively discussions!

Figure 2: Example GateKeeper flows.

Low Fidelity Designs

The first of half Tuesday was spent sketching low fidelity designs based on the flow from the previous day. Each team member sketched a few ideas. These ideas were then discussed and eliminated until only one remained.

Figure 3: Low fidelity sketch of Gatekeeper

High Fidelity Designs

The second half of Tuesday was spent making the hi-fidelity mockups with Sketch. We decided to use our standard colors and fonts for the app. I was able to create the mockups quite quickly as it was all of components existed in our Sketch libraries. We discussed the designs in real time and made tweaks based on suggestions from the team members.

Figure 4: High fidelity GateKeeper designs.

For about an hour on Thursday we reviewed final designs made several changes and built an InVision prototype. The rest of the day spent gathering user feedback on the prototype.  We ran some informal usability testing with five people. Based on feedback from the usability test, we changed the flow so that the Manifest Overview screen was shown after loading a flight and rearranged content on the history screen to make it more readable.

Outcomes and Lessons

  • Design specifications and assets were ready to go for development after the sprint
  • Development was able to begin the Monday after the design sprint
  • The app was completed in time for demonstration at the customer conference
  • Feedback from customers indicated that they would want a more robust solution that contained additional boarding functions