Reducing 1 week's worth of effort into hours of roster planning through automation feedback
Timeline

2 months

COLLABORATORS

1 Engineer
1 Product Manager
1 Design manager

CONSTRAINTS

Scarce engineering bandwidth
User testing opportunities

MY ROLE

Leading design, research and motion for feature discovery from 0 -> 1

As the sole designer onboard, I owned the design of the product – working closely with a Product Manager, an engineer, and with support from my manager. My team was also working in this product at a part time capacity, which affected product decisions and directions.

IMPACT OF DESIGN SOLUTION

Impact on time and effort for roster planners

From a power user –

"1 week’s worth of time can be reduced to 5 hours – 2 hours for inputting on Roster Monster, 3 hours on my spreadsheet.”

– Roster planner from Emergency Medicine Department, Singapore General Hospital

CONTEXT

What is a roster? Who is a roster planner?  

Roster

A roster is a schedule or list that outlines the assignment of tasks, shifts, or responsibilities for a group of people.

Roster planner

A person that uses tools/systems to manage and organize employee schedules/rosters.
‍

Rosters are governed by algorithms, and logical "rules"to follow
A B2B roster generation tool for public sector roster planners in Singapore

Roster monster helps roster planners in the public sector create a first draft of a roster more efficiently. The algorithm takes into consideration a set of rules, scheduled shifts and staff requests, which roster planners set-up manually.

Why such a product/solution?

In public sectors such as healthcare, roster planning can be highly complex, time consuming, and mentally draining. Enterprise software and solutions are costly, and not flexible enough for roster planning. To further justify these as a designer on the product:

Business goals

Save time and business costs on enterprise softwares, allowing roster planners to focus on more / other important work.

Design goals

Reduce the human errors from manual rostering whilst giving enough clarity to the automated processes.

HIGHER LEVEL PROBLEM

Roster planners don’t have visibility and insight into the fairness of the roster, generated by the machine.

When a normally manual process is automated, roster planners lose the insight to easily identifiable information into how tradeoffs are made.

Manual, time consuming workarounds when evaluating if a generated roster is good and fair enough for the staff rostered.

The automation process leaves the roster planner completely out of the loop when creating a roster.



THE DESIGN SOLUTION

A generated roster summary view of rule violations

Roster planners can now look, identify, and assess the severity of roster planner defined rules (constraints) that have not been met in the generated roster.

In addition to the summary view, I added transparency to the generation time, time estimate, and a simple loading animation, exported as a Lottie file.

RESEARCH -> PROBLEM FRAMING

How might roster planners evaluate whether a roster is ‘good enough’ based on rules?

One of the insights we discovered was what information regarding rules was important to see.

Example use case:

If roster isn’t able to fulfill a ‘20 staff per day’ rule, a roster planner would need to know where (i.e. Monday) and degree (i.e. only 18 staff were rostered).

Roster planners needed 3 types of rule information to evaluate the generated roster

I led semi structured interviews to further understand this process with various government stakeholders.

DESIGN EXPLORATION – CONCEPT TESTING

Various concepts that leveraged both familiar and different workflows to evaluate a ‘good enough’ roster

I explored 3 different concepts and high level scenarios without getting too deep into the UI.

What if you could see the rule violation directly on the roster?

Visual, hover interaction

What if you could see the rule violation directly on the quota statistics page?

Hover interaction

What if there was a summary of rule violations?

Drawer modal

Finding an 'MVP' concept to work on first

Roster planners liked the summary view the most, but it was also important to see the roster in view.

FEATURE SCOPING, PRODUCT ROADMAPPING

Will building this feature amongst others move the needle? 

As I was the only full time designer onboard, I needed to justify with my engineer that the feature was worth pushing out after the research and design I would be undergoing.

Hearing the user challenges through interviews and our feedback loop helped me justify the decision (with good confidence) to push for a high impact, high effort feature.

DESIGN DETAIL CONSIDERATIONS

Focusing on the most important, relevant rule violation information

For example, if a roster isn’t able to fulfill a ‘20 staff per day’ rule, a roster planner would need to know where (i.e. Monday) and degree (i.e. only 18 staff were rostered).

Some key insights from the usability tests:
‍

No table headers look, feels cleaner.

Table header information was not relevant and took up unnecessary space to roster planners.

Accordion helps with showing relevant info.

Accordion worked well as intended, allowing focus on specific rule violations.

Info hierarchy can be a bit tough to navigate.

Grids helped, already quite a lot of text to process. Hierarchy was not as clear.

INTERACTION DESIGN CONSIDERATIONS

Maximising the view for roster planners

During a testing session, I noted that a roster planner would ideally like to see both the roster and the drawer summary for reference. This meant hiding irrelevant information, such as hiding sidebar by default.

HIGHER LEVEL DESIGN FLOW, EDGE CASES

Bringing clarity to the backend roster generation process

Generating a roster can take up to 5 minutes, conveyed through the spinning circle of death. I spared an hour to quickly create a pop-up modal with a simple animation using After Effects and additional copywriting, which my engineer could easily implement in minutes.

Final iteration - added transparency to the generation time, time estimate, and a simple loading animation.

THOUGHTS, REFLECTION

Learnings

Catering to everyone meant catering to no one

During the initial part of my internship, we faced a lot of issues during testing and research of people not understanding our product. Upon reflection, this taught me to be judicious about what and who to prioritise for. In this case, we decided to focus on tech savvy roster planners for the time being.

Conducting group design critiques when it's hard to hear directly from users

Often times hearing from the user is ideal, but I don't always have access to them especially with a small user base. I learnt how to prepare and present my work amongst designers which gave me invaluable feedback on explorations, design details, and other considerations. This taught me to organise types of feedback given and build confidence to share designs in various types of fidelity.

Email ↗Linkedin ↗Read.cv ↗