Discovery
The customer service team were our internal stakeholders and held huge knowledge. We collaborated regularly and unpacked the challenges they faced. Tracking requests and workshopping together.
FEBE - Lantum's internal software
Who are the protagonists we need to design for?
We identified three actors in the product discovery. Lantum customer support, rota managers and workers. All of these actors would have a role to play in the product.
Validate assumptions early
I've become agnostic to the tools I use and more focused on the outcomes not outputs. The feedback from this session was crucial in moving the project forward and validating our initial ideas.
One copy system
Copy writing is part of product design and an area I think is often overlooked. With such a complexed feature how could I keep all of the interactions up to date and let everyone have access to it? I created a Google spreadsheet as an artefact that could be accessed by developers, designers and QA. It could be worked on asynchronistically across the cross functional team.
Sequencing
Now that we knew enough and the cross functional team were aware of all of the testing and validating it was time for planning poker and walking the fine line between what not to include for V1.
V1
- Application order After talking with rota managers it was clear that they wanted to be fair with the order at which applicants were listed. First come first served so timestamps were included to help make a more informed decision when allocating shifts.
- Accepted and rejected candidates We need to expose who's been accepted but also who's been declined for a shift, it's the polite thing to do and the experience should be polite where necessary. In the event that the first candidate withdraws then the rota manager will be able to refer to the shift history and offer the rejected candidates the shift.
- Declined by default When a clinician is accepted the others will be 'automatically declined'. This needs to be communicate in the timeline as a system decision.
- Editing shifts All changes to shifts need to be documented with the person, time and action they performed. If the worker has accepted the shift then they need to be notified of the change as it could change other plans they have outside of work.
- Editing shift details with applicants attached Any edits to shifts that have applicants on remove the applicants and they have to re-apply if the shift is still in their interests. However, if the hourly rate goes up then we don't need to notify them. This was proven in user interviews to be the only acceptable edit.
- Copy system The copy system is the glue that ties everything together so this was non negotiable when it came to speccing the ticket to be done.
What we shipped
V2
I always like to plan for the future and having a V2 teed up has always been a good plan in my experience.
- Notes There is a need for rota manager to add notes and reasons why certain staff were declined so that organisations with multiple people working on the rota have the knowledge they need.
- Swaps When two clinician swap we put the one who wants to swap first and the receiver second.
- Declined by default When a clinician is accepted the others will be 'automatically declined'. This needs to be communicate in the timeline as a system decision.
- Swap declined What does this look like and how is it communicated?
- Applications with negotiations We need to be able to surface what an “negotiation” between a clinician and a manager would look like in the timeline.