IMS CANS
Customer Portal

As part of the Collins Aerospace's IMS Customer Portal team, I led UX/UI vision and execution across the redesign. Complex and heavily layered, Commercial Aviation Network Services (CANS) spans a gamut of aerospace communication solutions from global air-to-ground connectivity solutions to air navigation services (10+ unique tools/applications).

Spanning 6 months, my team of 30 individuals including product, QA, tech and design scoped, re-designed, and re-engineered the front end and back end of this legacy portal. IMS CANS is used by airlines including Lufthansa, Alaska Air, Cathay Pacific and more.



This project is ongoing. Due to the sensitive nature of the aerospace industry, please contact me for more details about this project!

The Challenge:
1 of 2 customer flight communication providers in the world, Collin's was seeking to eliminate the 3% annual decrease in contract value by meeting competitor and market expectations of value and usability.

My Role And Responsibilities
Product Designer with +1 lead designer
Product Scope, Design Research, UX/UI, User Testing

Year
2020

Timeline
8 Months

Methodology
Hybrid: Design thinking + agile Dev

00 Context
RDS, and the importance of data

The operation and success of aerospace, IoT, and spaceflight rely heavily on the analysis, usage, and the communication of data. At UTC — the world's third-largest aerospace company — success relies on data at a uniquely high level. At the time, charting and visualizing data at UTC—from Carrier HVAC temperature data to Boeing 737 engine health monitoring—was disparate and inconsistent with modern-day design patterns.

Rotor Design System (RDS) is UTC’s Internal design language. Born at the Digital Accelerator, its goals and structure draw parallels from systems like Google’s Material Design, IBM’s Carbon Design System, and Apple’s Human Interface Guidelines. The first of its kind, RDS defines design best practices for complex aerospace and manufacturing applications. Rotor Charts is a sub-design system that currently lives within the broader Roter DS.

01 What's the story?
Setting the narrative and architecture

ABOVE: Storyline: building a chart

Our first priorities were: Alignment with the design and product leads within the Rotor Charts Team and research on similar design systems (IA, dev/design assets, etc.) and their driving factors behind their success. We initially aligned the contents around our toolkit and the structure it followed around the question "What story are you—the designer—trying to tell?" We used this as an anchoring framework to begin our exploration and documentation.

A parallel first step was understanding Rotor Chart’s place within the broader Rotor Design System. Since Rotor Charts would ultimately live within Rotor Design System, we aligned early with the RDS design leads on initial information architecture, nomenclature, visual style, and sketch design standards. This was a continuous relationship, and as my team’s understanding of Rotor Charts grew, so did the fidelity of our integration with Rotor Design System.

ABOVE Integration with Rotor Design System

02 User Research and modularity
Flexibility and adaptability first

With scope focused on a deployable Designer Toolkit, we turned to our in house designers to align nomenclature, build logic, and prioritized needs. Through many rounds of user research and testing, we landed on a prioritized list of chart types, understandable nomenclature, build logic for the components in our toolkit, and a ranked list of designer needs when building charts in the aerospace industry. Flexibility and needing the "full kitchen pantry" were the highest needs of UTC designers, due to the enormous amount of variability in projects, products, and use cases.

ABOVE Designers need a high level of flexibility and "all the lego bricks"

We iterated vastly on breaking apart the "pieces" of a chart, and worked through round of user testing to better align our "lego box" to the mindsets of our designers. Key pieces include titles, titles with controls, subtitles, keys, x and y axis labels. We also included various kinds of chart types to plug and play that could sit on any background or grid.

03 The Delivered Toolkit
Plug and play

Flexibility and needing the "full kitchen pantry" in Sketch were the highest needs of UTC designers. Due to the enormous amount of variability in projects, products, and use cases, Rotor Charts utilized the modular nature of Sketch symbols substantially, and helped inform a modular, component based design system at multiple dimensions. With every chart 'piece' designed into modules and scalable sketch components, designers could plug and play, and within minutes, could build a fully stretchable chart for use across digital applications.

03 Documentation and deliverable
Instructions Not included

We included a robust instructional PDF outlining all the various abilities of the Rotor Charts Toolkit. I owned the general guidelines, and outlined just how a designer would use our toolkit. In this manual, we included color guidelines around accessibility. The accompanying color pallette and accessibility guidelines were led and executed by fellow designer Daniil Ashtaev

We painstakingly built scalability and flexibility into each symbol layer and component. We deployed over 50 individual sketch chart modules across 40 sketch pages. These assets could scale, stretch, and switch between dark and light mode. We also included pre-built charts for use during quick mockups and concept explorations.

ABOVE A glimpse of the accompanying guidelines for rotor charts

ABOVE Dark mode sketch sticker sheet

04 In The Wild
Digital Accelerator Entry

Currently deployed in UTC's Digital Accelerator, one public example of Rotor Charts in useas a flight monitoring dashboard for large format applications. Using non-technical data, we display a collection of flights from historical databases in the lobby of 55 Water St. Brooklyn, NY.

Contact —
jeremylu.design@gmail.com

Connect —
LinkedIn / Medium

Designed by —
© 2020 -  Jeremy y. Lu