FleXyber Solutions, LLC

Opportunity Space

General aviation pilots are required to complete an immense amount of documentation when flying internationally.
The documentation for flying internationally only adds to the responsibilities of the pilot’s preflight responsibilities.

Solution

A responsive SaaS that reduces the amount of time and effort that is required by general aviation pilots to complete necessary documentation before flight.

Methods

Competitive Audit
Kano Analysis
User Survey
User Interviews
Information Architecture Diagram
Usability Tests
Personas

skills and tools

Axure RP 8
Sketch
Google Docs (Survey)
QuickTime

flight plan

FleXyber Solutions, LLC was started by Tom Chapman, a local aviation pilot who saw a need for creating software to assist pilots. He approached our team to ask us to design an application to make the process of filing an APIS (Advanced Passenger Information System). This system is required for pilots to complete prior to takeoff when flying internationally.

Information Architecture of an APIS

The first thing that our team did wanted to do, was gain a better understanding of what is required on an APIS. In order to do this, I used an XML file (the typical submission method at this time) and broke it down into an easily understandable information architecture diagram. Using this, and a competitive audit, we found that there is an enormous amount of repetitive information that must be entered on an APIS. At this point we formed a hypothesis: By creating a system that stores this repetitive data, we could reduce the amount of time and effort that was typically required to complete the document.

Step 1: XML document

Step 2: Handwritten flowchart

Final Product: Information Architecture Diagram for an APIS

GA Pilots

After completing user interviews and a survey to get to know our users better, I constructed Personas to help guide our design.

heads in the clouds

Now that our team had a better idea of the users and the problem, we began to conceptualize a system that would store previously used APIS, and allow the user to recall those documents in order to edit them to fit their upcoming flight.

I led usability testing while Ben and Simone (left) took notes.

Pivot

After conceptualizing the process of recalling a previous APIS, our team realized that this process could still be tedious for the user and allow for easy mistakes by not editing necessary fields. Instead, we decided to have the system store sets of data for high level categories. The user would then be able to select from these sets of data to populate a new document. Additionally, we would allow the user to select certain sets of data to be a ‘default’. This means that these specific sets of data would auto-populate whenever a user started a new APIS.

test flight

I led multiple rounds of usability testing with primary users and non-primary users in order to gain a better sense of effectiveness of our prototype.

Usability tests main findings and recommendations

takeoff

After making the necessary corrections that we found from usability testing, we were prepared to show our stakeholder our final product. Tom was elated with the results! Below, you can see a video walkthrough of the prototype that we were constructed. The walkthrough shows the pathway for filing a new APIS, and editing an APIS.

Meet the team

From left to right: Simone Quach Hougaard, Sean Kwon, Mitch Ryks, Ben Pollack.