UX talk

Meike: We all work on the topic of user experience every day. That is, the experience a person has with a service, a product, an application, etc. The usage experience.
By now there isn't just user experience, but customer experience, client experience, candidate experience, brand experience, employee experience – it's a long list.

That's where the question is worth asking: is now the time to fan this out further, or does it make sense to bring it back together? Fundamentally, isn't it about developing something for people: so a human experience?
Our customers currently tend to separate this. HR deals with a candidate experience that's completely different from the customer experience.

Does that make sense? In some cases, they're the same people after all. A Peter who is a customer at a company can also apply for a job there. He always brings all his roles with him. Is there an argument for separating experiences by usage scenario? Usage context? Or can it be reduced to the "human experience"?

Susann: That's how we experience it in our daily work too. When we talk about UX projects, we always have different clients. Our customers come with the concept team or the UX team. These are often based in marketing or corporate communications, and their perspectives are then naturally more marketing- or sales-oriented.
There we also talk about customer experience. And with HR about candidate experience.

Nina: I don't think it's necessarily different target groups, but rather different needs, depending on the context you're in. On Amazon, I don't want to call anyone, but with a B2B company I want to see a photo and be able to call immediately. So different needs in a different context. We need to look at that.

Susann: On your point about reducing it to human experience: I don't think that's a reduction, I think it actually feeds the topic with much more data, in order to be able to reach the user. Because every user is individual. There is no such thing as "the user". The distinction between applicant and customer rather helps companies handle individual areas separately.
The problem with this distinction between customer, candidate, applicant etc. is really only that the individual departments communicate poorly with one another. So my experience as a customer at a company can be great, because the website area is tested and optimised. But as an applicant I might experience poor usability. And that rubs off on the overall brand. Often on my behaviour as a customer too.

Nina: It also happens that our clients say: "These are all experts visiting our website. They know the technical terms. They know all that already."
But that's not actually true. It could be a graduate who doesn't yet know all the terminology, or someone from admin. Or someone applying for a job, or a journalist. You always have a diverse target audience.

Nina: Some of our B2B customers say: "I know my 100 customers personally." Luxurious position. With this knowledge, can design own website optimally for these people.
At the latest when it comes to recruiting skilled workers, though, the situation is often less comfortable. And that's exactly when you need to be able to make overarching statements about needs. And understand users you don't yet know. And also place them in context: applicant, customer, employee and so on.

Susann: Right. And these are of course all people. The UX industry won't rename itself to „Human Experience“ any time soon, but going forward it's an important aspect we mustn't neglect: the holistic experience a person has with an application or a company.

Far more important than understanding the technical terms is understanding that it's about a shift in perspective: truly understanding users.

Nina: Do you always manage that shift in perspective, understanding the users?

Susann: At the start, yes. Before every project we look closely at the target group: create personas, do research, develop a customer journey – everything needed to better understand the people who will use our application.
Over the course of a project, however, this perspective can slip out of view, especially for clients.

Header And you notice again and again how important a UX test with actual users present is. Often, after a test and an adjusted prototype, Susann says: now we're back to my initial design. Through discussions with clients and adjustments to technical conditions, everything eventually became too complicated. The result was then no longer intuitively understandable for users.

Nina: In these rooms where something is being developed, there aren't any users.
Isn't a UX test actually a detour to bring the user back in?

Susann: Perhaps. But that's exactly what I'm there for as a concept designer. In the get-to-know-you rounds at the start of a new project, I often deliberately present myself as the interface between users and our clients.
So I understand customers' needs. Marketing-centred. But of course I also keep putting on the user's glasses again and again. And matching the two together, making them mesh, that's the balancing act you perform as a concept developer.
We don't start from a blank slate. There are organisational and technical circumstances. And I need to know when to set aside the user's perspective.

Meike: The moment we use a method like a customer journey and get customers to make the shift in perspective, the aha moments happen. "Now I understand why!"
And everyone involved needs to realise that this is always a shift.

Susann: Absolutely. In our projects, the biggest hurdle isn't the perspective shift either. It's internal communication. With our contacts here, there's little discussion. They see it right here. They experience the same as we do.
When they then go back to their company, they have discussions with stakeholders from different departments and have to fight for credibility there. That's already a big challenge.

Nina: Back to the challenge of how UX insights can be effectively carried into organisations: agile methods help us with that too.
If I work classic waterfall and at some point say: here is the finished thing, my customer will carry that forward differently than if they had worked on it every day and repeatedly confirmed the direction we're going, what we're adjusting.

Susann: Absolutely. In my recent in-house UX tests we always used the agile RITE method. Rapid Iterative Testing and Evaluation.
So testing on day one. Incorporating a day of feedback. And then testing again.
On the first test day, the biggest pain points are identified together with the participants. Then it's defined: what didn't work at all, where do we want a quick win, which measures can we implement.
We work here with a click dummy, not a coded product. That means you might not be able to implement everything one-to-one, but you can change and adapt things quickly for the next test day.
Then the old errors usually don't show up at all. And you notice whether the small changes made a difference.

That's what it's about: this quick reacting and immediately asking again and adjusting.

Nina: What I find nice is that you validate the new ideas you have straight away.
If you bring your new ideas with you, you can't prove that it works better. But if you test it directly on the second day, you can say: we did it this way; it worked.
In UX-driven projects, we sometimes test in every sprint. And at the latest once customers experience a test in our lab, we no longer need to make the case for user experience.