Where’s my order?
Lyst has one of the largest selections of fashion in the world. We have achieved this scale by holding no stock. When people buy on Lyst, they are really buying from one of thousands of fashion stores.
This has its benefits, but it comes with problems too. The most common question our customer care team receives is, “Where’s my order?” These customers were struggling to understand what was happening after they made a purchase through Lyst.
This case study is about how we tried to address this issue, showing some of the process that went into it and how we approached research without a researcher.
For a while, people had been contacting Lyst to ask what was happening with their order. It wasn’t until the opening of 2017, when we sat down to talk with our customer care team, that we realised this was now creating thousands of enquiries highlighting that there was a larger problem to explore.
Reading into the customer support enquiries a few themes began to emerge. To explore these themes and get to the root of the problem we looked deeper into the kind of experience people were really having post purchase.
So, the problems
After reviewing the existing experience, the emails we’d received and the reviews of the experience we had a good idea of what the problems were.
- There is no holistic overview of what’s happening with an order, leaving customers guessing.
- Customers don’t know who is responsible for fulfilling what.
- The existing ‘solutions’ we had in place just weren’t good enough for customers and they end up having to contact customer care.
Or in the words of a customer…
“I want to know what’s happening with my order but I don’t know where to look to find out.”
Where do we go from here?
Having assessed the problems it was clear to us that we should be focussing on providing a single point of reference for their order, providing clarity around the process and instilling trust in the customer.
Given a lack of time we decided to move forward and design an order history. This is a common pattern amongst almost all of our partners so we felt confident moving forward with this rather than needlessly reinventing the wheel.
What makes a good order history?
With it decided that we wanted to keep things simple and leverage an existing pattern we then needed to find out what makes a good order history. To do this we used a mix of methods; competitor analysis, talking to friends & family & our knowledge of how people use Lyst.
First, keeping with spirit of not reinventing the wheel we knew we could learn a lot about what people have become accustomed to from looking at our competitors. In particular, we were interested in the kinds of information they included in their order history.
With this we then asked friends and family to sort the different types of information from the most to least important. We ran this with friends and family as a proxy for real research participants.
Ideally, we’d have done actual user testing with real scenarios trialling various hierarchies of information rather than just asking people. However, we had neither the time nor resources to go beyond this during this project.
The most useful thing we did was look into all the possible pain points in the current experience and think through the potential emotional consequences for the customer. Whilst this isn’t the same as speaking to real people, it did allow us to focus on what the role of an order history could be in these circumstances.
Why was this the most useful?
We could have looked at the usage data on our existing solution. This would show us that most people want to view delivery timings. This is obviously still important to us but it’s not those customers that are struggling with their order, nor needing to contact customer care.
With an idea of what’s important in resolving people’s problems, we were ready to move forward and start creating something real.
Turning what we learned into something tangible
We started with a series of sketches, refining them through continuous iteration with the team before turning them into wireframes. Here we could begin to work on the intricacies of the messaging and interactions.
Given our original problems stemmed from a lack of clarity it was really important to us that we had one clear message coming through to customers for each of the potential scenarios.
Even without a researcher it’s still possible to test. We iterated through tons of different messaging whilst testing with friends and family to make sure that we managed to communicate exactly what we needed to.
Learning from the launch
We launched this alongside an overhaul of our help centre. The combined impact of these projects resulted in a significant drop in order related issues being received by our customer care team. 🎉
However, from this we learned how we would have been better to launch each of these separately. It would have allowed us to measure each projects impact independently meaning we could better understand how helpful it really was to our customers.
What else did we learn?
- Being coherent is key. One of the biggest downfalls of our old solution was that customers were continuously passed from one company to another, none of which acknowledged the roles of the others.
- Emotions matter. In a world of ‘data driven’ projects, it can be easy to forget how people are feeling when they interact with your designs.
For this project, the customers emotions gave us a completely different perspective to what our data would have told us. - It’s the little things. We as designers spend so much time working on projects that’ll really ‘push the needle’ that it can become difficult to make a case for projects like this.
But, fixing these things does matter. It may not be the most visited part of the app, nor the most exciting but to those who need it, it becomes super important.
