Building the driver-side app for India’s largest ambulance service provider

My Role

Outcome

Context

Existing situation

• R is India’s largest ambulance service provider. However, the ambulance dispatch work happens mostly offline.

  All communications to drivers and customers happen via SMS with embedded web-links.

• The design goals were to:
  • create a seamless experience for patients and drivers/team by automating the ambulance dispatch process.
  • reduce TAT (call-to-dispatch time)
  • enable seamless communication to all necessary stakeholders

Problem statement

Success criteria

An aesthetic and usable mobile app for R’s ambulance drivers that would solve problems pertaining to the following metrics:

Team

• 1 Senior UX designer (me)
• 1 Senior visual designer

Time

4 months (1.5 months for discovery & 2.5 months for execution)

Discovery & research

Discovery sessions with stakeholders

We conducted 5 discovery sessions with R’s business & product teams to get to know the users better.

Target demographic for MVP

Primary Audience – R-managed ALS (advanced life support) & BLS (basic life support) ambulance drivers

Secondary Audience – 3rd party BLS ambulance drivers (partner-ambulances)

• Age group: 20–50
• Location: Tier 1 & tier 2 cities
• Languages: English, Hindi, Telugu, Tamil, Marathi, Urdu

We uncovered the primary user’s goals, motivations, needs, and pain points.

Over the next discovery sessions with the stakeholders from R, we conducted similar exercises for the other core user-types: customers, and consumers.

Business pain-points

We realised 3 core challenges that the business was facing. Some of these were firm constraints we had to work around, while others had possibilities of restructuring:

• Healthcare sector has many regulations that we also need to integrate and take into account.
• Emergency, non-emergency, scheduled & non-scheduled cases have different & complex handling processes/protocols.
• Overcoming technological & development constraints to ensure up-time stability and performance reliability.
• All possible kinds of edge cases needed to be taken into consideration

Through these extensive discovery sessions we realised the ideal business goals that R’s stakeholders hope to achieve from this exercise:

Field research and interviews

We travelled to Hyderabad to have interviews with the users in their live setting. We interviewed:

1. R’s ALS ambulance drivers
2. 3rd party BLS ambulance drivers

We also spoke to the following users for clarity on delight and distress across various relevant touch-points

1. Fleet manager
2. ALS ambulance paramedics
3. R’s partner-ER doctor
4. R’s command centers
   1. operations team & dispatch team
   2. inbound team at hospital kiosk

The observations recorded in these interviews were synthesised.

Observations → Insight(s) derived → HMWs (How might we) → Associated flow (for relevant action to be taken on)

For R’s drivers:

For 3rd-party drivers:

Problem definition

The core problem statement for the MVP of the driver app was defined

Once we dived deeper, we unearthed 4 main themes – ‘Problem Areas’:

1. Driver status
2. Vehicle (& equipment) status
3. Communications
4. Help & support

All further detailed problem statements could be traced back to one or more of these 4 ‘Problem Areas’. Here are our detailed problem statements for R:

How might we ensure that all requirements are captured and passed on accurately?
[Communications + Vehicle status]

How might we ensure that requirements are met before the journey is initiated?
[Communications + Driver status]

How might we optimise the payment-collection process from patients / attenders for R drivers?
[Communications]

How might we reduce manual intervention by the drivers to convey information to all concerned stakeholders?
[Driver status + Communications]

How might we ensure complete visibility of trip status to all concerned stakeholders?
[Communications + Help & support]

How might we minimise chances of vehicular and / or equipment-related issues while on trips?
[Help & support + Vehicle status + Communications]

How might we leverage technology to reduce manual intervention in daily admin tasks (like attendance, fueling and maintaining vehicle & equipment)?
[Communications + Help & support]

How might we ensure drivers’ quick and easy access to requisite life-support “add-ons” at all times?
[Vehicle status + Communications]

Design process

Feature ideation & definition

We had brainstorming sessions with R’s product team to define an ideal feature set for the driver app, which we then grouped, and filtered down based on their necessity for the MVP stage.

Based on the ideation, we defined an exhaustive feature list for R’s driver-side mobile app MVP, and categorised them into relevant buckets:

The following features were marked as out-of-scope:

• Redesign of the webpage that patients/attenders receive
• Ability for 3rd party drivers to access and use the driver application
• Ability for potential candidates to convert to employed R drivers through the application
• Revenue-generation through the driver app

User flows

Based on our understanding of the key touchpoints, we created feature-based in-app flows for R’s drivers attuned to their real-life ambulance trips.

We conducted this exercise in 2 phases, so as to not lose the benefits of the 3 amalgamated methods:

• Phase 1

  We defined block diagrams to understand the breadth of each feature according to the user journeys

  

• Phase 2

  Based on the block diagrams, we defined detailed flow charts to realise the depth of technicality within sub-features

  

Screens

Based on the task flows, we started creating wireframes of the app-screens.

The home view in particular was up for debate for a long time, and went through several iterations.

1️⃣ In iteration 1, we created a rough structure to base our refinements and optimisations on.

This was a crude layout without much thought for visuals – this barebones structure created the foundation for us to improve on, with respect to:

• prioritising features
• prioritising content

2️⃣ Iteration 2 led us in a different direction for both – the features & the content.

We de-prioritised certain features for the MVP due to technical feasibility, and brought more important & quickly actionable content to the forefront.

3️⃣ In iteration 3, we got to stable grounds.

We settled on the overall directions for:

• online/offline mechanism
• content & layout

4️⃣ Iteration 4 was done directly on the visual side of things, because by then the visual designer had defined the visual language for the app.

Within iteration 4, there were multiple variations created for the “You’re online” state – specifically the CTA design to go offline.

The reason we didn’t recommend any of the “Not recommended” ones is because that CTA would be entry-point to not just going offline. All possible events from that CTA are:

1. Personal break (time off for activities like meal breaks, washroom breaks)
2. Official break (time off for re-fuelling and maintenance of vehicle/medical equipment in the vehicle)
3. End shift (the official happy-state for going offline)

Also, going offline is not actively encouraged considering the nature of the drivers’ job. Hence, a subtle CTA was the proposed way forward.

5️⃣ With iteration 5, the clients and us eventually finalised on the initial approach of the chevron facing right as the label for the CTA.

Also, we realised that all R employees have their photos taken and maintained digitally – mandatorily – as part of onboarding for security reasons. So, we leveraged that to replace the icons denoting the team personnel.

And we also introduced dark mode for the same, to prevent ambulance drivers from getting eye-sore after sun-down from the white theme.

Pretty much the same structure was followed by us for all other features and task flows. We went through roughly two rounds of iterations on each at the wireframes’ stage, followed by a maximum of two rounds of iterations at the visuals’ stage.

A noteworthy addition to improve user experience we did to the mobile app was that it would collapse into a FAB (floating action button) once it was closed.

This would come in very handy for certain critical situations like:

• New incoming trip
• Update in pick-up location
• Update in drop-off location

Offline mode

Another interesting approach undertaken was “Offline Mode” – we did not want a lack of internet connectivity to disrupt emergency medical services at any cost.

To that extent we conducted secondary research and convinced the client to build offline capabilities – from both POVs – design & development.

We studied best-practices across platforms and across domains, and took the learnings to the R’s driver-side mobile app.

Every feature of the app was designed and developed to work perfectly fine, offline.

All it would need is to fetch certain internet-dependent data like addresses. At the end even the bill payment and rating procedure could be handled offline. Once the internet connection was re-established, all updates would be pushed to the server.

Dev audit

Extensive design QA was conducted for all the developed screens.

Over 200 bugs and incongruencies were fixed during this period.

However, the client-engagement ended before they reached the end of their development phase.

Retrospective

What went well?

• We were able to smoothly adjust our design process to accommodate the constraints that came with this project
• We were able to transform the ambulance-service landscape with the first of its kind mobile app for drivers
• We restructured the inefficient processes in medical emergency management and designed a scalable and efficient system for the same
• Crafted a milestone-based life support delivery system that ensures complete peace of mind for the patients and attenders with respect to ambulances – giving them one less thing to be anxious about

What could have been done differently?

I recently came across a unique toggle switch made purely in CSS on Codepen, and the online/offline switcher for the driver app came to my mind.

Of course this exact structure would work only for recording areas with an upper time limit.

For time-limit-independent display it can simply be a beacon in the on-state.

Key learnings for future projects

• Learning from “Offline mode”: Simply telling the clients about what we believe and backing it with secondary research is not as helpful, as also telling them how important business metrics would be positively impacted by our intervention
• Emergency service projects are a big end-to-end “Critical Incident” in themselves, and should be treated with tremendous responsibility

Thank you for reading! 🤍