This is the case study of Flyright. To visit the completed web app, click here.
Complete Flyright concept
The Flyright concept

Riding through the Gobi desert in Xinjiang, the westernmost province of China, a conversation inspired us to build Flyright, a concise travel preparation app. This case study will discuss the process of designing and developing Flyright in the following sections (click to skip to a section):

Discovering the problem

The idea to build something in the travel space came unsurprisingly while we were traveling. Originally on a research trip to study the production of wind and solar energy in China’s western hinterlands, we were stopped by dozens of security checkpoints throughout the area. Those of us unused to this experience complained about the interruptions, but one of our group, from Trinidad & Tobago, was unsurprised. Trouble traveling was the norm for her.

The Gobi Desert
The Gobi Desert

From my experience living in Beijing with a small cohort of world travelers, I saw and heard just how inconvenient traveling can be for other passport holders: whether it be a Vietnamese friend mistreated by foreign embassies, or a Chinese friend searching the internet for hours to find the right travel information. They encountered many issues whenever they went somewhere, the most frustrating being an inability to find the right travel information from their government.

The problem
The problem

These experiences inspired me to redesign the experience of travel from first principles. While most travel-related technology companies focus on where they perceive the money to be, selling airplane and accommodation tickets, none addressed the difficult process we all go through in preparing to travel. Visas, travel warnings, vaccinations, currency restrictions, embassy locations and contacts - the list of things to figure out before you fly is long and difficult to access. With Flyright, my goal was to craft a design solution to completely refactor the way we plan travel.

Our solution
Our solution

Initial research

The idea sparked, we set out to conduct research and tease out hypotheses to test. We started by mapping user journeys. Take the persona of a U.S. passport holder flying to India. Our user starts with a Google search, returning a long list of options: the Department of State’s travel page, the country fact sheet page, a consular notification and access page, a page for consulates and embassies in India, and many more. Assuming a first-time traveler could guess which page held the information he or she needed, there remained no source to verify the accuracy or currency of it. Moreover, the page designs were difficult to navigate and draw meaning from, further complicating the process. At this point we saw that while the U.S.’ system left much to be improved on, it was at least consistent in using the State Department Travel site as the root to which all other sites were linked.

US information architecture
US information architecture

Next we conducted interviews with travelers from different countries to see if the system was similar. Passport holders from China, Trinidad & Tobago, Singapore and others revealed that travel prep for U.S. passport holders was actually among the most accessible. The U.S. State Department has one large website as the source of truth for travel information, while many other nations have hundreds of separate sites each managed by individual embassies. This distributed model proved extremely difficult to search and verify information because of the widely differing site management approaches by each embassy. Given this disparity, we saw an opportunity to level the playing field and improve access for everyone.

China information architecture
China information architecture

Design process

With a better grasp of our target users and the problem we sought to solve, my partner and I started the design process from our respective domains - he from backend architecture, and myself from the frontend. We sketched out our ideas together and came to a base understanding of our product, end-to-end.

Initial sketches
Initial sketches

The paramount challenge of Flyright was one of design. How can we take inherently boring and inaccessible information and make it fun and accessible? If I crafted a user experience only marginally better than the current one, our value as a service would be diminished. It needed to be much simpler, faster and more enjoyable. In order to achieve this, I found a way to simultaneously condense communication and evoke delight: emoji.

EmojiOne emoji used in Flyright
EmojiOne emoji used in Flyright

After I found an emoji SVG library that would render consistently across all devices, I had to figure out how to use the emoji to the greatest effect. In addition, the information needed to be portable to encourage sharing as our community grew. I’d seen major information providers like Google and Vox implement a card-based UI to varying degrees of success, but thought that the experience was limited by their inability to share on a card-by-card basis. If we could iterate on this model by adding an export option for each “Trip Card”, it might enable rapid sharing akin to the way links, pictures, videos and other media travel between users.

Lo-fi Trip Card sketch
Lo-fi Trip Card sketch

The concept was slowly coming to life. As I moulded the Trip Card concept further, another key value of the form factor became clear. From my experience with responsive design and web development in past projects, I knew first-hand the value of a design well suited for devices of all shapes, sizes, pixel densities and operating systems. Trip Cards could serve as our universal UI for Android, iOS and the web while still achieving native-like feel. In designing mobile-first, I was able to save time and energy on the initial mocks and craft a better design system for our expanding cross-platform product.

Flyright mobile mock
Flyright mobile mock

Our goal of supporting multiple platforms with the initial launch of Flyright was ambitious, and it required some medium to act as the central node for all of our apps. I needed to anticipate how our users would discover Flyright and what they might do once they did. How would they know what platforms we exist on? How would we introduce Flyright to users and communicate our mobile-first approach? First impressions are everything. I decided that a landing page could serve both purposes well if designed clearly.

Lo-fi landing page
Lo-fi landing page

The landing page layout complete, I fleshed it out responsively with higher fidelity mockups in Sketch.

Hi-fi mobile landing page
Hi-fi mobile landing page
Hi-fi tablet landing page
Hi-fi tablet landing page
Hi-fi desktop landing page
Hi-fi desktop landing page

Frontend development process

Although I am primarily a product designer, I place high value on knowing how to build what I design. For Flyright, I learned to develop with the popular frontend Javascript framework React and its sibling, React Native. These environments leveraged my web development experience to the fullest given its deliberate use of web-based languages like JSX, CSS and Javascript. Further, React’s “Learn once, write anywhere” philosophy gave me the opportunity to develop a lean web app and real, native Android and iOS apps using the same principles.

React lifecycles
React lifecycles

Detailing the entire development process is beyond the scope of this case, but I thought it appropriate to include code snippets of three key functions closely related to the design process: React lifecycles (above), text input and page transition animations (below). As the sole designer and front-end developer of Flyright, I found that having a detailed understanding of both ends of the product gave me deep insight into the complete experience of the app. However, this perspective came with a trade-off, as the longer I spent in the internals of the app, the more difficult it became to step back and view the bigger picture with fresh eyes.

React Native text input
React Native text input
React animations
React animations

Preparing for launch

After two months of developing and redeveloping the Flyright frontend, the apps were finally production ready. Despite delaying our Android launch due to ABI differentiation issues in the Android ecosystem, we were ready to release our iOS and web app the public. However, we learned quickly that there is still a long list of things to do in the time between the last line of code and shipping the app. I had to design artwork for display tailored to each app store, build the About, Contact, FAQ and other informational components, and wire workflows for user feedback and debugging when we encounter issues post-launch.

Play Store artwork
Play Store artwork
App Store Mock 1
App Store Mock 2
App Store Mock 3
App Store artwork

Shipping Flyright

The moment of truth arrived and we shipped Flyright on October 25th, 2017. We planned no extensive social media campaign or fanfare and instead just shared it with our networks. A few days later I added Flyright to Product Hunt, and on October 28th we were the #1 Product of the Day on their platform! It was beyond exciting to see our email inbox, Twitter feeds and PH page flood with positive feedback and requests for passport support. Perhaps most exciting of all was seeing the http requests on the Flyright web app climb per day - people were using what we spent so much time and energy building!

Product Hunt App of the Day!
Product Hunt App of the Day!
Snapshot of recent http requests for Flyright
Recent http requests for Flyright
Snapshot of recent App Store downloads of Flyright
Recent App Store downloads of Flyright

Where we are now

Although Flyright’s initial usage hasn’t been meteoric, we’ve seen a slow and steady increase in http requests, App Store downloads and feedback from our early users. The task of designing and developing Flyright from its inception was a mammoth task, but it was incredibly rewarding to see something we built being used and shared so freely.

As of the time of this writing, my partner and I have created a pitch deck and are focused on finding the right investor to take our project to the next level. We have big plans, and I can’t wait to see what the future holds for us.

As for me personally, I will be stepping away from the project to move to Singapore and find work in product design. In the interim, my partner will continue to grow our community and move the business side of our endeavor forward in the Bay Area. I am extremely proud of the work we have accomplished so far, and looking forward to building on what I’ve learned from this experience at a full-time position in Singapore.

If you made it this far, thank you so much for your support and please do reach out to me on LinkedIn. I would love to meet up or explore how we might work together!