24-03-21 Entry: Discussion on User Experience of AS Feature

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.