The goal of this semester-long project was to facilitate or improve a long-distance relationship. Aviate was created with my grandparents in mind; they live in China but enjoy spending time with my immediate family in the US. Due to physical limitations and barriers in communication, traveling to a foreign country can be difficult and even stressful. To minimize frustration, Aviate was designed.
Users are able to input their flight information into the app, which then maps out a route based on location and ultimate destination. They are also able to book or reserve transportation assistance, such as a wheelchair or shuttle, if needed.
University of North Texas
Foundations & Frameworks of Interaction Design
IDENTIFYING THE CHALLENGES AND GOALS
The overall goal was to improve our relationship and increase the quality of their lives. Two main categories have been taken into consideration: age and airport navigation. Language is also a category but its importance is linked to navigation. Age relates to physical capabilities such as, decreasing autonomy and visual changes. The issue of navigating airports is a challenge on its own, despite age. This issue has several parts: 1. Airports are difficult to navigate, 2. difficulty finding help or assistance in a foreign country, and 3. Long lines. For some people, trying to maneuver through airports can be a stressful experience. How to get from point a to point b is not always intuitive and the layout of airports across different cities and countries vary.
Traveling should still be an enriching experience despite age.
Apps should be easy to navigate and use.
Minimize the need to ask for assistance.
Decreasing autonomy and the possibility of depression.
Similar phone applications were analyzed (seven, to be exact) for their successes and failures, specifically, what Aviate could improve upon or take inspiration from. A common issue among all apps were their maps and navigation capabilities - maps were not detailed enough, the link took them to an external app (Google maps), and stops/destinations were not informative, just to name a few.
Some highlighted capabilities were access to maps offline, 'quick menus' that enabled users to quickly find some common destinations (e.g. bathrooms), and add stops along their route.
SCENARIO-OF-USE AND STORYBOARDING
S.O.U.s were limited to 3-5 scenarios - any more than that could compromise the main focus of the project. The goal was to eventually focus on 2 main issues and with the limited time of one school semester (3 months), it was imperative that we not distract ourselves with too many options.
S.O.Us: Wrote our possible scenarios that the user may encounter.
Storyboard: Created scenarios where the user is utilizing the product. 'How can it go wrong?' Scenes were added on as extensions of the previous storyboard.
This activity was particularly helpful in envisioning any difficulties my users may encounter during their trek AND while using the app. I gained a couple of valuable insights: (1) notifications can be disabled by the user making some features or services less useful and (2) the application needs to be user-friendly for both my target user and tangential users (airport personnel).
UNDERSTANDING THE SCENARIO OF USE
The first round of sketches began the search for the solution. 40 sketches were made that related to airport travel. This exercise enabled the identification of early design ideas, areas for further exploration, and traveling activities that may have been forgotten if sketching was excluded from the process.
When there was a mental block, sketches were rearranged by similarities to look for additional patterns - this also contributed to the initial stages of scenarios-of-use.
Additionally, I would consult friends and family about their traveling experiences when my tunnel vision hindered me. For example, a friend who is a frequent traveler told me to think about not only what the user goes through while at the airport but also include what they do to prepare for a trip.
WIREFRAMES AND LO-FI PROTOTYPES
Prior to creating any prototypes, I made a quick, rough wireframe of the main pages I wanted to include. This process enabled me to organize my thoughts and align the functionality with my personas' goals.
The low-fidelity prototype had two version; the first was paper and the second was conducted through Sketch. The paper prototype helped with imagining the flow and progression of screens along with some of the features, but I found it difficult to conduct for this specific project. There were lots of little pieces that I had to place and remove, and the map and virtual map features were difficult to convey. With Sketch, I was able to create a more viable product but still had difficulty since it lacked the capability to auto-animate. Sketch enabled me to organize screens by creating pages that sectioned them off but the inability to view screens without the lines connecting them all proved to be overwhelming.
The next 4 iterations were carried out on Adobe XD. This program has the capability to convey certain functions that no other method or program was able to. When it came to user testing, it was much easier to place on my phone so users could get a more accurate feel of the app, which was difficult with Sketch. Unfortunately, there was not a way to organize the screens in pages, rather, I had to group them in areas in one screen. This had both pros and cons as I could view all the screens at once but it was tedious and frustrating having to reorganize constantly.
Due to prototyping tool limitations or lack of time, certain features could not be implemented. The map is supposed to provide haptic elements - such as, phone vibrates and dings when there is a new set of directions or when new suggestions in the 'coming up...' tab are added - that the prototyping tool was unable to include.
As noted on the menu, there seems to be a medical profile function, but it is not clickable. This function would have allowed users to upload information about their medications and surgeries; they could take a picture of their prescriptions, have all the necessary information, and depict any metal prosthetics that could cause the security detectors to go off. The goal was to take away the stress of going through airport security, including the need to have an extensive conversation with foreign airport personnel. Unfortunately, time was limited and this function would require
possibly another month or two to complete.
The initial idea was to include a translation feature that enabled users to communicate with airport personnel in foreign countries. The goal was to mitigate any stress or issues that the user may face in a moment they needed to talk to someone. For example, if their flight was cancelled or delayed and consulting an airport personnel became essential, this function would be helpful in doing so in a foreign country. After brainstorming with my classmates and participants, I came to the conclusion that there are plenty of apps and programs that would do this better and ultimately, it did not make it to the low-fidelity designs.
The design of the overall aesthetic and readability was geared towards older people who have difficulty hearing, reading, and navigating apps. The blue theme was important as it is a calming color and during stressful times, this choice seemed better than vibrant and alerting colors such as orange and red. In addition, I kept in mind the size and font of the text and designed many of the boxes and panels around a 16-point sans serif font. Anything smaller than that and any serif fonts could prove difficult to read for older users. Additionally, contrast was taken into consideration; as we age, our ability to differentiate between colors becomes more difficult.
For reserving transportation, that quickly became an overwhelming feature where functions were being added every week. It first started as a simple reservation function, then the user had the capability of adding stops to their journey, which led to the idea of an Uber inspired shuttle service that would be an app of its own.
Eventually, it was simplified to be the final version it is today. There were moments where I considered deleting it but remembered the initial importance of it: to help users maintain independence and avoid confrontation. The reasoning behind this function: Those who physically struggle with walking long distances or standing in lines for long periods of time are relieved of the pain and stress associated with their limited mobility. Additionally, travelers who need assistance have to call the airports ahead of time or ask for assistance in obtaining transportation once they land. By providing this option in the app, the user is able to maintain some independence by controlling the situation and avoid the need to speak to someone in a foreign place. Ultimately, it is meant to minimize any amount of stress.
The maps also went through several design changes. The first was the quick menu; the design was originally a quick search of necessary destinations or stops. Users would select a stop and it would indicate the closest one by highlighting and blinking the icon on the map. This was later changed, along with the icon, when the ‘search along route’ function was included. The icon changed from a ‘search’ icon, to three dots, and back to the ‘search’ icon to indicate that the user could add a stop along their route. Once selected, the icon on the map would blink and the stop would be added to the directions panel along with its distance from the user’s current location. The position of the ‘coming up…’ tab was also moved from the directions panel into its own tab on the left side of the map. When placed in the directions panel, some users had difficulty understanding its purpose and there were limitations to how many stops could be shown at once. By moving this section into its own tab, there was room for the ‘search along route’ function, more than two stops could be shown, and the user had the ability to control when they wanted to see.