.svg)
In the summer of 2019, I interned as a UX designer at Honeywell's HUE studio. There, I helped design new data visualization components for the HCUI (Honeywell Core User Interface) design system. Being in this environment allowed me to better understand the experience of designing within a large corporation while growing my skills as a designer, researcher, and effective communicator.
The team I worked on was Honeywell Core User Interface (HCUI). This team was responsible for creating and maintaining high-quality UX components in the company design kit, which is used internally to create mockups and prototypes in the Honeywell branding style. This situation was unique because we were designing for other UX designers in the company rather than working on a consumer-facing product. The team also worked to enforce best UX practices through specifications laid out in the documentation.
Much of my design work centered on components used to show data visualization in dashboards. These dashboards were usually demonstrated as information-dense monitoring tools used by warehouse managers to diagnose and prevent operational errors. Above all, the data visualization components needed to easily customizable for other designers. To lay the foundation for my later work, I started by creating some broad design requirements:
When I started laying out these requirements, I had to familiarize myself with the myriad internal use cases. Honeywell is an international company, so there are many. To get a sense for the standards being set by big data viz companies, I collected examples from Zoho Analytics, Tableau, IBM Watson Analytics, and others.
As shown above, a critical issue was information overload in dashboards that displayed large amounts of data. This challenge relates to one of the foundational design requirements that I derived: components must take up as little space as possible while still being understandable. Such requirements provided guidelines for my later design work.
When I arrived in June, the data viz components in the design kit were sparse and difficult to use. They had been quickly designed months before to meet the needs of designers working with dashboard technologies; up until now it had not been a priority to improve them.
Much like a software engineer who writes code, creating design assets involves pushing them to their limits and attempting to break them by rescaling, grouping, and other actions. The challenge of rebuilding these components was to make them as flexible as possible so that all company designers could use them in their UI. However, it was also important to build in restraints that reinforced Honeywell’s design language. That way, designers could focus on intuitiveness for users without needing to constantly check if they were adhering to brand guidelines.
Having built the foundation for data viz UI components, I moved on to the next major component: a chart legend. From looking at examples from other firms, I discovered that the foundational purpose of key legends is this: to add clarity to data visualization while reducing the necessary amount of text to help the viewer understand the graph. Thus, I worked to prioritize clarity and concision to use space efficiently.
As with before, I began with competitive analysis and proceeded accordingly:
In my design explorations, I set out to define micro-level rules for the appearance and usage of legends in the company design kit. This can then serve as a visual guide for Honeywell UX designers to follow. To begin, I explored different possibilities for the color chip size and ordering of legend elements.
Before formally presenting my work to my manager, I showcased my explorations in a team review session. Here, I got valuable feedback on where to best focus my energy so that I could deliver concise, well-prepared work for formal review. Below is the work I showed and the iterations that I chose to further refine.
Based on the chosen iteration above, I underwent another round of review gathering feedback on the roomy and compact versions of that iteration. Below is a summary of the results from round 2 of internal review. My next step following this was to lock in rules for alignment and wrapping so that I could represent edge cases.
In preparation for my formal design review, I put together salient artifacts so that I could showcase my process and speak to design decisions made along the way. I learned that an important aspect of review is helping your audience understand your rationale for the decisions that shaped your work. It's also key to make artifacts big and easy to see so that people can better analyze and critique them.
A formal design review at Honeywell can be summarized by the points below:
During the three months that I spent designing, observing, and listening to others, I came to better understand what UX design in the tech sphere really entails. On my last day, I got to deliver a 30-minute presentation about my experience at Honeywell and the projects I worked on. Here are the lessons I learned from interning at Honeywell as a UX designer:
