UX as Customer Service
A Continuous Research Approach
As designers, we are often seen as people wearing fancy headphones on their computers; this needs to change. We serve people, and to help them, we need to be closer; this text is about that. It's about my experience working on a digital product for seniors with an agile, collaborative, and human-centered approach.
Have you ever wondered how long it takes to reach you or the development team for user feedback?
I have, but I confess that was after I came across a new approach for continuous research, something simple and natural that made me wonder how it is not everywhere. As much as I would like to say I was the author of everything, this all happened because of a perfect combination of factors: an engaged and mixed team and physical proximity to customers.
All I'm doing here is sharing this knowledge.
Generally, in larger companies, the consumer is not only physically far from developers, but sometimes it looks like the whole organization goes the opposite way of the customer, making it hard for the customer relationship area to share their learnings directly with product design and development team.
This entire customer frontline is usually sectored between sales, support, and aftersales, contributing even more to this fragmentation and probably losing valuable information that would be crucial for the company when it comes to building a better product.
Last but not least, these teams are more concerned with selling, supporting the usage of the product or service, or quickly solving a problem. They have different performance indicators in sales, such as the number of people served and sometimes even the cycle time of service to worry. They are unlikely to write down every insight that a customer might come up with during a call or conversation.
The team and the problem to be solved
The Bank hired me during the initial phase of a digitalization process; it was the first development squad¹ I've participated in. The term squad, in other words, is about different types of professionals of complementary skills organized to attack a single product.
All members of the squad were new employees at the company, and the team was entirely structured around agile software development; I mean we followed the scrum methodology by the book performing all the ceremonies, such as daily scrum, sprint planning, and then started renaming each one in a matter that made more sense to us, also adapting new dynamics, like design sprint methods for idea generation, sketching and deciding.
The product was the payroll loan, a type of loan in which you pay through payroll discounts; This is precisely why it creates a lower risk for the Bank that turns into lower interest rates, a widespread modality for retirees, veterans, pensioners, and civil servants.
The vast majority of the users are people between 50–78 years old. One of our biggest challenges was developing an accessible solution for seniors since many of them had a smartphone for the first time and rarely or never had contact with the digital world and applications such as Instagram.
After a phase of research and many prototypes, we began our minimum viable product (MVP), the first version of mobile user-focused software that synthesized a whole set of assumptions to be validated, with the necessary functionality that delivers customer value.
All good, right? Well, not exactly.
The first version was aesthetically excellent, worthy of a page on the Dribble (designer community). Still, right on the first tested customer, we realized it was just aesthetic. We talked to one, two, and on the third customer, a wild idea came to our minds: redesign all screens without any scroll usage.
It made sense since 10 out of 10 customers did not even use Facebook, but they used WhatsApp, where scrolling is automatic. The result came quickly, and we realized that we had much more to learn by becoming closer to our audience.
More importantly, each conversation brought us something new, and more and more, they became more constant in our routine.
Daily conversations, one way or another
At one point, our MVP got a little "help" button, and by clicking on it, users could choose to use WhatsApp or make a phone call directly to my desk; that was when things started to get interesting as the customers started coming straight to us.
We had a dedicated phone, so everyone in the team was aware that an incoming call would mean a customer with a question or complaint, each time with a unique opportunity to learn something about our product if we could listen carefully.
The product was only available for part of the Bank's customer base, which guaranteed enough leads to generate enough feedback but not at the point to need someone dedicated to it. It had an ideal balance, and indeed, we were at the correct number.
The team's product owner (PO) was a unique guy who had little technology experience yet had over a decade inside the Bank and incredible empathy with people. And among other things, he said he hated the term "user" because that meant something negative and distant for him (which I agree with nowadays), and maybe that's why when he answered the first call that rang on that phone, he said:
“Good morning! ParanáBanco, customer experience. How can I help you?”
Without realizing it, he had named us, and from that very moment, I started to acknowledge that we were doing something slightly different, slightly better.
From that moment on, I decided to compare everything we were doing with that traditional UX research, creating the following table:
A couple of days later, the first call I answered, I was not yet totally aware of all the Bank's processes, so I asked for help in solving problems, but I was already able to identify and categorize them.
This fast process changed the dynamics of user's feedback, not just by drastically increasing the number of feedbacks but also in the quality that could generate results in areas we were not expecting to find inside the Bank.
During one of these conversations, we discovered a bug that only appeared in a browser so-called "Internet" that came up by default in Samsung phones, something that we had never tested but affected a good number of users.
Just try for a second to imagine someone saying something like:
“ The problem is on my internet”
The bug that we discovered was solved on the same day, 3 hours later, and the next day, we had an instant change in the number of people passing through the conversion funnel we were tracking.
Something that I noticed is that people are far more honest when they come to you believing you are some service desk, probably not only because they are still feeling the pain (right time) at that moment, but also because design interviews make people use better words (also less precise) trying to be more polite and not hurt your feelings.
Something that came up naturally was asking the client for permission to talk to the speaker; the idea was to make the whole team aware of a problem; this also increased empathy by bringing responsibility for everyone.
Most of the time, these conversations generated some discussion later about what could be better, faster, or easier to understand; we also tried to correlate the call with a persona and a larger group of people that may be experiencing the same.
The conversations could be classified into:
•Bugs to be fixed;
•Usability adjustments;
•Product insights;
•New features.
The flow
1. Bugs to be fixed
Any failures that were too critical or too quick to resolve would not necessarily enter the sprint if the effort was more significant. It would be mapped to the weekly sprint according to its prioritization.
2. Usability adjustments
Everything else was recorded on post-its in a visible place and weekly presented to the team as "Design Insights" before the sprint planning. We aligned those users' demands and how they would be allocated in the subsequent development sprint.
Usability tweaks, for example, were like bugs, ranging from small things — such as descriptions — or bigger — like changing a complete element — and almost always became the task of the next sprint.
3. Product Insights
Do you know when someone tells you something that changes everything?
It happened something like that. Insights were new ways of doing something: it could be a shorter user flow, a form of communicating more naturally. The prioritization in time to the product was related to our perception of improvement with the insight generated; if it was something simple like a change of a text or button, that improvement could happen on the same day, in case of something more complex like a new user flow the insight might become a user story for the next sprint or even an item in the product backlog.
4. New features
This was probably the rarest scenario that could have happened because we'd already had a lot of features mapped in the backlog, some of them being prioritized because of new insights.
Each new feature demanded a discussion, and sometimes we came back to the ideation process, and some of them used the method Crazy ⁸³ that I pulled from Sprint Design, a great chance to make the entire squad work together by creating new ideas.
We used many methods from the design sprint; we discovered they could be easily adapted to the reality of agile software development. Still, perhaps this specific point is the subject of another article.
Conclusion
Those daily conversations generated by the approach could change the whole perception of the team, building empathy, making us more aware of different types of audiences' needs and desires, and the amount of customer feedback that enables faster product improvement.
The "customer experience" approach guaranteed more real feedback; after all, it became increasingly clear that people smooth out flaws when they get interviewed, generating completely different feedback when we identify ourselves as a customer experience team.
But the biggest highlight, in my opinion, was the team mindset, becoming more and more responsible awareness of the problem and the customers, more empathy and responsibility in the value generated from each feature, each design element, and each line of code we implemented.
You care a lot more if you know people depend on that; you see these people, you listen to them, and you know that their lives may depend on you; it changes your perception of what you do.
You should try too!
Acknowledgments to Ricardo Porciúncula for his contribution to the development of this approach, and to the Bank's president, Cristiano Malucelli, for being willing to share these learnings here and, of course, to the initial PB Squad:
Renatinho, Luan, João, Fábio, Bini, Kimura, Wagner, Meggy, Bruna, and Eduardo. You are awesome!
References:
(1) If you are interested in understanding more about squad organization, I recommend the text "Scaling agile @Spotify with Tribes, Squads, Chapters & Guilds" written by Henrik Kniberg and Anders Ivarsson.
(2) Design Sprint is a methodology for developing a hypothesis, prototyping an idea, and testing it quickly with as little investment as possible in a real-life environment, in a collaborative and time-constrained manner.
(3) "Crazy 8" is a sketching method of the Design Sprint that consists of folding a sheet of paper into eight spaces and sketching eight ideas within 8 minutes.
This article was previously published in:
www.design2020.com.br
