Existing feedback experience

Design Tenets

Contextual. We enable users to provide feedback in the context of their experience—as close to the event or issue as possible.

Assistive. The platform is being developed to serve our drivers, not us. Our primary focus is always to be helpful to drivers verses them helping us.

Lightweight. Providing feedback must be low friction for the drivers and must not obstruct them from completing their route. Providing feedback must be safe, quick, simple, and optional. We will not ask drivers to provide data that can be collected other ways.

Transparent. Follow-up and close the loop with drivers as quickly and with as much detail as possible.

Reusable. Internal teams can use the infrastructure and design system components to quickly setup a feedback mechanisms for any data type.

Creating a scalable Feedback SYstem

Experience blueprint

I took the user experience and broke it down into four basic parts. Iterating on each step, I worked to solve known pain points and evaluated each concept against our design tenets. I developed guidelines for how the platform would behave and guardrails for onboarding feature teams. The system used standard components from our existing design system, however, new components and patterns were also created and contributed back to the design system.

Multiple ingress options would be supported. The platform would utilize a variety of ingress options to allow drivers multiple ways to provide feedback and feature teams the ability to engage with drivers at opportune times.

• Contextual ingresses would provide feature specific access conveniently placed in context of the driver’s current workflow to enable specific data collection while reducing driver effort. For example, issues with routing or map data could be reported directly from the map interface.

• Prompted ingresses allowed feature teams to prompt a driver for explicit feedback based on a pre-determined event (ie: deviation from planned route).

• Universal ingress would allow drivers to easily access a consistent entry point to submit feedback for any reason, at any time.

Once evoked, the feedback workflow surfaces over the current screen. The bottom sheet component was created to provide a modal experience, keeping the driver in context of their current workflow. If necessary, the driver may be presented with a menu of options to drill down into the category of issue type. The need for this optional step will be determined by the information we have regarding driver intent at the time of ingress.

Data reporting would use common templates to create a consistent experience. The bottom sheet provides a secondary surface for the driver to quickly select pre-defined options, or answer structured questions detailing their pain points. At any point, the driver can close the sheet to return to their workflow or navigate back to the previous sheet.

Provide transparency for drivers and to hold ourselves accountable for providing solutions. We would provide immediate notification of submittal to the driver with the expected timeframe for resolution. Once the issue is resolved, we will close the loop with a newsfeed post to update drivers on the outcome of their submission.

applying the system

Use Case: Dog Hazards

While delivering packages, our drivers face various safety hazards and these correlate to safety incidents like dog bites. Due to lack of awareness about the presence of dogs, we are unable to mitigate the risk and prevent incidents. Prior to the new feedback platform, the dog hazard reporting process was inconvenient and time consuming. It required drivers to exit their delivery workflow and call Driver Support (avg. call time 10.08 mins).

The New Experience

Early user testing informed the the ingress placement—drivers are conditioned to go to the Help menu when they encounter problems at an address. From the Help menu they tap “Report a dog on your route”—this evokes the feedback platform’s modal experience (bottom sheet), allowing the driver to never lose sight of where they are at in the delivery workflow. With a few quick taps, they can submit feedback that a dog is present at any delivery location. Upon submission, we immediately acknowledge their feedback and automatically apply a “paw print” to the address to alert future deliver drivers (not shown here). A message is also sent to the in-app news feed to update the driver on the impact of their feedback.

If the driver selects an injury has occurred, then they are prompted to contact Amazon Emergency Helpline or Emergency Services (911).

Results

• Addresses are updated in real time. We use the “dog presence” signal to update our internal data. When future delivery drivers arrive at the address, a paw print icon is displayed along with related safety tips.

• Since the launch, we have received an average 11k dog hazard feedback per day from drivers and have taken action on 99.5% of the feedback submitted by applying paw prints. (10/2/2022-1/10/2023)

• Saves time. “I can submit with only a few taps and not waste time calling support.”

• Earning trust. “It shows some actual action resulting from my feedback.”