Methods Used

Comparative Analysis
User Interviews
Stakeholder Interviews
Personas
Flow Diagramming
Annotated Wireframes
Interactive Prototyping
Usability Testing

Tech Used

Axure RP 8
Sketch
Adobe Illustrator

FleXyber App Team
FleXyber App Team Presentation

FleXyber Solutions, LLC.: Simplifying a Complex Filing Process

This case study’s focus was to design a program for helping general aviation pilots file documents when crossing international borders. Working on a team of four, we addressed the opportunity space and developed a program to solve the problems of filing an APIS document internationally.

Identified Goals

The Client
Tom Chapman and FleXyber Solutions, LLC. approached our team to create this program after identifying the problem space.

The Problem Space
Our client identified that pilots were choosing not to travel internationally (specifically to Mexico and Canada from the US) due to the complicated nature of filing documents.

One of the most complicated forms to file is an APIS (Advance Passenger Information System) document. An APIS is a data heavy document that is required by a country’s Customs and Border Control agency every time a pilot crosses an international border. The document contains information about the pilot, the passengers, the crew, the aircraft, arrival location, departure location, arrival time, and departure time. APIS documents must be filed to the Outbound country as well as the Inbound country which means for a round trip, the document must be manually filled out 4 times. Some countries, like Mexico, require the APIS to be filed twice, increasing that to 6 documents that need to be filed.

Challenges

When we began, the problem space was identified but we wanted to do a deep dive into the competitors. After conducting user interviews and a competitive analysis, we had a pivot and realized that the idea to use a previously filed APIS could be a series of categories and databases that pre-populated the document since there were only a few categories that would be necessary.

Developing the Interface

We then set out to build the interface by breaking down the document into its categories and components. One team member created the information architecture flow chart while I and another member began working on the interface design. After several iterations and reviews, we landed on a simple design utilizing the categories: Aircraft (including Owner), Operator, Manifest (including Passengers and Crew), and Departure and Arrival Information for each leg of the trip.

Conclusion

After developing this interface we did some usability testing and identified some key pain points that the user might come across. We adjusted the design to allow for those inconsistencies. In addition we implemented the feature to edit current APIS documents as the system would file them automatically upon the necessary time. The APIS documents would be saved locally in order to allow for the editing but then upon reaching the deadline, information would be pulled and sent to the corresponding countries.

By eliminating the manual filing and repetitive actions, the users stress can be alleviated and with auto submission the user won’t have to worry about the documents reaching the correct place on time.