Honeywell Experion® PKS - Experion Batch

Long History, Fresh Start

Since joining Honeywell at beginning of 2018 fresh out of college, I have been working with Experion Batch team as a software engineer. Working at a multinational conglomerate business, I was not too shocked to see developer comments from 90s’ here and there in our huge code base. In fact, our team still owns some products which are built upon legacy system dated back to 1980s’(learn more about product timeline of Experion PKS). While maintaining the infrastructure by adding modules and extensions may sound like a viable solution from technical perspective, User Experience, on the other hand, is compromised inevitably when it comes to the long drop-down list, rows and rows of window tabs, lack of guidance or feedback… the list goes on.

My concern since Day 1 was no news to the team, nor the management and leadership. Focusing on Velocity Product Development, Honeywell is launching a whole new process called Z21, which is going to reduce innovation cycle times in half. Batch team, as one of the pilot projects of Z21, has adopted Agile software development and moreover, modern technologies to build user-centered product.

Procedure Explorer

Currently in Batch Operations, operators are often “flying blind” not knowing when critical steps are coming up. According to our customer research, throughput is sometimes compromised because operators do not have the time-based visualizations to prepare for upcoming tasks. Knowing what is coming next and when is key to keeping the plant running at maximum efficiency.

While the majority of my work in this project is focusing on front-end development, I have certainly picked up a lot of useful design practices through the workshop as well as sync-up sessions with UX designer. At the same time, implementing features for a working product makes me dive deep into every design detail. As the development goes I was able to understand the patterns and principles better, and to come up with questions and feedback to support design.

After going through iterations of User Needs Analysis, we landed on a lighter-weight web-based application as a reliable solution to help customer achieve their golden batch. Procedure Explorer is an intuitive recipe visualization interface that facilitates seamless workflow to operate and control of batch processes.

Adaptive Web Design

"Adaptive design will (theoretically) ensure the best user experience according to whichever circumstances the user is in to interface. As the name suggests, the design adapts to the user’s situational needs and capabilities. As designers, we can show users that we’re in tune with their needs by giving them the right solution without asking for input.
A strength of adaptive design is that it feels more relevant to the modern user experience, whereas responsive design shows a more desktop-centric approach (with the demands of other devices taking a secondary, almost passive place). Let’s take a literal example; if you were driving through a long tunnel, wouldn’t you rather have a GPS screen that adapts to the environment and adjusts its brightness? That context-based performance and usability is reassuring, at the same time confirming that your smart device is smart enough to adapt and be extra useful.”

Our users work in complicated, stressful, distracting environments: an oil refinery plant in Texas producing over 5,000 tons of petrochemical products, or a pharmaceutical manufacturing plant in Germany running 2-million-dollar batches per day. Users could be sitting in the control room, multitasking on four separate displays while three different alarms going on in the background. They could be standing in the plant near a mixer equipment, working on a single-screen console station at the 5th hour of 12-hour night shift. They could be running back and forth between control room and the field, with a pen and a notebook in hand to write down parameters to be checked… With Procedure Explorer, our target is to resolve customers’ most concerned pain point – user experience.

Once a batch finishes configuration and kicks off running, hundreds of configured parameters and run-time data is generated. To work this massive amount of information into an intuitive visualization without compromising the legibility, it requires us to design adaptively and inclusively on the details:

Progressive Disclosure

"Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone."

An inevitable dilemma for interaction design:

1. Users want power, features, and enough options to handle all of their special needs. An operator would like to skip all the details and get straight to the error block, while an engineer needs some essential parameters to troubleshoot specific scenario.
2. Users want simplicity; they don't have time to learn a profusion of features in enough depth to select the few that are optimal for their needs. For example, users struggle to find their target in a context menu when it lists more than 10 items, or expands more than two levels - it takes forever for one single action.

Progressive disclosure is one of the best ways to satisfy both of these conflicting requirements. It's a simple, yet powerful idea:

• Initially, show users only a few of the most important options.
• Offer a larger set of specialized options upon request. Disclose these secondary features only if a user asks for them, meaning that most users can proceed with their tasks without worrying about this added complexity.

As we introduce Procedure Explorer as a user-friendly replacement for functionalities in existing system, progressive disclosure makes the transition happens naturally: with one action users bring up a set of limited functions, they are designed intuitively leading to next level of information, while not overwhelm users with the options.

A closer look on the workflow running a batch with Procedure Explorer shows the complete three layers of progressive disclosure: