Analytics configuration
Analytics configuration was a feature I worked on as part of GE’s Asset Performance Management team. In order to get an analytic running on an asset, the user would have to perform I/O mapping as part of the deployment process. This involved basically looking at the list of inputs and outputs for that analytic, and telling the system where to get the data to feed into the inputs, and where to put the data that comes from the outputs. My task was to add functionality that would allow the user to vary these mappings based on criteria that they defined.
The Challenge
In order to satisfy the needs of one of our customers, we needed to provide a way for a different set of mappings to be used for different assets or in different circumstances. This was a challenging proposition, as I/O mapping was already the most complex part of our users’ workflow. In addition, this was a feature that many of our users would not need, so I wanted to make sure this functionality did not get in their way.
Research
To begin the process of designing this feature, I performed some research with the customer. I was able to observe the users’ workflow in the tool they were using at the time. One of the users was also able to give me a spreadsheet documenting all the various I/O map variations they were using for one of their analytics.
In doing this research, I discovered several things.
I found that a single deployment can have hundreds of I/O map variations.
I found that adding additional criteria can increase the number of variations exponentially.
I found that the process for making changes to these maps was tedious, and changes were difficult to track.
Later in the process, I was able to make a trip out to the office where our primary users were working. There, I was able to collaborate directly with one of our key users, and get validation on the design direction.
Ideation
Once I had a solid grasp of the problem, I set out to design a simpler way to manage these maps. The concept I came up with was something I called “Override Maps”.
The idea was that each analytic would have a single, primary I/O map, with each port (an input, constant, or output) mapped to a data source. Then, the analytic could also have one or more override maps. Override maps would be partial maps, generally only having a few of their ports mapped. Each override map would also be tied to a set of criteria that would define when it was applicable. During runtime, depending on the circumstances, any applicable override maps would be applied, their mappings “overriding” the ones on the primary map, like a transparency being overlaid onto a sheet of paper.
To help convey the concept to the users, I created an example based on Back to the Future: running an analytic on a flux capacitor. Using this example, I was able to show the possibility of turning hundreds of I/O map variation into just a handful of override maps. The users were very excited at that prospect, and so I began turning the concept into a set of screen designs.
Design & Validation
The first set of screens that I designed showed how a user would be able to create override maps, manage the criteria associated with them, and change the mappings within them, all from within the same interface where they were doing their primary I/O mapping.
I was very excited to show these designs to our users, but the response was less enthusiastic than I had hoped. The users I talked to told me that the designs I showed didn’t allow them to see an overview of the mappings and didn’t have a way to visualize all overrides for a given port. The screens were designed to allow them to easily manage all overrides on a single map (i.e. a given set of criteria), but they told me that wasn’t something they really needed.
So I went back to the drawing board, knowing that the override concept was still something they liked, but looking for a new way to design it that would better meet their needs. What I came up with was a simpler, more elegant solution. Instead of having override maps that were tied to a set of criteria, I moved the overrides to the port level. A user could drill into a port and manage a list of overrides, each with its own criteria. This not only better matched the users’ mental model, but did away with override maps as an object, which simplified several parts of the experience. After presenting this new design to the users, it became clear that this was the right direction.
Main Mapping Screen
Port Details & Override Management
Implementation
During the design process, I had discussed the scope of the work with the development team. Because the I/O mapping page would be undergoing some significant changes, we agreed that this was an opportune time to sort out some of the usability issues that had been identified in the past. So, as part of the design and development of this feature, we made some changes to make better use of screen real estate and simplify the data flow interactions. We were also able to make another feature, per-asset mapping, less cumbersome, while also moving it out of the way for users who don’t need it.
Below you can see the before and after images of the I/O mapping page. The data flow area is outlined in red, and the per-asset mapping area is outlined in yellow. You can see that the new page has a much stronger hierarchy, and focuses on the ports as the primary objects, rather than pushing them below the fold. Note that the side panels can be collapsed to enable even more screen space for the ports.
