work | artarticles

pixels + code + art


Product design at the scale of millions

At the forefront of flight tracking technology, FlightAware is revolutionizing the airline industry. Their pioneering “build your own” program allows anyone around the world to become a real-time flight tracker. They’ve created partnerships to put their technology in space, providing global coverage for every plane in the sky...think Waze + Google Maps for airplanes.

FlightAware has millions of daily users and provides critical infrastructure to a massive industry. I jumped at the opportunity to work with them to redesign and rebuild their iOS app. In a follow-on project I also helped them create a new, responsive design language for their website.

The app now has a 4.6 rating with over 20k reviews, up from its initial rating of 2 based on 14k reviews.


Part 1: iOS Work


Creative Brief

The ask was to redesign the iOS app, which included a general requirement to address navigation issues and to incorporate a new search feature. My first steps were to survey the current version of the app and gain a better understanding of the travel-based app landscape. I accomplished this via stakeholder interviews, code-base review, cataloging AppStore reviews, and using services like AppAnnie to perform competitive analysis. 


It’s important to understand the as-is before moving toward the to-be.

These initial research activities were critical for several reasons:

Check Stakeholder Assumptions
Seeing everything for the first time is a perfect opportunity to observe with a critical eye and ask questions to uncover motivations driving the project.  This process helps identify underlying assumptions and ensures that the expectations, outcomes, and success metrics are clearly defined. Specificity keeps everyone on the same page. Taking the time to move “upstream” from the immediate request unlocks a broader set of creative options moving forward.

Become Informed
Consultants are usually applying their skillset to new problems. The ability to quickly obtain functional knowledge in an unfamiliar domain is crucial. My “review and survey” technique is an efficient way to ramp-up with a new client. You can’t really help someone if you don’t understand their world and their language.

See the Big Picture
I wanted to catalog all of the pieces in their product design puzzle. I find it invaluable to see how a client’s existing offering aligns with their brand and roadmap, and also how it fits into the broader market. Capturing industry trends, scouring reviews across apps for user pain points, and cataloging UI and UX decisions are due-diligence tasks that ensure there are no missing puzzle pieces.

App Review
Competitive Survey



The biggest challenge facing the app was catering to FlightAware’s broad audience.

Private pilots and flight enthusiasts use the app in a very different way from commercial airline travelers. Airport and airline employees also have their own unique set of use cases. The initial research led me to recommend either targeting the app to a specific user, or creating distinct experiences for each audience group, rather than going with a one-size-fits-all approach. But the time and cost of such a solution was out-of-scope for the project.


This problem is primarily one of information design.

Private pilots and flight enthusiasts typically want as many data points on a single screen as possible. This is in direct opposition to a commercial traveller who needs an uncluttered UI with clear and salient content. We were in a constant struggle to strike a balance with information density, and the end result is that the app lends itself more to a professional user than an average traveller. But this direction is more in-line with FlightAware’s brand and strategy, and that’s what mattered the most.

Wireframe Examples

Usability Testing and Measurable Outcomes

I was able to introduce FlightAware to the benefits of usability testing out of the need to better understand the workflows of two fairly complicated features:

The prior version of the app required users to specify if they were searching by airline, flight number, airport, or route before initiating the search. OmniSearch is a new feature that allows the user to simply start typing, and matching results across all categories are returned in real-time. Upon release, we discovered this to be a fairly nuanced interaction for most users.

Analytics showed that the alert feature, which allows users to be notified of updates to their flights, was not being used as much as expected. It was considered to be a primary benefit of the app and FlightAware wanted it to be used more often. With no data to go on, there was no way of knowing what needed to be changed.

I put together a proposal that included clearly-defined hypotheses for the two features to be tested. Each hypothesis would be tested separately and by different users. Don’t overload a study with too many interactions, and only present a single task in each test. It’s important to be specific with test scenarios in order to confidently link successes and failures to a given design. 


The proposal, along with a detailed test plan that included methodology explanations, helped everyone to get on-board with an unfamiliar process whose ROI was in question.

The outcomes of the tests established a “ground truth” from which to make data-informed changes to the workflows and designs, and subsequent tweaks could now be effectively measured.


Redesigning the app was only half the work; I was also contracted to implement the new design. I transitioned FlightAware from Objective-C to Swift to gain the benefits of a more modern and maintainable codebase moving forward. There were several positive outcomes from the rewrite:

Process Improvements
I moved them from a monolithic release pattern to a continuous development cycle and established a light-weight set of QA guidelines. For a small mobile team with limited resources, these tweaks to their process made it possible to decrease bugs, and track and manage changes over time. 

View Controller Bloat
The application architecture was cleaned up by separating business logic and API calls into individual services that could be consumed by views, view controllers, and other services. When only one service is responsible for a given piece of functionality, API calls for example, there is only one place to look when a bug pops up.

Presentation Layer Consistency
I created a style service to manage presentation-related code. Centralizing font, color, and other UI-related data makes it easy to incorporate future design changes. A new data transformer service was responsible for JSON intake from the APIs, which could be wildly inconsistent based on the source. The transformer I incorporated ensured that consumers were always receiving well-defined data, formatted to their needs.

Flight Progress
Airport Activity
Alert Creation

Part 2: Web Work


Responsive Requires Flexibility

FlightAware was making plans to update their website while I was working on the iOS app. They wanted to adopt a responsive design with an updated look-and-feel. As the mobile app moved into maintenance mode, they asked me to stay on and work with their new UX team to create a design language for the site.

The UX team had already conducted a ton quality research on their existing site, down to eye-tracking studies. Their work yielded seven initial personas along with a prioritized list of features to help inform the direction of the new site design. We conducted a workshop to narrow our design focus to three primary personas and to create a timeline for wireframe and design deliverables.
The tight timeline meant I needed a fast, flexible workflow in which I could easily show break-point variations and account for new - but not final - advertising guidelines. Static design files would hamper our ability to test layout variations and iterate quickly. As an experiment, I used ResponsiveSiteDesigner to produce “living wireframes” for the project. 


It was a breeze to sit in a meeting and make updates in real-time to “What if we moved this to there?” or “Let’s throw this new ad size into the flow.” requests.

The solution worked well because I was able to directly export my work as a functional website that anyone could view in a browser on any device. An added bonus was that the engineers were able to use the breakpoint code and CSS as a reference for the final implementation. 

Narrow Breakpoint
Medium Breakpoint
Wide Breakpiont


Handing-Off for Implementation

I took a mobile-first approach for the redesign because the roll-out plan started with updating the flight detail page. The vast majority of the site’s traffic routes through this view when people initiate a Google search for flight status because the FlightAware flight detail page is the top result. Analytics indicated that most of these searches happen from a mobile device. 

Working from an information hierarchy driven by the prioritized feature matrix, primary personas, and a set of responsive wireframes, I kicked-off the visual portion of the redesign with an Initial Look exercise. 

Initial Looks
Time and budget didn’t allow for a full-fledged exploration of tone, style, mood boards, I tried to combine these steps by producing three distinct themes with single, hero screens. I had a sense that FlightAware would go with the Cloud language, as it was the direction most closely-aligned to the brand, and they did.


I intentionally pushed the design in other directions. The visual contrast can help to solidify “on-the-fence” perspectives and also broaden horizons for those who have trouble conceptualizing the possibilities of change.

With a direction chosen, it was a fairly straight-forward process to create a color palette, styles, margin rules, and layouts. Over the course of finalizing design we had to account for the column rules changing, ad placement updates, and tweaks to the social media buttons. The initial work conducted via living wireframes made these updates relatively pain-free.

Tools like Zeplin and Marvel were not options to facilitate engineering hand-off, so I created a good, old-fashioned style guide. Knowing that I wouldn’t be around during implementation to answer questions, I tried to provide the engineers with a base-line of patterns so they would have the flexibility to evolve the design language over time. 


Final Design

FlightAware is made up of some of the nicest, most genuine people I’ve come across in my career. I’m grateful I got the opportunity to work with them. The projects were massive and challenging, and the work pushed me to grow as a designer, a developer, and a person. They are always looking for good people join their team. If that’s you, check them out!

© lee brenner 2019