Warning: The magic method WP_Hotjar::__wakeup() must have public visibility in /customers/7/9/6/craigcottingham.co.uk/httpd.www/wp-content/plugins/hotjar/hotjar.php on line 50 Warning: Cannot modify header information - headers already sent by (output started at /customers/7/9/6/craigcottingham.co.uk/httpd.www/wp-content/plugins/hotjar/hotjar.php:50) in /customers/7/9/6/craigcottingham.co.uk/httpd.www/wp-content/plugins/onecom-vcache/vcaching.php on line 716 STERIS Collect & Deliver UX » Craig Cottingham: UX & UI Designer

user experience /

STERIS 
COLLECT & DELIVER

the problem

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.

TEAM

1x Business analyst
2x Developers

My role

User research  //  User flows  //  Wireframes  //  Visual design  //  Prototyping  //  Testing

Exploration

The app aims to help delivery drivers perform their tasks with ease and efficiency, as well as cutting out any mistakes.

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.

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.

Insights

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 day to day basis.

Trolleys getting mixed up

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.

Fast-tracked trolleys

If the driver gets a call to come and collect a ‘Fast-tracked trolley’, they literally 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.

Completing delivery logs

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.

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. (excluding any Fast-track journeys)

Product Features

Delivery drivers use a device called a Bluebird. It has a built-in scanner that allows drivers to scan their location where they are collecting trolleys from, as well as scan any trolleys that waiting for collection.

Once scanned, the app notified the facility the trolleys were collected, and they are getting 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 delivery drivers phone device.

Lean UX process

Native Google Design

Geo-location tracking

Offline handling

Ideation Process

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.

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.

I mocked up some basic wireframes to help gather feedback from the drivers on the overall flow and layout whilst also considering the following:

Make the process as lean as possible to minimise completion time

Making visuals as intuitive and easy to understand as possible

Accommodating technophobes - I don't want to isolate older folk

Login & 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.

Login design flow (1 of 3)
Login design flow - enter user details (2 of 3)
Login design flow - enter details (3 of 3)
Login design flow (1 of 3)
Login design flow - enter user details (2 of 3)
Login design flow - enter details (3 of 3)

Collect

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.

Login design flow (1 of 3)
Login design flow - enter user details (2 of 3)
Login design flow - enter details (3 of 3)
Login design flow - enter user details (2 of 3)
Login design flow - enter details (3 of 3)

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.

Login design flow (1 of 3)
Login design flow - enter user details (2 of 3)
Login design flow - enter details (3 of 3)

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.

Login design flow (1 of 3)
Login design flow - enter user details (2 of 3)
Login design flow - enter details (3 of 3)

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.

Login design flow - enter user details (2 of 3)
Login design flow - enter details (3 of 3)

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.

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

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 trolleys weren’t obvious where they 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 their delivery was expected. If there were an issue, the user would get notified by the app that there was a problem.

  • Defect Rate (Without app) – 79%
  • Defect Rate (With App) – 100%
  • Productivity increased (With app) – 44%

CURRENT TROLLEYS PROCESSED A WEEk

TROLLEY DEFECTS A WEEK (WITHOUT APP)

TROLLEY DEFECTS A WEEK (WITH APP)

%

PRODUCTIVITY INCREASED