Let's set the scene
So, at N26, a big digital bank, most of our customer support happens through our in-app chat. This case study is all about a project I worked on to make that chat experience better by being more transparent about when our support agents were actually available.
Year: 2022 | Team: Assistance (PM, Native Engineers)
What was the problem we were trying to solve?
We had a big issue during our busiest times. So many people were trying to chat with support that it created really long wait times. This was super frustrating for our users because they had no idea how long they'd have to wait. That feeling of being in the dark was creating a really bad experience. The challenge was: how could we manage that frustration without being able to instantly hire more agents?
My role in this
As the Product Designer on the Assistance team, my job was to lead this project from start to finish. I got to do everything from the initial user and desk research, to running brainstorming sessions with the team, to prototyping and testing different ideas, and finally working with the engineers and chatbot team to get it launched.
So, what was the outcome?
The final solution was a feature that told users the estimated wait times right inside the chat. This helped manage their expectations and made them feel more in control. The result? We reduced the number of support chats during our busiest times by about 10%.
⚠️Please note that I am under an NDA for this project, which strictly prohibits me from disclosing any confidential information. As a result, I can only provide a general description of the activities I conducted without divulging any sensitive details. For a complete case study of this project, please contact me.
The journey: how we got there
To tackle this, I followed a pretty structured process to make sure whatever we built was based on what our users really needed and felt.
1. First, I had to understand the real problem.
Before even talking to users, I started with some desk research on a topic I found fascinating: the "psychology of waiting." What I learned was that for people waiting for something, the uncertainty of how long it will take is often way more stressful than the wait itself. A lack of communication just makes everything feel worse.
I used this idea to guide my user research. I created empathy maps to really dig into the specific anxieties our users felt when they were stuck in a silent chat queue. It became obvious pretty quickly: the problem we had to solve was uncertainty.
2. So, how should we communicate? And when?
Once we knew the problem was uncertainty, I ran an ideation workshop with my team to brainstorm different ways to solve it. The winning idea was to proactively show people the estimated wait time.
But that brought up a new, tricky question: when is the right moment to show that information without scaring people away? This led us to two main hypotheses that we wanted to test.
3. Testing our ideas
I built two different prototypes, one for each of our hypotheses about the best time to share the wait time. Then, we ran a moderated usability test. A fun part of this was using the "Wizard of Oz" technique, where we manually simulated a live chat to make the experience feel real for our testers.
The results were super insightful. It became very clear that one of our hypotheses was wrong, and the other one was the right way to go.
4. Creating our guiding principles
The results from that winning prototype gave us the proof we needed to create our design principles. These weren't just ideas we guessed; they came directly from user feedback.
→First, only tell users the estimated wait time when they specifically ask to talk to an agent.
→Second, if the wait time is longer than 3 minutes, we need to keep them updated on their progress.
A screenshot of some of the work done, because why not? :p
The solution: a chatbot that's honest and helpful
Guided by our new principles, the final solution was a series of smart interaction flows built right into our support chatbot. The whole point was to give users transparency and a sense of control right when they needed it most.
The new flow did three key things:
→Sets clear expectations: When you ask to chat, the bot immediately tells you the estimated wait time. No more guessing.
→Gives users a choice: If the wait is long, we give you the option: want to wait or come back later? This respects your time and empowers you.
→Keeps you updated: If you do decide to wait, the system gives you little updates on your spot in the queue, so you don't feel like you've been forgotten.
The impact: less load, more trust
We worked with the chatbot team to get the new flow launched successfully. By being proactive and clear in our communication, we helped manage user expectations and gave them more control. This directly led to a ~10% decrease in support chats during high-traffic spikes, which took a lot of pressure off our support team and created a much more positive and trustworthy experience for our users.
Designed flows
What I learned from this...
My biggest challenge
At first, this seemed like a simple UI project. But the biggest challenge was realising just how complex the issue was. To really fix the user's feeling about support, we had to look at things beyond just the chat window, like our overall communication strategy and even how our support staff were trained. It was a great lesson in how interconnected everything is.
My key personal takeaway
This project was a big one for my personal growth. It made me a lot more confident working with teams outside of my own, like the chatbot specialists. It also really sharpened my research skills, especially how important it is to do your homework in the preparation phase. My biggest takeaway is that spending more time on planning and scoping at the beginning really does make everything more efficient for the whole team in the long run.
