Reimagining GE Aviation Customer Navigation

Project Context

Once a customer buys an aircraft engine from GE Aviation, they are granted access to various applications. Currently, users must open these applications in separate browser tabs in order to switch between them.

The Task

I was tasked with creating a way to navigate between these applications in a more efficient manner on an internal level. If we could improve this process, users would be able to log in once, and roam free among the suite of applications efficiently and securely.

I was also asked to create two versions of my solution. One version would be a "short-term", more implementable solution. The second, the "future-version" would be a more aspirational, forward-thinking solution that the design team could revisit later.
‍

Constraints

In order to establish a benchmark from a software development standpoint, I was asked to keep these solutions within the confines of Google Material Design. Since my team also wanted to present these solutions at an upcoming design review, I was given roughly 2 weeks to complete these interactive prototypes.

‍

Despite the short timeline, I knew that I had to get grounded in my research before ideating. Since there are many well established, existing navigation patterns, I decided to explore what patterns could give me inspiration through comparative research.

Comparative Research

Many tool suites have their own way of navigating between applications. The two primary tool suites that I chose to look into were Google and Microsoft due to their well known patterns and ingrained mental models.

Key Insight

• Since I didn't have a large quantity of menu items, I chose to divert from the Microsoft menu format and lean toward Google's. This would also help me to better align with Material Design specifications.

Early Ideation

To contextualize this early ideation, I will explain my primary goals that I knew had to be accomplished with this solution:

1. The "short-term" version will solely allow users to switch between apps
2. The "future-state" version will allow comprehensive search, notification, and profile integration across all applications
3. Don't try to be perfect, just get some ideas flowing

To start, I created a hamburger menu navigation style. This format would have been adequate; however, I realized that there was no need to minimize the tool's display to this degree while switching applications. Given this, I chose to pivot to a dropdown style menu:

Design System Alignment

As previously mentioned, I was under the constraints of using Google's Material Design specifications. Referring back to my second idea (shown above), I knew that there was an opportunity to explore both the "short-term" and "future-state" versions using this format.

Construction

As I built my screens, I started with the header because this would be the central UI component that would be universally carried across the apps. Using a mixture of Google Material Design specifications and inspecting Google product HTML code, I was able to create my final header.

‍

After receiving good feedback from my supervisor and making a few small edits, I jumped into creating the interactive prototypes. During my internship, I used InVision to do this; however, for the purpose of this portfolio entry I used Figma.

Versions

The "short-term", more attainable version of this navigation system has a much more basic header. The bento menu, tool name, and profile are the only pieces of functionality. This would allow users to:

• switch between applications through the bento menu
• view the tool name
• click and view their their user profile

The "future-state" version is a much more robust header with multi-app integration. This version allows users to:

• switch between applications through the bento menu
• view the tool name
• search for files, keywords, users, and other items across all applications
• submit an inquiry (a request about an engine or fleet)
• get site help
• view integrated, global notifications
• click and view their user profile

Cross-Functional Support

These concepts received great feedback from other designers on my team, product managers, and adjacent teams. Unfortunately, we were not able to test these concepts with any users during my short time working on this project.

Shown below is the "future-version" interactive demo that I was able to create and share with coworkers.

What I Learned

• not every forward-thinking idea is implementable, and creating two versions can help this dilemma
• cross-functional team support is necessary to make "out there" design leaps
• there's not always an unlimited time to deliver a futuristic concept
• Google Material Design specifications can be helpful but also a creative constraint
• something as simple as a new header and menu system can help drive a more efficient customer workday

‍

‍