Aqua Solution’s fish farming framework (case study)

Aqua Solution’s fish farming framework, and feeding system: UX case study

“How does one bring innovation to an industry that is – at the same time, both woefully stuck in the past, and in its most innovative time ever? “

Before we delve in, I must first emphasize that the opinions, and perspectives presented within this case study is wholly my own, and may not reflect the opionions of Aqua Solution.

This past year I worked as a consultant as lead user experience (UX), and interaction designer for a project at the centre of the booming fish farming industry in Norway.
Fish farming is today experiencing an incredible boom in both growth, and innovation. There are an innumerable amount of upstarts that are building everything from software, to new ways of feeding. There are even aquatic drones that use lasers to shoot 2mm large salmon louse of the fish, before the parasites can cause irreparable damage to the fish.

This past year I worked as a consultant as lead user experience (UX), and interaction designer for a project at the centre of the booming fish farming industry in Norway. Fish farming is today experiencing an incredible boom in both growth, and innovation. There are an innumerable amount of upstarts that are building everything from software, to new ways of feeding. There are even aquatic drones that use lasers to shoot 2mm large salmon louse of the fish, before the parasites can cause irreparable damage to the fish

However, at the same time, after visiting multiple farming sites I can personally attest that the systems in place to actually feed the fish has seen none of this innovation, and has instead been stuck in stasis for at least the last 10 years.

Improving upon, and bringing the processes focused on fish feeding into the 21st century  was the focal point of the entire project. Backed by the mission statement:

“to create optimized an feeding process that autonomizes the feeding process, and moves control away from decentralized facilities and into centralized control rooms.”

On the surface fish farming is simple: “ Breed, and feed fish in enclosed facilities,harvest grown fish, pack and deliver fresh fish across the globe.”
However, taking a deeper dive, reveals that the industry reality is much more complex. As with all farming, fish are live creatures, beholden to; weather conditions, feeding patterns, diseases, water currents, algae, mechanical equipment, genetics, and numerous other factors that all affect the profitability, as well as the final delivered product

The solution presented at Aqua Solution is simple; Leverage the company’s considerable experience with HMI/Scada, and Industry 4.0, within the Oil&Gas sector, and bring the daily routine of aquaculture into the 21. Century, and accessible on any platform anywhere, via the web.

The Brief

For at least the last ten years, the main production process for farming fish has remained the same:

Install a fishing barge in the ocean, then add 1-12 fish cages filled with approximately 100 000 – 200 000 salmon per cage. Then feed the fish via hoses which blow feed pellets from silos on the barge into each cage, all the while a farmer watches a camera feed of how the fish consumes the feed pellets, in order to provide the optimal amount of feed the fish can consume, without wasting feed.

Both the software used to control the process, as well as the process itself has remained almost entirely static since the concept of camera feeding the fish began, but that is about to change as the industry is standing on the precipice of innovation with the introduction of systems like the one I will present through this case study.


The project was kicked-off by first engrossing ourselves completely in the industry, and  innerworkings therein, in order to allow myself, and the rest of the team to gain valuable and critical knowledge.

The team at Aqua Solution consisted of:

  • Arne – an amazing engineer specialized in programming HMI, and SCADA solutions, as well as web technologies.
  • Pete – HMI, and backend specialist.
  • Thomas, our project leader, and PLC programmer.
  • Kåre, lead PLC programmer.
  • me – lead UX, and IXD, graphic designer, and support developer.

and in the latter part of the year,

  • Sturle an apprentice automatician, and programmer.

Using me as an example, I went from barely knowing more than cooking a piece of salmon, to an expert on the entire aquaculture feeding process.
This path to knowledge started simple, with a lot of questions, googling, and meetings, before we moved on to more hands-on focused study.

Field Study and competitive analysis

After gaining some baseline knowledge and structuring a plan, we set out on a field study to expand our knowledge bank on exactly how the daily activities were completed, and to get to know the users, in their own environment.

In order to use our time as efficiently as possible we split up with our own specific area of focus. My task was to get to know the users, and the systems they use, while others studied the camera systems, mechanical components, and PLC systems.

My focus was on performing observations and semi-structured interviews with the farmers while they worked, as well as studying the different feeding systems currently in use on the different sites.

Returning from the field, we had answered many of our questions, all the while new ones were forming, as well as an acute desire to apply our newfound knowledge in our project.

For me, that meant preparing, and analyzing the gathered data – of which there was approximately 4 hours of audio footage, more than a thousand pictures, and a whole lot of notes, all of which would serve as the basis for the next task on my agenda.

Competitive Analysis

In order to both refrain from remaking the wheel, I performed a competitive analysis where I studied all four of the feeding systems I had observed. My reasoning was to gain a greater understanding of how they worked, what their limitations were, as well as what unique features each of the four had to offer.

To understand their structure better, I first outlined the entire architecture of all four systems, and built flow charts detailing the user interaction with each system. Both of these proved highly valuable in the following months – both for understanding the systems themselves, as well as the users.

Once completed I used these, in addition to the results from the interviews, and my notes in order to analyse how interaction with each system was done.

After the analysis was completed I had begun to form the a very clear idea of both the valuable functions within the competitions systems, as well as their shortcomings, which could be used as a basis for the first prototype of our software itself. However, I still wanted to understand, and get to know our users, and their needs better.

User Research

During the field study I carefully studied the users, and how they interacted with the different software available, in order to discern the different types of users, and user patterns present.

The first part of my observation was done by watching the farmers while they were doing their daily tasks. This allowed me to observe how they interact with the system, as well as certain patterns, such as:

During the actual feeding the farmers would like to spend as little time as possible focused on the software itself, opting instead to focus on camera feeds – both above water facing the feeding nozzle, and underwater, placed in such a way to observe both the movements of the fish as well as the feed sinking through the water. The software was therefore only interacted with, in the event that the farmer needed to adjust the numbers in order to tweak the amount of feed to be delivered.

Additionally, I also noticed that different farmers had different ways to tweak the systems, where some prefer to simply increase the current weight of feed delivered each minute, others preferred to alter the registered readings for water temperature, and let the system recalculate the feed based on that parameter. This allowed for the same feeding program to be active in the system, but would still provide a greater amount of feed to the fish, because they have a healthier appetite when the water is certain temperatures

Other important findings from both the observations, and the interviews was points such as:

  • Each system is so unique that they are unable to move from site to site, and feed from different systems.
  • Each farmer has their quirks for how to provide the best care to their fish.
  • Some of the sites use legacy software, which they are familiar with instead of newer software.
  • Other farms, on the other hand use beta versions of coming software, which are buggy, and do not have all intended functionality in place.

Due to these patterns, much of the strategy for designing our software therefore became focused on not only streamlining the experience. But also providing something that both improved upon the usability of the system regardless of prior experience, as well as providing an experience malleable enough for each farmer to retain their personal quirks in the new software.


Completing my analysis I had a very clear concept in mind which would take advantage of the well functioning parts of the competitions systems, and combine them with a more streamlined, user friendly interface which would both optimize the farmers time, and allow them to keep their attention acutely on what is actually important – the growth, and welfare of the fish.

For our first version I did not want to add too many new features, and causing feature-bloat to the software. Instead I wanted to hone, and perfect a dashboard which could layout everything the fish farmers need to see on one screen, thus removing the need for the farmer to jump between pages, and look up data.

Design Principles


The current competition has cumbersome, difficult, and complicated interfaces.
Lets be different.


The users vary in both age and computer know-how. The interface must therefore never be ambiguous, but alway clear in speech and presentation.
Text must also be legible for anyone.

Main tasks first, fluff later

To be able to quickly gain an overview of the site, and its feeding, is key.
Everything else, although important, is irrelevant if the fish starve.

Present the depth of the system, without depth in structure

The system needs to display a large amount of data, without being overwhelming, or resorting to a high amount of sub-pages.

During my competitive analysis I had created a series of information architecture diagrams for the competition’s systems, and to begin visualizing my design plans and intentions, I went to work on creating a similar structure for our own system. Sitemaps and information architecture are a good way to define the hierarchy of the system, and how all of the different parts connect to each other.

It was also an essential tool to refer back to, as a macro view of the site, especially during meetings and discussions within the development team, as well as with the stakeholders.
These diagrams were, through collaboration, and discussion, continuously worked on, as I moved into designing the first low-fidelity wireframes, and prototypes.

Prototyping & Focus Group

As mentioned previously, I based my design around four key principles, which defined everything in my design.
The first of these was the idea of simplifying everything. However, this does not mean that I wanted to remove necessary or important functionality. Instead I wanted the farmers the possibility to “zoom out” and get a bird’s eye view of everything important happening on the site – without overwhelming the farmer, or drowning out the important information in a sea of data.
This was quite a formidable task, and I went back and forth from my field study notes, the information architecture, and the flow charts.

From here, I iterated over multiple low-fidelity prototypes, until I had very rough idea of the basic structure, and presentation of information and data throughout the system.

The design itself is based upon much of the guidelines provided by the material design specification provided by google. This was for two main reasons:

  1. Most people today, are familiar with google’s design, therefore there is a certain subconscious recognition in elements such as buttons, search fields, etc. which will provide a baseline familiarity with the system from the first interaction, allowing the users to become acquainted much faster.
  2. Google has done extensive research in areas such as legibility of fonts, sizes, spacing etc. allowing me to put less emphasis in researching the optimal solutions myself.

Although I felt I was beginning to develop a good understanding of what the necessary components for the system were, there was still some uncertainty about how each component were used by the farmers – as well as defining the importance of each component. To remedy this concern, we invited three farmers to our offices for a focus group where the intent would be to have a discussion about both how they work, as well as what their desires, and wishes for the system was, such as:

  • what tasks did they feel were cumbersome in the current systems
  • what is the important pieces of information the system can give them to better inform their feeding.
  • How do they work
  • If they were in our shoes, what would be their focus.

Following this very productive discussion, I developed a comprehensive list of user tasks, ranked by importance, and colour coded for each sub-section of the system. Additionally I also defined some of the key characteristics, which I felt defined a fish farmer, and their needs.

Design development

Equipped with a wealth of knowledge, and concrete requirements of everything needed for the system I was ready to take my low-fidelity prototypes to the next level.

During the following weeks I designed, and iterated, and re-designed, and continued to iterate, until I was left with two candidates for my overview screen. I finally had my bird’s eye view, which could accurately describe both the feeding status, and current progress of each cage in the site, as well as environmental data, and overview of the stock and size of the fish on the site.

Using Adobe XD I expanded upon my candidates to create an interactive prototype, which provided the possibility to click through the system, testing out how it would feel to use the system to feed the fish, and control the inner workings of a fish farm.

One on One Usability / User Testing

Using my interactive prototype we set up a mock control room and invited the fish farmers back for a second round of evaluations. This time however, I focused on one on one evaluations, where a colleague would interview, and discuss other topics with two of the farmers, while I tested the system with the final one, rotating through all three throughout the day.

Having the farmers sit down with my designs felt both amazing, and terrifying.

Two days before my participants arrived, I first went through the entire evaluation with one of the other members of the development team, as a pilot study, and eliminated any leading questions, and other problem areas.
The evaluations themselves were built around the same core-questions, and tests. But I swapped my two prototype candidates between participants, in order to get first impressions of both.
The entire evaluation was recorded with audio recording software, as well as screen capture, to allow me to go back to specific questions, or problem areas – something that served to be equally beneficial here, as it was in the last big evaluation I completed, my Masters Thesis.

Re-evaluation & Redesign

Following the usability testing. There was a period of analysis of the results, which lead to multiple smaller improvements, as well as some key points which were glaring in hindsight:

  • The text had to be much larger than first intended.
  • Some of the datapoints intended to be presented on the main page, were not important enough to warrant their placement.
  • Many of the subpages were superfluous.
  • Certain navigational paths were not as clear as I had intended.

Following these results I went to work re-designing the prototype, while also increasing the fidelity of the wireframes, in order to present a view which was as close to a real, live system as possible.
This was to be the final prototype before the development began in earnest, and I therefore focused a great deal on having it convey the entirety of the system as clearly as possible.

The full prototype – please try clicking around, and test it for yourself.


While much behind the scenes functionality had been worked on alongside my prototyping, the system did not go into full production until after the completion of my final prototype.
The entire system was developed with the Atvise software – a completely web-base HMI / SCADA solution.
The main concept behind Atvise is the manipulation of Scalable vector graphics (SVG) using both Javascript, and Atvise’s own WebMI language.

Throughout the development phase I designed, and implemented all of the SVG graphics used within the system, while our lead developer added most of the functionality. For some of the elements I also altered preexisting objects provided by Atvise to reflect our needs – such as speedometers, sliders, and radiobuttons.   

Version 0.8 of the Aqua Solution feeding system

The development itself lasted for approximately six months (June-December), while I stepped away from the active development around September in order to tackle other areas such as integration of analytical tools (HighCharts, and Tableau), as well as the counterpart to the feeding system – the video management system (VMS), which is necessary for the farmers to study the fish within each cage.

Now & Future

At the time of completion of my consulting assignment at the end of 2018. The system was being readied to be deployment to one fish farm for live testing, alongside the VMS, and the database backend.

For myself I am thrilled to see something I designed reaching beyond my sketches, wireframes, and analysis notes, and into the hands of actual users. I must however say that it comes with a certain sadness as well, as I would both very much have liked to be present when the system is turned on for the first time, as well as I would have loved to gather first hand impressions from the users, as I am sure there are still unforeseen issues that should be ironed out in order to provide the absolute optimal experience for the users.