Collect & deliver
The ‘Collect & Deliver’ app is a mobile application developed by STERIS to streamline the process of collecting and delivering trolleys (such as those used for medical instruments or supplies) between hospital facilities and a central cleaning warehouse.
My role
The plan for this project was to create a lean app-based solution to help porters in their daily job when collecting and delivering trolleys from a hospital facility to a cleaning warehouse, minimising any defects caused by human error in the process (roughly 80 defects per week!)
To do this, I looked at moving their current process of good ol’ pen and paper to a digital format. The porter would scan the clean trolleys they collected from the cleaning warehouse and drop them off at a hospital to be used, scanning their location on arrival, followed by any dirty trolleys they collected in that trip.
Key challenges:
Reduce weekly defects
Challenge
A trolley that is meant for one hospital may turn up at another. It sounds crazy, but these trolleys have poor wheels, cleaning staff tend to group trolleys together based on location ready for the porters to collect. Don’t be surprised if a trolley from one group slowly creeps away from the rest.
You only need a member of staff to notice a random trolley sitting in the corridor somewhere and they will put it back in the group where they thought it came from, but it’s actually the wrong one – et voila! Mixed up.
Solution
While I can’t do much about the dodgey wheels of a trolley unfortunately.
But by introducing methods which inform porters of how many trolleys they are expected to collect during each collection, we notify them if they have scanned less than the expected amount of trolleys – this will hopefully fix this problem.
Key challenges:
Make delivery logs simple
Challenge
The porter will generally turn up to a hospital with a van of roughly 10+ trolleys ready to hand over.
There is only one porter per van – so you would normally take 2 trolleys at a time (unless they’re really heavy). So that is 5+ trips from the van to the ward (which tends to be on the 6th floor somewhere) meaning elevator trips. This process can obviously take a long time after you’ve dropped the clean trolleys off and collected the dirty trolleys.
As well as this, the porters have to remember what they have dropped off, and what they have collected so they can fill in the delivery logs correctly – obviously, there are quite a few things that can go wrong with this, leading to quite a few discrepancies.
Solution
By tweaking the method porters currently use hopefully won’t make these changes too daunting for them.
If the porter scans their location when first entering the building, then scans each trolley they drop off and collect, it should just become muscle memory after a couple of times using the new process.
Goals
Create a lean experience for users
The app aims to help delivery drivers perform their tasks with ease and efficiency, as well as cutting out any mistakes.
Delivery drivers use a device called a Bluebird. I has a built-in scanner that allows the drivers to scan their location where they are collecting trolleys from, as well as scan any trolleys that are waiting to be collected.
Once scanned, the app notifies the facility that the trolleys have been collected and in the process of being delivered.
As well as notifying the facility, users could also view the location of the delivery van in transit due to the geolocation of the drivers phone device.
Replace pen and paper with a digital format
If there are any mistakes, a financial charge is added to the bill, this is in the hope that it will cut down mistakes going forward, but this is still happening.
By going digital, the porter scans the clean trolleys they’ve collected from the cleaning warehouse and drop them off at a hospital to be used, scanning their location on arrival, followed by any dirty trolleys they collected in that trip.
Offline handling
Some hospitals have awful phone service, and the Bluebird is a mobile device at the end of the day.
I needed to really consider handling offline situations for the device to make it obvious to the porter what is happening, and not prevent them from doing their jobs because of poor signal – if this can’t be integrated seamlessly, then it could ruin the whole project.
Research:
Shadowing
Whilst shadowing a driver for the day, I learnt about the current processes in more detail, which highlighted a few issues that the drivers have on a daily basis.
The current process involved drivers filling out sheets of paper with collection and delivery times, as well as writing down the number of trolleys they collected and where they had been collected or delivered from.
Research:
High level user journey
I created a high level user journey to help highlight the path that a porter will generally take during their shift.
This excludes any Fast-track journeys.
If the driver gets a call to come and collect a ‘Fast-tracked trolley’, they have to drop everything that they are currently doing to go collect that trolley ready for its emergency procedure. As a result of this, this is another way in that trolleys can easily get mixed up.
Ideation:
User flows
I created user flows – one happy path, and one that covered service drop out, the signal can be pretty poor in some hospitals so this needed to be carefully considered.
Happy path
After the user logs into their account, they land on the Tasks screen – this shows a personalised page relevant to the user and what tasks that they would perform on a day to day basis.
The ‘Collect’ feature, requires the user to scan the location they are collecting the trolleys from, then scan the trolleys waiting to be collected.
When scanned, the barcodes of the trolleys are checked against the database to see if it is recognised. If recognised, the trolley name and its ID gets logged to the collected list, and details are updated on the database accordingly.
If the barcode isn’t recognised, the user is then notified to take action to solve the problem. Users will be able to tell if the barcode isn’t recognised by the error noise the system makes (it’s loud!), as well as the Bluebird device vibrating in the user’s hand until the error has been acknowledged.
This process repeats until there are no more trolleys left to scan.
Unhappy path
The unhappy path covered how the app handled offline functionality.
The app talked to the database to make checks when scanning locations and trolleys, so it is vital to keep a signal.
Signal strength tends to be quite low in older facilities, so if the signal drops, the handling of this needed to be seamless, considering the importance of the trolley’s contents.
So when the user scans a trolley while the device is offline, the trolley details are stored in an ‘offline list’, and the current functionality handles the way it would normally. – making a ‘success’ noise to notify the user that a trolley has scanned.
When the signal returns – the database checks the ‘offline list’ for any trolley errors and duplications. If there are any, the app notifies the user to take action.
Design process:
Wireframes
After taking all my research and findings into account, I started creating the wireframes in Balsamiq to work towards addressing the pain points the drivers currently have, including:
Wireframes:
Login and password expiry
When the user opens the app, the first thing that they have to do is login with their credentials.
The app login had a 10minute inactivity period before it logged the user out of the app. If the user works for a longer time, the user can tap ‘Remember me’, and it will keep them signed in until they decide to log themselves out.
After logging in, the user is taken to their Task page, where they can set up, or do their daily jobs. – Phase 1, started with Collect and Deliver.
Wireframes:
Collect
When the user arrives at a location, the first thing they need to do is scan where they are collecting and delivering trolleys from.
Once they have done that, the user then starts scanning the trolleys that have been left to be collected.
The device makes a ‘ping success’ sound after every successful scan.
When a wrong trolley gets scanned, it was decided that the scanner device would give an ‘aggressive’ vibrating feel for the user and a different sounding noise to the ‘ping success’ scan.
The user also gets blocked by a notification on screen that they have to ‘Confirm and ackowledge’ before they can continue scanning trolleys again.
Wireframes:
Hospital contacts
When the driver logs into a device, it populates the contacts page with the relevant staff that are on shift at that facility, as well as the relevant delivery points.
If something goes wrong during a journey, e.g. stuck in traffic, the driver can call the manager, or use the maps to navigate around and get to the location quickly.
Most drivers have roughly 3 or 4 delivery points that they drive to throughout their shift. Sometimes there can be ad-hoc requests for Fast Track deliveries that are needed urgently. These requests notify the user and take them directly to that location straight away.
Wireframes:
Favourite tasks
The user can edit their favourites depending on what jobs they are doing throughout their shift. This updates the Task page when the user toggles each job on or off.
Wireframes:
Notifications
The notifications page shows a timestamp of the driver’s journey throughout their shift.
So when a Driver arrives at a location, they need to scan their location barcode, as well as scan trolleys that are getting delivered and trolleys that they are collecting.
Design process:
Flow chart
Creating a flow chart for the app gave me a high-level view of the whole process. Doing this helped me refine any little niggles with the expected behaviour and what pages users should navigate to when coming from specific pages.
Design process:
User testing
I conducted a user test session with the drivers to see how they got on with the new design and whether they thought it improved the issues they were having previously during their shift.
I wrote a script including a scenario asking the user to login with their account details, select a task (in this case we were just focusing on ‘Collect’), scan their location, and a couple of trolleys.
I also managed to add the prototype onto the device so it gave the drivers the impression that it was the real thing.
During the session, I watched how they interacted with the device and started scanning the barcodes. Initially they were a little wary, but soon got the hang of it.
After they completed the scenario I asked what they thought of the process. Like all loved the simplicity of it but they all felt like they needed to go back to the van to fill the delivery logs in, but obviously the process cut out the need to do anything like that so they were really pleased with how much time it saved them.
The numbers
%
Delivery defects before
%
Delivery improvement after
%
Productivity increase with app
With roughly 382 trolleys being processesd each week, and roughly 80 of them being defects. The aim was to reduce delivery defects by the drivers when collecting and delivering trolleys.
The defect rate was quite high before the project kick off, and the issue was that it wasn’t obviously where trolleys were getting delivered and what the trolley content was. So facilities received trolleys they weren’t expecting.
Developing the app allowed drivers to scan the trolleys and their location; this reduced the defects significantly and increased overall productivity because hospitals were aware of when there delivery was expected.
If there was an issue, the user would get notified by the app of the problem so they could fix the issue at the time, instead of waiting till it was being delivered at the next hospital.
Collect & deliver
The ‘Collect & Deliver’ app is a mobile application developed by STERIS to streamline the process of collecting and delivering trolleys (such as those used for medical instruments or supplies) between hospital facilities and a central cleaning warehouse.
My role
The plan for this project was to create a lean app-based solution to help porters in their daily job when collecting and delivering trolleys from a hospital facility to a cleaning warehouse, minimising any defects caused by human error in the process (roughly 80 defects per week!)
To do this, I looked at moving their current process of good ol’ pen and paper to a digital format. The porter would scan the clean trolleys they collected from the cleaning warehouse and drop them off at a hospital to be used, scanning their location on arrival, followed by any dirty trolleys they collected in that trip.
Key challenges:
Reduce weekly defects
Challenge
A trolley that is meant for one hospital may turn up at another. It sounds crazy, but these trolleys have poor wheels, cleaning staff tend to group trolleys together based on location ready for the porters to collect. Don’t be surprised if a trolley from one group slowly creeps away from the rest.
You only need a member of staff to notice a random trolley sitting in the corridor somewhere and they will put it back in the group where they thought it came from, but it’s actually the wrong one – et voila! Mixed up.
Solution
While I can’t do much about the dodgey wheels of a trolley unfortunately.
But by introducing methods which inform porters of how many trolleys they are expected to collect during each collection, we notify them if they have scanned less than the expected amount of trolleys – this will hopefully fix this problem.
Key challenges:
Make delivery logs simple
Challenge
The porter will generally turn up to a hospital with a van of roughly 10+ trolleys ready to hand over.
There is only one porter per van – so you would normally take 2 trolleys at a time (unless they’re really heavy). So that is 5+ trips from the van to the ward (which tends to be on the 6th floor somewhere) meaning elevator trips. This process can obviously take a long time after you’ve dropped the clean trolleys off and collected the dirty trolleys.
As well as this, the porters have to remember what they have dropped off, and what they have collected so they can fill in the delivery logs correctly – obviously, there are quite a few things that can go wrong with this, leading to quite a few discrepancies.
Solution
By tweaking the method porters currently use hopefully won’t make these changes too daunting for them.
If the porter scans their location when first entering the building, then scans each trolley they drop off and collect, it should just become muscle memory after a couple of times using the new process.
Goals
Create a lean experience for users
The app aims to help delivery drivers perform their tasks with ease and efficiency, as well as cutting out any mistakes.
Delivery drivers use a device called a Bluebird. I has a built-in scanner that allows the drivers to scan their location where they are collecting trolleys from, as well as scan any trolleys that are waiting to be collected.
Once scanned, the app notifies the facility that the trolleys have been collected and in the process of being delivered.
As well as notifying the facility, users could also view the location of the delivery van in transit due to the geolocation of the drivers phone device.
Replace pen and paper with a digital format
If there are any mistakes, a financial charge is added to the bill, this is in the hope that it will cut down mistakes going forward, but this is still happening.
By going digital, the porter scans the clean trolleys they’ve collected from the cleaning warehouse and drop them off at a hospital to be used, scanning their location on arrival, followed by any dirty trolleys they collected in that trip.
Offline handling
Some hospitals have awful phone service, and the Bluebird is a mobile device at the end of the day.
I needed to really consider handling offline situations for the device to make it obvious to the porter what is happening, and not prevent them from doing their jobs because of poor signal – if this can’t be integrated seamlessly, then it could ruin the whole project.
Research:
Shadowing
Whilst shadowing a driver for the day, I learnt about the current processes in more detail, which highlighted a few issues that the drivers have on a daily basis.
The current process involved drivers filling out sheets of paper with collection and delivery times, as well as writing down the number of trolleys they collected and where they had been collected or delivered from.
Research:
High level user journey
I created a high level user journey to help highlight the path that a porter will generally take during their shift.
This excludes any Fast-track journeys.
If the driver gets a call to come and collect a ‘Fast-tracked trolley’, they have to drop everything that they are currently doing to go collect that trolley ready for its emergency procedure. As a result of this, this is another way in that trolleys can easily get mixed up.
Design process:
User flows
I created user flows – one happy path, and one that covered service drop out, the signal can be pretty poor in some hospitals so this needed to be carefully considered.
Happy path
After the user logs into their account, they land on the Tasks screen – this shows a personalised page relevant to the user and what tasks that they would perform on a day to day basis.
The ‘Collect’ feature, requires the user to scan the location they are collecting the trolleys from, then scan the trolleys waiting to be collected.
When scanned, the barcodes of the trolleys are checked against the database to see if it is recognised. If recognised, the trolley name and its ID gets logged to the collected list, and details are updated on the database accordingly.
If the barcode isn’t recognised, the user is then notified to take action to solve the problem. Users will be able to tell if the barcode isn’t recognised by the error noise the system makes (it’s loud!), as well as the Bluebird device vibrating in the user’s hand until the error has been acknowledged.
This process repeats until there are no more trolleys left to scan.
Unhappy path
The unhappy path covered how the app handled offline functionality.
The app talked to the database to make checks when scanning locations and trolleys, so it is vital to keep a signal.
Signal strength tends to be quite low in older facilities, so if the signal drops, the handling of this needed to be seamless, considering the importance of the trolley’s contents.
So when the user scans a trolley while the device is offline, the trolley details are stored in an ‘offline list’, and the current functionality handles the way it would normally. – making a ‘success’ noise to notify the user that a trolley has scanned.
When the signal returns – the database checks the ‘offline list’ for any trolley errors and duplications. If there are any, the app notifies the user to take action.
Design process:
Wireframes
After taking all my research and findings into account, I started creating the wireframes in Balsamiq to work towards addressing the pain points the drivers currently have, including:
Wireframes:
Login and password expiry
When the user opens the app, the first thing that they have to do is login with their credentials.
The app login had a 10minute inactivity period before it logged the user out of the app. If the user works for a longer time, the user can tap ‘Remember me’, and it will keep them signed in until they decide to log themselves out.
After logging in, the user is taken to their Task page, where they can set up, or do their daily jobs. – Phase 1, started with Collect and Deliver.
Wireframes:
Collect
When the user arrives at a location, the first thing they need to do is scan where they are collecting and delivering trolleys from.
Once they have done that, the user then starts scanning the trolleys that have been left to be collected.
The device makes a ‘ping success’ sound after every successful scan.
When a wrong trolley gets scanned, it was decided that the scanner device would give an ‘aggressive’ vibrating feel for the user and a different sounding noise to the ‘ping success’ scan.
The user also gets blocked by a notification on screen that they have to ‘Confirm and ackowledge’ before they can continue scanning trolleys again.
Wireframes:
Hospital contacts
When the driver logs into a device, it populates the contacts page with the relevant staff that are on shift at that facility, as well as the relevant delivery points.
If something goes wrong during a journey, e.g. stuck in traffic, the driver can call the manager, or use the maps to navigate around and get to the location quickly.
Most drivers have roughly 3 or 4 delivery points that they drive to throughout their shift. Sometimes there can be ad-hoc requests for Fast Track deliveries that are needed urgently. These requests notify the user and take them directly to that location straight away.
Wireframes:
Favourite tasks
The user can edit their favourites depending on what jobs they are doing throughout their shift. This updates the Task page when the user toggles each job on or off.
Wireframes:
Notifications
The notifications page shows a timestamp of the driver’s journey throughout their shift.
So when a Driver arrives at a location, they need to scan their location barcode, as well as scan trolleys that are getting delivered and trolleys that they are collecting.
Design process:
Flow chart
Creating a flow chart for the app gave me a high-level view of the whole process. Doing this helped me refine any little niggles with the expected behaviour and what pages users should navigate to when coming from specific pages.
Design process:
User testing
I conducted a user test session with the drivers to see how they got on with the new design and whether they thought it improved the issues they were having previously during their shift.
I wrote a script including a scenario asking the user to login with their account details, select a task (in this case we were just focusing on ‘Collect’), scan their location, and a couple of trolleys.
I also managed to add the prototype onto the device so it gave the drivers the impression that it was the real thing.
During the session, I watched how they interacted with the device and started scanning the barcodes. Initially they were a little wary, but soon got the hang of it.
After they completed the scenario I asked what they thought of the process. Like all loved the simplicity of it but they all felt like they needed to go back to the van to fill the delivery logs in, but obviously the process cut out the need to do anything like that so they were really pleased with how much time it saved them.
The numbers
%
Delivery defects before
%
Delivery improvement after
%
Productivity increase with app
With roughly 382 trolleys being processesd each week, and roughly 80 of them being defects. The aim was to reduce delivery defects by the drivers when collecting and delivering trolleys.
The defect rate was quite high before the project kick off, and the issue was that it wasn’t obviously where trolleys were getting delivered and what the trolley content was. So facilities received trolleys they weren’t expecting.
Developing the app allowed drivers to scan the trolleys and their location; this reduced the defects significantly and increased overall productivity because hospitals were aware of when there delivery was expected.
If there was an issue, the user would get notified by the app of the problem so they could fix the issue at the time, instead of waiting till it was being delivered at the next hospital.