Intro
CABB stands for Consorcio de Aguas Bilbao Bizkaya. They’re the ones in charge of providing Bilbao with clean water, as well as purifying the wastewater created.
As a product designer for DigitaLinkers, my task was to re-design their SCADA system (A SCADA is a central controller for industrial machinery).
This project is a continuation of a different case study. In order to gain a better context, I’d recommend you to take a look at that one before reading this case study.
The first part of the project was to design a dashboard that gave an overview of the plant’s processes. The second one was to improve the experience for the plant’s controllers, which is what this case is about.
*This particular software is only available for Desktop, and they have a fixed resolution for their screens, which made responsive irrelevant for this project.
Discovery
When this project started, we had already covered some ground as part of the discovery phase. Nevertheless, we were still missing to talk to the heavy users of the software: the operations team.
We had a different sessions where we went through the flows and actions of each of the different operation profiles. When we were done, we came up with rules and constrains we’d need to follow and also identified some data that wasn’t necessary and we could get rid of.
Requirements
- Make the UI cleaner and easier to read. Almost everybody agreed that the UI was very heavy to the eyes.
- Improve the way alerts were displayed. With some many graphical elements alerts were constantly missed or ignored.
- Improve the flows and navigation. They had inconsistent navigation patterns which result in users getting lost in the interface.
Hands on
Navigation
The first thing we did was to map the software structure, so we could define a proper navigation pattern. In the end, we went for a tree structure with a Breadcrumb, that would always let the user know where they were.
Colors
As we had already defined a color palette for the Dashboard project, we just inherited it and keep working with it.
Flows
In order to understand better the flows they had, we went for a full deconstruction of the screens and try and understand what they wanted to show.
We set a weekly iterative process, where I showed my progress on Friday, we went over it, discussed it and got some initial feedback, and then they sent all the final feedback on Tuesday. Then I’d present my progress on Friday, and so on.
Iconography
After the flows were accepted, then we went to the icon design phase, where each of the elements should be clear, but at the same time abstract enough so that they could be easily placed in the system, reducing all the clutter the images they were using before created.
The biggest challenge here was to follow the guides and constrains from the software, so we had to come up with a system for displaying all kind of different status.
Design System
Once the iconography was put in place, we developed a system for the developers to follow it, so they could then build all of the software following it.
We also created a UI Kit that was shared with them as a PDF. You can check it here.
Final product
In the end, we created a design system for them to build their SCADA according to their needs (Alarms, different states, processes, CTAs, etc).
Made the UI cleaner and easier to read
Our approach was to make the interface as clean and abstract as possible, giving more importance to actionable items than to what was working properly. This gave the operations people a clear state of their process, and told them what they had to do.
Improved the way alerts were displayed
We reduced the clutter with alerts by creating a framework for categories of them. Also, we used the red color as the alert one, generating a lot of contrast and letting the user know when something wasn’t working, right away.
Improved the flows and navigation
As part of the Information Architecture, we blended some views and separated others. We also added a proper breadcrumb with a tree view of the site, where the users is aware of where they are, all the time.
Design system in place
When the project was done, the developers had a system that they could use to build the whole system by themselves. Until today, they haven’t asked for clarification or guidance for anything, which means the system is working properly.