Where is my Order?

Why was it suddenly needed?

During the first wave of COVID-19 countries went on lockdown. This made people stay inside a lot more and shopping was suddenly not an option anymore. Naturally, e-commerce platforms saw their traffic and orders skyrocket. For Rituals it was so much that their supplying warehouse couldn’t handle the extremely high demand. The same was true for the package carriers in The Netherlands. This resulted in a lot of deliveries getting delayed or lost. Unfortunately, Rituals didn’t have a clear tracking page where customers could see the status of their orders. So a lot of the customers called customer support and they in turn became overwhelmed as well. To improve this and avoid such cases in the future, Rituals asked Hike One to figure out and design a way to reassure customers where their order is at all times of the order & delivery process. I was tasked by Hike One to work on this with a project manager from Rituals.

Known knowns & known unknowns?

The first thing I needed to assess was what was at the core of the customer’s frustrations. It’s easy to acknowledge that a delayed or lost order is a bad experience. But not diving into the problem can result in solving the wrong problem and still having frustrated customers.

I interviewed the customer support manager and two of the customer support employees. I got very similar results back, here are a few highlights from it:

The lack of updates on the order of the customer made them feel anxious and unsure. It made them think they won’t receive their order.
Customers felt confused when they received a Track&Trace and it’s not active yet (meaning they got an error page).
Multiple shipments of 1 order amplify the 2 problems above as customers want to know the status of both shipments.

The problems and needs were clear now. What I needed to know now is how the products of an order went from the warehouse or store to the customer. The image above is what I received from the technical staff at Rituals, which was a good start to work from. I processed it and simplified on what we need to learn and what we don’t know yet.

Now it was clear what the known knowns and known unknowns are. So it was time to clarify the known unknowns.

Align stakeholders to create a service blueprint

I facilitated a session with all involved parties (warehouse, carrier, order system, supply chain) in the process. My main goal was to learn at what point in the process we could communicate to the customer about the status of their order. To do so I first needed to validate the process with the involved parties and by doing so having them aligned on it.

The service blueprint that you see above was empty when I started the session. As I was asking what the next step is, I filled it in and checked with the other parties if they agree. What I got out of it is:

Validated different steps that are important in the process
Learned where the order is between steps
Time between steps
At which steps we can communicate to the customer
A visual that makes it a lot easier to talk with stakeholders about the project

Now it was time to design a prototype.

Next up user validation

When the limitations of the third parties were clear, I wrote copy for each of the steps and edge cases. This way we had a collection of messages we could use in each step.

To kick the iterative process off I started a brainstorm session with 2 stakeholders. We took those results to quickly design wireframes which in turn would be worked out by me and a designer at Rituals in visual design to have a high-fidelity prototype for testing.

I set up a test plan and created hypothesis’ which I turned into questions to get answered with the test. Afterwards I tested the prototype with 6 customer support since actual customers would be too hard to get in touch with. Luckily the customer support was very vocal and bold to point out what is/isn’t clear. If they didn’t understand it, real customers would definitely not understand it. Most of the design was very helpful and solved the problems. There were 2 crucial problems though.

1 Delays in the order weren’t clear from the get-go. While users value that as the most important piece of information.
2 They expected address information under a different section and thus couldn’t find it.

We can't have it all at once

I made an overview of the different features that we could put in WIMO. I used the MoSCoW method and facilitated a scoping session to help the project manager and technical lead to scope it down for initial release. Based on the research and testing we created a scope what would be implemented in version 1.0.

Here is your order

We integrated the feedback and worked towards the 1.0 version. Afterwards we designed the pick up at store flow and ship from store flow (instead of the default flow (ship from warehouse)). Since we didn’t work with third parties in both flows we have more control over the messaging and fewer dependencies. That made those flows easier to design later.

I designed all edge cases and checked those with developers and business analysts. In the end I documented all interactions for a clear handover.

This project was smooth from start to finish. This was mainly due to the cause, problem and solution all being quite clear from the start. We didn’t have to test if order status page has value for customers because that is proven already by other webshops all having it and was confirmed by the interviews. The main challenge was to work together with the warehouse and supply chain to know at which point we could communicate something to the customer, which information is important and what we prioritise in the design.

Ganbatte!