Email with the mentor picks has landed 📨!

All 3 mentors 👩‍🦳👨👨🏼‍🦱have more than 10 years of digital experience and have worked with major brands across multiple industries.

I'm very keen to work with the one who's working as Principal National Creative Director for Deloitte Digital Australia. His experience includes websites, mobile apps, immersive experiences (AR, VR, IoT) and digital twin interfaces, which is rather impressive.

But what caught my attention was his passion for mentoring and coaching his own team of designers to advance their careers for the past decade.

It's not easy to keep up a passion as a mentor because it takes an enormous time and effort to have create the synergy and rapport with the mentees.

Looks like I've found myself a mentor to kickstart this bootcamp!

Next up will be scheduling the 1st video call with him. Very much looking forward to it!

Today I reviewed the document that details the overview of the bootcamp and the timeline.

I will be working on 2 projects to be showcased on my portfolio based on my desired goals together with a mentor.

I did the onboarding quiz and personality test in order for IxDF to shortlist 3 mentors from which I would pick one to work with.

I've also started on my 1st course also: UI Design Patterns for Successful Software

I will learn how to choose UI design patterns appropriately for different use cases and how use them to speed up my design process.

The outcome is a nicely crafted UI with the users in mind that will help them move through the interface with minimal effort, simplify data entry and reduce errors.

What I discovered is that the courses are delivered in a "dripping" method, meaning that we won't get to view all the tutorial videos at once, but are delivered weekly. This way our brain will not go overload with new information.

It also allows us to take a multiple courses concurrently and have ample time to reflect and retain those info.

Next up: awaiting the email to finalize the mentor that I'm going to work with! So excited!

Yep, I've finally decided to get myself more educated in UX design and signed up for a bootcamp organised by Interaction Design Foundation!!

I hope to build up a solid portfolio of case studies to showcase for potential hires and freelance work.

I also hope to hone my UX design skills in deeper and incorporate what I've learnt in Design Thinking into it.

This will serve as my daily journal for my bootcamp progress and a review of what I did and learnt.

See ya!!

I love it when my team challenges my design! Sometimes I may be too attached to my own designs to see how something could be done in another way, or sometimes I don't know if it's feasible coding-wise.

So it's always good that your developers could suggest better ways to design a component.

This was what I've came up with for entering the ETA formats initially: 2 options for user to click to select either enter the ETA datetime or ETA indicators.

So in  order to enter an ETA date with AM, the user needs click the "Indicators" first, key in the ETA date and then select one of the 4 options.

Firstly, the ETA date is repeated in both cases, so there could be a way to use it for both the datetime format or the indicator format.

Secondly, the user needs to toggle between 2 options in order to get to the format they need.

Here's what my dev proposed: one input field for the date, and one input field for the time and the indicators:

If the ETA date & time is available, the user can simply key them in as usual.

If its any of the 4 indicators, the user can click on them and the timing input field will be updated:

Or if it's only ETA date available, the user can leave the timing field empty:

If it's an ETA daterange, user just need to select the start and end date from the datepicker, and the timing options will be disabled:

And this is only the prototype designed on paper.

During development, we are able to streamline it further by having the timing input field to behave like a dropdown where you can select to enter timing or any of the indicators.

Here's the scenario where its an ETA daterange: the timing field gets hidden entirely:

If its the same date, then the timing field appears. If the user leaves it empty, then it will be taken as an ETA date only format:

Once the user mouses over the timing field, the dropdown appears:

My biggest takeaway is that always talk to your developers during the design phase and be amazed by the solutions they might come up with!

While designing the job list page for the WPOC project, we came to a little challenge to display the sequencing of the operations.

Here's how it looks like initially: bunkering ops having its own column, and the other ops at its right. From a glance, you can't really tell which ops is going 1st.

Initially we had only 4 operations in all: bunkering, underwater ops, ship supplies and lube oil. To display bunkering in one column and the other 3 ops in the other was still fine.

Then 5 more ops were added to the list, making it a total of 9 ops.

Not all 9 ops would take place for a job, but the bunkering would definitely take place. The user would select the ops that would happen for each job.

I tried added numbers to each of the other ops and because of the width of the column, they will be wrapped to the next column.

It's still not so clear to tell the sequence at a glance due to the wrapping:

And I have another challenge of displaying the bunkering ops in cases where there are multiple fuel grades to supply.

Here's an extreme example of supplying 3 fuel grades: not a very good use of real estate with lots of white space due to 3 ops stacking on top of each other:

The next iteration is to combine the 2 column into one, with the bunkering at the top and the other ops at the bottom.

I added arrows between each ops in place of numbers to visualize the flow. Now it's easier to see the sequencing for all the ops:

This also solves the challenge of multiple fuel grades: they can be displayed in sequence too from left to right:

While doing this, I've also combined the receiving vessel's and location column together to free up more space for the ops column.

It can display up to 4 ops in sequence. If there are more ops, then the last pill will display the number of the remaining ones.

I kinda think the divider between the bunkering and the other ops is redundant, so instead I bumped up the font size of the ops pill component.

So now they can be differentiated from the bunker barge above, which are also in pills:

Here's how the latest version looks like:

Today, I worked on creating a interative walkthrough in Figma for the users to have a better field of the Add Job flow and Job Single Page tabs.

I first converted all of the togglable fields such as radio buttons and checkbox buttons into interactive components:

And replaced as many sections by components that previously weren't so they could be interactive now on.

It now looks more like a powerpoint slide, but one that's interactive and one that you may scroll down and up to view the entire page:

2nd half of the day, I worked on the revising one of the Job Single Page's tab: Bunkering Info, due to new information from user.

There are several structural details of the vessel such as freeboard height, manifold sizes and locations, and receiving rates, etc..., which needs to be entered for each job.

Initially, we presumed they were meant for the bunker vessels, but it seems like they were meant for the receiving vessel.

They usually won't change, unless when the users were updated by the vessel's personnel of the changes. Thus, the users need a way to see those information and have the ability to change them as and when is necessary.

Initially, we planned for it to look similarly to the rest of the components: item title on the left and value on the right. But we realised it makes the whole card look cramped and long due to the amount of details to be displayed.

Thus we were thinking to have it in 2 columns instead, and then make the values larger. It makes them easier to read in a glance:

When user clicks on the Edit icon on the top right corner, they will be able to update the details.

The layout will change to be how it looks like for entering into the input fields.

When saved, system will apply those changes to that receiving vessel's details in the database as well.

Today I worked on the add job section where the users key in the Estimated Time of Arrival (ETA) of the vessel.

We discovered that apart from the typical ETA with date and time, there are times where the users receive ETAs in other formats, such as:

1. ETA date only but no time;
2. ETA date only with timing indicators like AM or PM;
3. ETA daterange.

And also, for the nominated quantity, it might be a range at first instead of a single value.

ETA Input Version 2

We decided to create another option for the ETA input field. So now, if the users receives an ETA with Datetime, they will proceed as usual with the 1st option:

For the other formats, they will select the Indicators option.

Below the date input field. There will be 4 options for the AM, PM, LAM (Late AM) and LPM (Late PM).

For the ETA daterange format, the timing indicators are disabled since its a daterange and impossible to indicate whether it will be arriving in the AM or PM within the range:

Quantity Range

We have already this function in our current system, so it's only a matter of incorporating it the design.

We think we will allow user to enter a quantity range for each parcel of bunker to allow more flexibility for users:

That's all for today, c'ya tml!

We conducted our 1st workflow walkthrough of the Figma screens with our client W today, and it was pretty fruitful.

We confirmed many of our presumptions (we were about 95+% correct), got new insights and uncovered new outcomes:

1. More fields are required for the bunkering post-ops section (essential for reporting);
2. More than 1 parcel can be assigned to Owner (crucial for reporting);
3. Users need to know the sequence of all the ops; not only bunkering (important for ops people);
4. The formula for calculating variance, which is the difference between what was exepected and what was actually used, is different from other clients (also crucial for reporting);

Had we not planned for the workflow walkthrough this early into the project, all the above would be impossible to be discovered unti much later.

The initial plan was to show client W the 1st working software 2 months after kickoff, followed by 1 month of UAT, bug-fixing before going live.

Time is of essence to make sure we ship the right stuff and ship it right.

This was something I learnt from my ScrumMaster course and Jim Spool's UX workshop, and it was acutally the first time I ever kicked off a new project where I could be both involved in the design and project management.

After the video call, our team quickly had a chat and refine the ERD while I revised the screens to reflect the changes.

The tricky one was the sequencing of the ops, which we assumed to be of no importance for the client.

Any of the 4 operation types could commence first, but usually it would be the bunkering. The clients need to access it easily at the job list page, and define the sequence at the job details page.

I came up with 3 options for the initial design:

I personally go for option 3 because it requires less mouse clicks:

E.g. in order to bring Bunkering ops down to sequence #4, for option 3, I will click & hold once, drag it down and release; for option 1 and 2, Iwill need 3 clicks. And it's not too complex comparatively to code with current web technologies.

Next task I'm focusing on tomorrow will be the sequence display at the job list table.

The other outcome I hope to achieve is how the users can update the status of each ops easily at the table, without the need to open up the job details page to do so.

It is a bloody good challenge!

Today is a whole of bug fixings and troubleshooting.

More importantly, we had a long discussion about the whole user experience of our auto-scheduler (AS) feature.

When the user runs the AS, it was not easy to find out more details about it and we, as the PM or someone who needs to troubleshoot when issues arise, would always get them from the backend team. And they need to check the logs before replying us.

So this happened every time when we need to check the AS details. Time and manpower is "wasted" to do those tasks, as they could be used on more productive tasks like completing new features, refactoring codes, or reviewing completed tasks by other colleagues.

It also didn't provide any clarity to the management or the users themselves, on all the AS runs that they have made so far. Metrics such the number of times did they run AS on a daily basis? How many runs were successful? How many weren't? What are usually the errors encountered? were not readily available for retrieval.

What I do now for recording them is very manual and time-consuming. I created a Slack post and update on a daily basis the outcome of every AS run.

We did not create a good user experience even for ourselves in this aspect, which was quite sad.

So we came up with a to-do list of all the problems that the users (the clients and us the support team) are facing, and the desired outcome based of them.

Our hypothesis is that with those problems resolved, the users (the clients) would be able to run the AS and get the output they are looking for; when there is an issue, the support team would easily retrieve the information for troubleshooting.

At the 2nd step of the add job flow, the user is able to enter the timing details of the Receiving Vessel's (RV) port call and the bunkering details.

The input fields for the timing details are pretty straightforward with usual fields such as the estimated time of arrival (ETA), location, contact details of the point-of -contact (POC), etc...

More time was spent on the bunkering section. Through the interviews with the stakeholders, we learnt that the RVs may be receiving one or more types of fuels, and for each fuel type, the RVs may be reciving it in one or more parcel units for recording purposes.

With that, we break them down into 4 main scenarios:

1. Single fuel type / Single parcel;
2. Single fuel type / Multiple parcels;
3. Multiple fuel types / Single parcel each;
4. Multiple fuel types / Multiple parcels.

Quantities and Parcels

We spent quite some time on designing the input section for the quantities and parcels.

Each parcel can belong to either the Charterer or Owner, and we need to represent that as an option for the user to select.

The initial idea was to have a unchecked radio button on the left of the input field:

The user will check if that parcel belongs to the owner.

It was a bad design and will cause unwanted outcomes: As it's a radio button, if the user accidentally checks on it when there's only 1 parcel, you can't uncheck it anymore. User has to either close this modal and restart all over again. Very painful experience, I would say.

The "Owner Account" title is too long for the radio button to be placed on either left align or right align.

My teammate Jonathan also commented that just by having the field title as Quantity isn't clear enough for user to know that each row is actually a parcel.

Next iteration

He came up with the following idea:

Now each quantity row is called Parcels, and instead of having the radio title on the top, it's now on the right. By selecting the relevant radio button, the title will update to reflect parcel's account.

This is much better than my original idea, but it still doesn't solve the single parcel's issue where the user accidentally clicks on the radio button.

3rd iteration

From his idea, I realised that we've forgotten that we could use toggle instead of radio button.

So I converted the radio button to toggle button, and moved up the word "Account" to be the title of the toggle. Now by toggling the switch, the account owner title will be reflected.

And it solved our challenge of selecting the owner of the bunker when it's single parcel.

Frankly, I would not have come up this 3rd design by my own if it was not for the team's feedback on the very 1st one. So it truly helps to sharing the designs early to the team and get their feedback.

The next thing is that the team might raise up questions about the fields and flow which I might have missed initially.

We were awarded to develop a proof of concept (POC) for client W, the idea is to develop a agency module for them to manage and track their clients vessels.

I did up the initial screens for the sales presentation, right now it's about refining the screens after getting more detail requirements from the client.

Dashboard

For the dashboard, it will show the map of Singapore with the different anchorages. On the right side, we have a collapsible component that displays the upcoming jobs.

Each upcoming job is a card component that can be reused for in-progress jobs too.

The next tab displays the in-progress jobs. There's a progress bar to show time remaining to the completion of the operations.

Add New Job

For adding of new job, we initially broke the form into 2 steps.

At step one, the user will choose the ops that will take place for this RV. The user will be able to add more fuel grades if necessary.

At step two, the user will enter all the details for each of the section. As you can see, the form is pretty long:

When analysing the form, we discovered that the bunkering section makes up the bulk of the form. Thus, we decided to break the bunkering section to its own step to make the form more digestible.

We also added the function to allow user to switch the position of the fuel grade to define the sequence of the supplying of the bunker:

Next up, the bunkering ops section! :)

Today, our client G posted a good challenge for us:

How Does System Suggests Delays For Overlapping Jobs?

When 2 vessels (RVs) arrive around the same time, and would be bunkered by the same bunker barge (BV A), usually what the user will do is to supply the earlier RV first, and then supply the later RV with some delays.

Once the user keys in the estimated time of arrival (ETA) for the RV, system would generate an estimated alongside timing for the BV. Currently, it's set to 2 hours.

Outside the system, the user will know that delays for the later RV is inevitable. But inside the system, issue arises when the user keys in the ETA for the 2nd RV and then assigns to the same BV A.

Currently, we will display that there is timing clash for that particular BV, but still allow users to assign. The assumption is that the user will later update the alongside timing to a logical one, one that will be after the completion of the first job.

The user, however, presumes that the system will automatically suggest a delay in such case when it was not communicated to them in the first place.

This would usually not cause any issues when it comes to manual assignment and tracking of jobs. it comes when the user wishes to run the Auto-Scheduler to get an optimized schedule.

It throws an error saying that there are some issues with the jobs and the function could not be run. The system doesn't know what issue it is because we've not catered to this edge-case scenario.

While we feel it's the user's responsibility to ensure the logical timings are entered for the Auto-scheduler to run properly, we agree that the system could have done more the inform the user about possible delays and automatically updates the timings when that happens.

The other reason is that it is currently not visually clear on the job list page when timing clash occurs, thus the user assumes that it has been taken care of. Would they have been displayed, the user could follow up to resolve the issue.

So it's one issue cascading to the other.

Proposed Solution

1st part of the solution tackles the issue when the user wishes to assign the job to a BV.

Apart from showing that there is timing clash for that BV, it will also show the earliest alongside timing for this job should the user insists to use this BV.

The user will also be informed of the delay in hours and minutes. The delay duration is important because it our mind can decipher hours and minutes better than having to calculate it when given 2 timings.

2nd part is a bit trickier.

When we were planning the screens for displaying the timing clash on the job list table, we discovered out that there are more scenarios than just having 2 RVs with different ETAs.

What if the 2 RVs have the same ETAs? What if they so coincidentally have the same required quantity?

Eventually, we came up with 4 scenarios:

1. RV1 has earlier ETA than RV2;
2. Both RVs have same ETA, but RV1's required quantity is larger than RV2's;
3. Both RVs have same ETA, but RV1's required quantity is smaller than RV2's;
4. Both RVs have the same ETA and required quantity.

Scenario 1: RV1 has earlier ETA than RV2

This is easy to tackle. RV2 will be suggested for delay in alongside:

Scenario 2: Both RVs have same ETA, but RV1's required quantity is smaller than RV2's

In this case, RV2 will be suggested for delay because it will be shorter than having to delay RV1.

RV2's estimated time to completion (ETC) will be later because it takes more time to supply a larger quantity, as compared to RV1's ETC.

However, we still provide the freedom for the user to choose otherwise:

Scenario 3: Both RVs have same ETA, but RV2's required quantity is smaller than RV2's

Then the pre-selected option will be reversed: RV1 will be suggested for delay.

Scenario 4: Both RVs have same ETA and required quantity

After some debate, we've decided for it to follow Scenario 2's flow: by suggesting to delay RV2.

The reason is that even though both these 2 jobs are having same ETA, how it's displayed on the job list table is by which job was added into the system earlier.

Constraints

What was left out from this problem statement is what happens if the user adds in a job with an earlier ETA, one that will overlap with the later job when assigned to that same BV that's been assigned to it.

We will think about this scenario next, while we send this proposed solution off to Client G for their feedback.

Was busy working on a main issue today:

Client G's bunker balance calculation issue.

Client G's bunker balance calculation issue

After each bunkering job, the user have to key in the actual bunker being supplied to the receiving vessel (RV), and system will calculate the balance bunker that's remaining on the supplying vessel, or, as we usually call it, bunker vessel (BV).

How system calculates the balance bunker is that it will do a lookup on the previous job of this BV, retrieve its balance bunker from it, and deduct it from the current job's actual quantity supplied to derive the number.

It's all fine and dandy if, we usually assumed, the user keys in the data in chronological order, meaning the user will key the data from the earliest job to the latest one.

But if they don't follow the sequence of jobs, the calculated balance will be incorrect.

For example, the quantity and balance for a 12:00hrs job A (entered later) was 1,000 metric tonne (MT) and 1,234 MT, and the quantity and balanace for a 18:00hrs job B (entered earlier) was 1,200MT and 1,034MT.

Visually, you can already tell something was off. The balance of job B is clearly incorrect: 1,234MT (balance of job A) minus 1,200MT (quantity supplied for job B) will give you 34MT. And not 1,034MT.

Well, yesterday, the user did just that. They first keyed in the details for a 09:00am job, then followed by a 03:00am job, and discovered that the scenario explained above has happened.

Of course, a point to consider was that they missed out entering the earlier job and the form was discovered later. Thus the incorrect sequence.

The raised up this issue and after investigation, we concluded that it was the sequence of entering the job details that caused the bug. We even provided a solution as remedy.

To our surprise, they did not buy our reasoning, and said that it was the system's responsibility to make sure the balance calculation is correct regardless of sequence. They use excel software as an example, saying that the balance column will always be correct in anyways:

For our case, when the job details are keyed in and saved, they are all saved as absolute values to the DB. There are no equation for any fields that would allow data manipulation in the the DB.

But looking at the user's point of view, we can empathize that it was not on purpose but more of the nature of the job that they themselves might not receive the details in sequence, only to receive them later for data entry.

Current Solution and Challanges

In fact, this recalculation function exists but it requires the user to click on the button for each job that needs to do so.

For example, if there are 10 jobs after that earlier job which I just entered, I need to go into each of those 10 jobs to click the button.

It takes 5 mouse clicks to reach the button, which means 50 mouse clicks for 10 jobs. It just does not scale. We released it just the same because we were not so sure of the repercussions if we opt for the automatic mode.

Proposed Solution

In order to fulfil our own system data integrity and also provide a streamlined user workflow to recalculate the balance, we proposed to allow user to first do the data entry, regardless of the sequence, and then allow the user to process the recalculation for all jobs within a daterange with minimal steps.

I started to work on the screens of the proposed solution to flesh out how we envisioned it to be and to show it to the client G for feedback before development.

We start by having a alert bar once there's balance mismatches after the data entry:

Once the user clicks on that "Run Recal Process" button, a popup modal will appear to allow user to select the date for the function to start running from:

When user click "Recalculate", the function will retrieve all the jobs within the daterange and go through each of them to generate the new balance.

Once the process is completed, the modal will resize, update its content and display the results for the user to review:

By grouping the jobs in chronologically for each BVs, the user can easily review the bunker balance for each of them.

Initially, our idea is to display them ungrouped, but we realised that the user would need to scroll up and down the list in order to review each BV. I.e. after reaching the bottom of the list for BV 1, the user needs to scroll back up and repeat the process for BV 2, and then BV 3, etc..

Finally, we did screen recording to walk through the entire flow using Loom, sent it to our product manager for review before firing it off to Client G.

I came across stashaway.com while listening to a investing podcast called The Financial Coconut.

Essentially, StashAway is "an intelligent wealth management platform that's designed to build and protect" the investors' wealth who parked their money with them.

I overheard that their UI is quite user-friendly and minimalistic, thus I signed up for an account with them so I can access and explore the system.

At the same time, I would like to make a little practise to mock up the system with as many sections as I can with my access rights and no money deposited.

While I signed up using the app, I accessed the system on the desktop via the browser. I've made screenshots for the sign up flow but have yet to mock them up.

Below are the desktop mockups which I made in Figma.

Login / Signup

Their login and sign up page is truly minimalist, with all the essential components displayed:

More and more Singapore apps are providing users with the ability to sign up using MyInfo and allowing them to access certain details of the user's profile. This saves time rather significantly by auto-populating those fields such full name, identification number, DOB, etc...

When the user selects the MyInfo option they will be brought to another government app called SingPass for user verification and access right permission granting.

The user verifies via SMS OTP, password or fingerprint, and a path is connected between StashAway and the user details.

I can see that this app forgoes the option for user to sign up/login using via FB, Google or Apple. I'm guessing it's for security reason in case any of those social media accounts are being hacked into.

So is the option to "remember" the user's login credentials.

Password Reset

After the user resets their password, an OTP is sent to the user's SMS for 2nd verification. If the OTP code is incorrect or the user clicks "Cancel", the reset operation will be terminated.

Homepage (Portfolios)

The top nav section is in their primary dark blue, which coolors.co refer as "Oxford Blue", followed by the greetings.

The main content section is a "3/4 + 1/4" column with lots of whitespace, and they are using Cards with muted background as primary mode of displaying content and CTAs.

CTA buttons are in all green (or "Verdigris" according to Coolors), including the chevron arrows for clicking to view more details about each card. That includes the text links so there's no recognitive load on the users part to guess if something is a link or not.

If it's green, its clickable. 🤟

Performance Page

Graphs are displayed with the Oxford Blue which creates a good contrast with the other cards.

What's exceptionally interesting for me is the dropdown, which has both "light" and "dark" shadow simultaneously:

The "light" shadow makes the dropdown glow against the dark background which the "dark" shadow allows it to float above the light background.

That's all I have to share today. Till next time, cya!