My role

I was the UX/UI designer on the project end to end – shadowing drivers in the field, mapping user journeys, creating flows for both happy and unhappy paths, wireframing in Balsamiq, designing the full Android UI and conducting user testing sessions with the porters themselves.

The app was built for the Bluebird – a rugged Android handheld device with a built-in barcode scanner – and needed to work reliably in environments where hospital signal could be terrible.

Key challenges:

Challenge

Trolleys have poor wheels and a habit of drifting between groups.

A well-meaning member of staff puts a stray trolley back in what they think is the right group – but it isn’t.

The porter collects it, delivers it to the wrong hospital, and another defect gets logged.

Solution

The app notified porters if they’d scanned fewer trolleys than expected for a collection, flagging the discrepancy before they left rather than after they’d delivered to the wrong place.

Not much I could do about the wheels.

Key challenges:

Challenge

A porter arrives at a hospital with 10+ trolleys. They make 5+ trips to a sixth floor ward and back, dropping off clean trolleys and collecting dirty ones.

By the end of the shift they’re trying to remember exactly what they collected and where – and filling in paper logs from memory.

Unsurprisingly, things went wrong.

Solution

By scanning their location on arrival and scanning each trolley as they collected or delivered it, the app logged everything automatically in real time. No memory required.

After user testing, the porters’ biggest reaction was realising they didn’t need to go back to the van to fill in delivery logs – the app had already done it.

Key challenges:

Challenge

Some hospitals have terrible phone signal, and the Bluebird is a mobile device.

If the app stopped working every time signal dropped, it would be worse than the pen and paper system it was replacing.

Solution

I designed a full offline handling flow. When the device lost signal, scanned trolleys were stored in an offline list and the app continued functioning normally – making the usual success sound so porters weren’t confused.

When signal returned, the database checked the offline list for errors and duplications and notified the user if any action was needed. Seamless.

Key challenges:

Challenge

Occasionally a porter would get an urgent call mid-shift to collect a fast-tracked trolley for an emergency procedure – dropping everything and going immediately.

This was another point where trolleys could easily get mixed up.

Solution

Fast track requests pushed directly to the device as notifications, taking the porter straight to the relevant location and logging the collection separately so it didn’t get confused with their regular run.

Key challenges:

Challenge

The Bluebird devices were shared across multiple porters.

Each user had their own preferred task setup and needed to be able to switch accounts quickly without losing their personalised configuration.

Solution

I added a Change User feature in Settings that let porters switch accounts in seconds, with each user’s task preferences saved to their profile so nothing needed to be reconfigured.

Ideation:

I created two user flows – a happy path covering the standard collect and deliver process, and an unhappy path covering offline functionality and error states.

The offline path was just as important as the happy path given the signal conditions in older hospital buildings.

Happy path

After logging in, the porter lands on their personalised Tasks screen. They scan their location, then scan each trolley. Recognised trolleys are logged automatically with a success ping. Unrecognised trolleys trigger an aggressive vibration, an error sound and a blocking notification the porter must acknowledge before continuing.

Unhappy path

When signal drops, scanned trolleys are stored in an offline list. The app continues as normal – same success sounds, same behaviour – so the porter’s workflow isn’t interrupted. When signal returns, the database checks the offline list and flags any issues.

Ideation:

I produced a full flow chart giving a high-level view of the entire app – helping refine navigation logic and expected behaviour across all screens before wireframing began.

Designs:

Porters log in with their credentials on opening the app. A 10-minute inactivity timeout logs users out automatically – with a Remember Me option for longer shifts. Password expiry prompts users to update their password periodically for security.

Designs:

On arriving at a location, the porter scans the location barcode first, then scans each trolley. A success ping confirms each scan. An unrecognised trolley triggers vibration, an error sound and a blocking screen the porter must confirm before continuing.

Designs:

The contacts page populates automatically based on the porter’s shift – showing the relevant staff and delivery points for that day. If something goes wrong en route, porters can call the on-site manager or use the built-in maps to navigate around the problem.

Designs:

Porters can customise their Tasks screen by toggling jobs on and off depending on what they’re doing that shift. Phase 1 launched with Collect and Deliver, with further task types planned for later phases.

Designs:

The Locations screen showed a porter’s regular delivery points for the shift, with fast track requests pushing directly to the top as urgent notifications.

Settings:

The app was built with multilingual capability from the start – designed to support STERIS operations across multiple countries, with language selection accessible directly from Settings.

Settings:

Shared devices meant multiple porters needed to switch accounts quickly without losing their individual task preferences. The Change User feature handled this in seconds.

Settings:

A straightforward password change flow – current password, new password, confirm, save.

Outcomes: