Process Doc: Electrical Engineers’ System Raw Output Report UI
A product team recently came up to me for a design touch to their 15-year-old industrial web application. This is one of these many applications “designed by engineers, built by engineers, and used by engineers” in my company. It allows engineers to read device/service configurations and highlight any changes between two historical versions.
Without disclosing any of their business secrets, here is a page they wanted my suggestion:
Let’s break down problems in this UI by category.
Remove everything your users don’t need.
I understand that engineers might have an urge to display everything generated by the server for debugging purposes. But we are now talking about a web app.
Perhaps they are using file size and SHA to detect file changes on the server side. But does your end-user want to see the SHA string? Doesn’t the application already mark items as “CHANGED” at the row end?
Even if your users do want to somehow use the SHA to verify nothing gets lost during the communication — SHA, by design, will change drastically with a minor change in the raw string (avalanche effect). Your users probably don’t need to show the full SHA string to realize something gets lost in the transmission.
Arrange the more important items on the top.
This web app appears to arrange entries in a fixed order. So, traveling down history, the “Hardware-Type” and “Hardware-Serial Number” entries will always be on the top, even if these two never change.
I assume that their end-users care more about changes during a firmware update. So instead of calling things out with a “Change” column on the right that takes a lot of room, we can do a stacked group instead.
Right-align numbers in a table.
Right-aligned numbers give users a better perception of the size, as they can quickly scan vertically through the data and get a good sense of the data magnitude.
So if the project team chooses to display file sizes, here is what I would push for:
Put closely-related information close together.
Texts that are of the same typographical style and color, and are placed close together are usually perceived to be grouped.
From the context, I know that the “retrieved” time is the most important to know among the three. While adjusting the typography feature, I enlarged the retrieved date to make it serve as a page title.
These data entries also need to have their spacing adjusted.
Add proactive inline actions.
When users put their mouse cursor on small data entries like “hardware type”, what do they intend to do? Usually to copy the entire string. Instead of having users carefully select the whole string, right-click and select “copy” or hit Ctrl+C, why don’t we simplify it like this:
Final Outcome
When I showed all my iterations to engineers from this project, they were shocked. The project commenced before User Experience became the magic word, and like many other projects in my company the maintainers simply “nudge” in a small feature every time they hear their customers complain about something. So I shared all the progress and tried educating them to enlighten their UX mindset.
I also encouraged them to conduct a few user studies, which they never thought about doing, to learn more about their customers — not the customers who paid them $$ for the software, but the actual end-users who have to tolerate bad UIs as their daily life.
And remember this is where I started:
