Select Page

UX/UI Case Study – 2021

Claritecs – Redesign of BunkerMaestro System

Project Overview

My Challenge

The users had feedback constantly that it took too long and too much effort for their team to generate a schedule with our software, by the time it was generated it could already be outdated.

The system was also very buggy and kept generating outputs with incorrect values, resulting in wasted time and needing to return to the manual way instead.


We reworked how the system from ground up on how it should work, and helped the users to save 63% in time and effort required to generate an error-free schedule.

My Role

Responsible for redesign, discovery and ideation, user research and prototyping.


Monika (Full Stack Developer), Pindar (Full Stack Developer), Timothy (Data Scientist)

TL:DR Version

Previously, it took more than 2 hours for the users to generate an optimized schedule because they need to add in the new jobs, and fill in the post-ops details of the completed jobs to ensure that the ROB values are matched to the current values. And the way we treated the ROB values previously generated lots of errors for many scenarios.

We reworked the workflow & processes from ground up by removing the connection between the completed jobs and the upcoming jobs and making sure there is only 1 ROB value to use for each barge to run the AS. We also locked the output such that the correct values were applied to the correct jobs regardless of how much time has passed since the output was generated. Lastly, we moved the data validation stage forward so the users can rectify them prior to running the AS.

We managed to help the users save 63% of the time used to generate an output, with zero or minimised errors. We made it more user friendly by providing contextual feedback only when they need them.

Read on if you wanna get into the details.

In the Beginning…

Software Background

BunkerMaestro is a software for the bunker suppliers to optimize their bunkering jobs by running them through our proprietary algorithm. It also serves as a CRM system for the users to manage the vessels, customers and contacts.

Bunker refers to fuel for vessels.

Industry Background

Our software attempts to solve one of the main challenges faced by the bunker suppliers: too much manual work and time taken to produce a schedule for their jobs.

Bunker suppliers receive bunkering jobs for vessels that are calling at Singapore’s ports, for which they would assign a bunker barge to.

There are several criteria that the planners, the main users of our software, need to consider when planning the schedule:

  • Type of bunker grade required;
  • Amount of bunker, also referred as ROB value, in each barge;
  • Vessels’ ETAs (Estimated Time of Arrival) and ETDs (Estimated Time of Departure); and
  • Sailing times.

When the bunker has depleted, the users need to plan them for loading at the oil terminals.

Due to various unforeseen circumstances, the vessels’ ETAs keep changing. Therefore, the users need to update the schedule and re-assign the jobs to different barges to fit above mentioned criteria.

It typically takes the users more than 2 hours to produce a schedule, and they have to re-schedule every 4-5 hours upon receiving vessels’ ETAs updates.

What makes this industry challenging is also the fact that the barges must go alongside the vessel within 4 hours from the time the vessel drops anchor, or else the bunker supplier would have to pay a penalty for arriving late.

That’s because the vessels themselves are paying a “parking fee” for every minute they stay in the anchorages or port terminals. Therefore, the planners have to make sure their schedule has minimal delays.

The Challenge

When planning for a schedule, the user requires the following info:

  • the current ROB for each barges;
  • the ETAs and ETDs of the upcoming jobs.

Previously, the system required the users to populate the actual quantities supplied to the vessels for all the completed jobs up to the point where they wished to run the AS.

For example, the last time they ran the AS was at 12:00pm yesterday. And they would like to run the AS now at 12:00pm today. The following was what the users need to complete first:

  1. Update all the jobs ETAs if necessary;
  2. Add in all the new jobs;
  3. For the completed jobs, assign them to the actual barges and key in the actual quantities supplied;
  4. Add the completed loading jobs and add in the actual quantities loaded;
  5. Double-check to ensure that the current ROBs are accurate.

In short, a whole load of work.

That was before a planner could even run the AS to generate a schedule. In fact, it took them around 2hours or more before they could get an output. The system was not adding value by reducing their time and work, in fact it took more time when there were errors.

I’ve tried it personally and, as someone who is very familiar with the software and shortcuts, I didn’t fare any better. I was just faster by 30-40mins. I could imagine why they were giving such negative feedback.

Yet Another Challenge

Another issue arose when the user ran the output but did not view and apply it until hours later.

The timestamp of the ROB values used was not the one when the users ran the AS, but when the user applied it. The ROB values literally did a “time-travel” and it messed up the ROB values of the entire schedule when applied back to the job listing table.

For some jobs, it would result in negative values as the starting ROB values became lower than they should be, and for some loading jobs, it resulted in values exceeding the max capacity of the barges as the starting ROB values became higher.

This rendered the whole schedule inaccurate and useless. It wasted the users’ time to redo the schedule, this time manually as they didn’t felt they could trust the system’s values anymore.

We’ve tried locking the jobs depending on the duration from the time they ran the schedule, but we weren’t able to address all the possible scenarios. Each day there would be a new edge case that we did not cater to previously and the client would call in and complain about the messed-up schedule.

Enough is Enough

We decided that it was time to look more deeply into the problem and radically change how the system should function.

We realised that we were too quick previously to come up with a solution or a fix whenever the users encounter an issue or error in the system. We based the solutions on the current system, without pondering if it supported the outcome the users are looking for.

This time we decided to dig deeper to the problem based on the high-level user outcome that was reminded to us constantly:

As a planner,
I would like to run the AS just by providing the current ROB values and the upcoming jobs,
so I can quickly update the relevant parties of the new plan so they can plan accordingly.

Currently, the system doesn’t support the outcome due to the following:

  • A lot of time is required to get the current ROB because they need to populate the completed jobs in order to get it;
  • The applied output changes based on the time it was applied, messing up the actual schedule;
  • Too much time has passed before they realised there were errors in their inputs.

I wrote down my thoughts in a confluence document about how it might potentially work and what the outcomes looked like. Here’s the summarised version:

  • Users are no longer allowed to freely insert a ROB entry of random datetime; they can only insert a current ROB value ONLY when they run the AS;
  • The output will be “locked” from the time it is generated, regardless of when the user finally applies it to the job list.
  • Any post ops details done on the completed jobs will not affect the barge’s ROB.

My team chipped in, suggesting to bring the error validations to before the AS is run.

It was a big project and revamp and involved many moving parts. Luckily we have very understanding clients who were willing to give us time to “tweak” the system.

We broke down this huge revamp project into small workable chunks, starting from the point of entry for this journey of getting an AS output.

Each test would build up to the next one until the entire re-working is completed.


Single Manual ROB Entry

We started first by tackling the manual ROB entry issue: there will now be only 1 manual ROB entry at any time: when the user needs to run the AS.
Previously, each time the users entered a manual ROB value, this entry got added into the system. Sometimes it was unintentional as they have keyed in the wrong values or datetime and deleting them was very manual: requiring the assistance of the dev.
It is now replaced by just one entry when the user runs AS, and its timestamp gets updated each time the user runs the AS again.

E.g I ran the 1st AS at 12:34hrs with barge A having 1,234 MT, then barge A’s manual ROB entry:
ROB = 1234MT, timestamp = 12:34hrs.

When I ran again at 18:59hrs with barge A having 789 MT, then this same entry will be updated to:
ROB = 789MT, timestamp = 18:59hrs.

What happens to the ROB values of those jobs for barge A between 12:34hr and 18:59hrs? They are no longer important because they are completed; ROB values are crucial only for the upcoming jobs.


Tackling the Ongoing Jobs

Next, we tackled the scenario where there are ongoing jobs at the moment when the user wishes to run the AS.
In fact, many of the issues stemmed from this scenario where a job for vessel C was ongoing when the user updated the bunkering jobs and filled in post-ops details to prepare for running the AS.

E.g. Vessel C with ETA 06:00hrs required 1200MT, and barge A is assigned to it. Barge A has 1800MT ROB before the job, and would have 600MT ROB after. The job should be completed at 14:00hrs.
But by the time they completed the 4 steps, that previously-ongoing job C was completed, by virtue of the timing calculated by the system.

The ROB value should be one after deducting the quantity for job C, but the AS pulled in the pre-job ROB without pulling in job C as it is already completed.

E.g. at 14:01hrs, the ROB for barge A should be 600MT, but the system still pulled in 1800MT to use for assigning her to upcoming jobs.

This was incorrect, and it rendered the output invalid. Worst of all, the user could discover this error ONLY after the output was generated.

It wasted lots of time and caused loads of frustration.

We resolve it by showing the users the ongoing jobs for any of the barges and instructing them to use the pre-job ROB values. The user simply needs to enter the ROB value without needing to enter the timestamp; the system will auto-adjust it to match the vessel’s ETA timing.
For example, it’s now 12:34hrs and there’s a 2400MT bunkering job for vessel B whose ETA was 06:00hrs. She has been assigned to barge A, and the ETC (estimated time of completion) would be 16:00hrs.

Now, both the ongoing job and pre-job ROB value will be pulled into the AS.

Why not just enter the post-job ROB value? It’s because this requires the ROB value to have a future timestamp, something which would mess up the algorithm and generate errors.


Locking the Output

In this step, we tackled the scenario where time has lapsed from the time the output was generated and the time when the output was actually applied to overwrite the schedule.

Previously, we couldn’t imagine such a scenario would occur: we imagined that the users need to run the AS to get a schedule and quickly update the relevant parties.

It appeared that the users would run the AS and leave the office, sometimes for hours.And by the time the users returned, some of the ongoing jobs would already be completed based on calculation. When the user applied the output to overwrite the schedule, the system simply skipped over those jobs again and used the starting ROB for the next upcoming job.

This also rendered the new schedule useless, and the users had to rerun the AS again. More time wasted and more effort required.

We tried to lock the ongoing jobs’ assigned barges and ROBs for X hours after the schedule was run. But we kept running into different edge cases each day the user tested running the AS after we hotfixed it.

What we did finally was to “lock” the entire run for as long as it was not applied, unless they ran the AS again after the previous one.

This means that if I ran the output today and waited until the next day before applying it, the system would start overwriting the schedule from the time it was run, not the time it was applied. This will secure the integrity of the output and, more importantly, the ROB values for all the jobs.


Earlier Error Validations

At this step, we tackled the issue where the potential errors are taken care of at the pre-AS stage, while the users are keying in the starting ROB values.

Previously, we let the AS algorithm do the checks, but it returned the errors only about 20 mins later. Time was lost when it could have been handled much earlier.


What we did was to put in place ROB value checks for ongoing and the next upcoming jobs of each barge. If it is an ongoing or upcoming delivery job, is the starting ROB value sufficient to do that job?

E.g. an ongoing job requiring 1200MT of bunker X; is the pre-job ROB of barge A 1200MT and above?

If it’s an ongoing or upcoming loading job, will the starting ROB value cause it to load over max capacity?

E.g. barge A max capacity: 6650MT; loading job is 6000MT; is the pre-job ROB of barge A 650MT or below?


Moment of Truth

Finally, the real challenge. After testing for a week with a couple of minor issues to be fixed, we felt we were ready to deploy it to production.

I did a Loom video showing them the new procedure to run the AS, and a Powerpoint presentation for those who preferred static images and text.

What came next was the long wait for the client’s call or email with their output.

The email came eventually, way earlier this time: they liked how the new procedure allowed them to generate the output so much faster, and more importantly, the output was acceptable without errors.

Our hypothesis worked and our efforts actually paid off.

As a result of the redesign, the users were able to get an output in about 40 minutes, a huge savings of about 60% from the 120 minutes it took previously.

What’s Next?

With the ROB issue finally settled, we are now able to focus on the mechanics of the AS algorithm: to push it further with more criteria and restrictions so we could cater to customers with different operations requirements.

Lessons Learnt

This is one of the most important and challenging projects I’ve worked on as it provides real value for the users, requires lots of research and revisiting of the system.

I was very blessed to have the trust and backing of my management team to pull this off, despite the initial concerns that it might break the entire system.

Kudos to my team who trusted and supported each otherwere able to translate my thoughts into actual codes

Here are some important takeaways from this project:

  • When the fixes are not working, we need to look into the problem deeper;
  • Don’t be afraid to make major overhauls when absolutely necessary;
  • You don’t have the solution; you only have a hypothesis of the solution;
  • Start with small, manageable steps and build upon it;
  • Help to team see the big picture and what positive impact they would be making.

Next Project >>