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). The main issues they had with it was:

• Lack of clarity on what was going on - No overview for management

• Operations people had to look at it for a long time, making it very heavy for them

• Some data was obsolete and some data was missing

*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

In the discovery phase of the process, we identified 2 main users who would interact with the system on a constant basis: Management and operations. We run a Design thinking workshop where we went deep in this topic and identified areas to work on, as well as defined both users’ interests.

Users

Management

Interested in the overall functioning of the plant. They want to know everything is working fine, and if there’s something they should be aware of.

Operations

Interested in their area. If there’s an issue and they’re responsible for it, they have to be aware of what’s going on, and take actions on it.

Areas to work on

Usability

One of the biggest pain points they had is that the initial page was unable to understand if you had no experience with it. The main driver for this project was to have a system that was more usable by all of the profiles involved.

Accessibility

The SCADA is used 24/7 in different kind of screens (from 23” to 60” screens) and in different environments, so sometimes it was very tiring to look at.

Constrains

As this is a 3rd party software where integrators were doing their magic on top of it, it came with a couple limitations and design constrains that we had to work with.

1. There were limitations in terms of charts and information we could display

2. There was a pre-defined way of showing errors that would be followed

As this was my first (and only so far) SCADA project, we had a very close relationship with the developers, where I needed their guidance on the Do’s and Don’ts for the project.

Hands on

Feedback loop

When the project started, we setup 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.

The feedback committee was formed by all kind of different profiles, from operations plant people to the decision maker of the project.

UI

One of the first decisions we made was to reduce all the color weight the interface had to make it more readable. Also, we went through a process where we defined the data and tried to put it all together in one screen.

Data definition

During the workshop we created a doc where we wrote down the data each of the profiles needed to be displayed in the initial dashboard.

Afterwards, we went through a definition process to discover which data was really important, what we could get rid of, and what was missing.

Data visualization

Once data was somewhat defined (there were still some unknowns, but we were confident we could finish this as the process advanced), we moved on to a DataViz phase. We used the same iteration model, where we were validating weekly our decisions.

Final result

In the end, the client was happy with it, and the initial feedback I got from it was very positive, so you could say the final result was a good one.

Sadly, when you work for an agency most of the times you don’t follow the project after you deliver it, so I don’t have actual data to see how the system is performing and what should be improved - there’s always something to be improved.

Nevertheless, from the agency they still say the client is satisfied, so I take that as a win 🙂