Breathing UX
When I started working at PedidosYa, I thought I had a solid foundation in UX knowledge. The truth is, I was wrong. That's when I really began to breathe the true oxygen of user experience.
Humanizing the experience
One of the philosophies we applied as soon as I joined the company was "let's experiment to infinity (and beyond)." This involved all kinds of methodologies, from user interviews, paper prototyping, and AB testing to playing "Big Brother" and entering users' homes to see firsthand what their experience is like when using our app—their joys, frustrations, and a host of other emotions.
Custom Spotify
At PedidosYa, the teamwork model within Product is called 'PedidosYa Squadification,' and is based on the Spotify model, although adapted to our needs and objectives. It's composed of tribes categorized by business topic (for example, 'Delivery,' 'Growth,' 'Partners,' 'Shopping,') which, in turn, contain squads ('NCR,' 'Restaurants,' 'Payments & Checkout,' etc.).
These squads are made up of a multidisciplinary team with defined roles: each has a product owner, iOS developers, Android developers, web front-end developers, QA, and a UX designer. This allows each squad to be autonomous and independent of another team. Cross-functionally, there are Chapters, teams of people from the same discipline: there's a Design Chapter (which I led), an iOS Chapter, an Android Chapter, among others. They work with three-week sprint objectives that are, of course, based on and aligned with the company's strategic objectives (OKRs).
From a design perspective, we need to be ahead of the rest of the squad. That is, for a particular feature to be worked on in the sprint, the designer must have it tested and validated with users before moving on to the development stage. Of course, the entire squad is involved in the validation stage to understand, empathize, and take an active role in what will be worked on.
For the interview, there are always two people from the PedidosYa team: one who keeps the conversation going and another who takes notes and barely interacts (except to say hello). These people change depending on the members of the corresponding squad so they can gain insight and see everything from the perspective of the end user, while also providing continuity to their project. Generally, the designer is the one who interviews, but if another member wants to take on that role, they can. The focus of the interview is always on a friendly approach. We remind everyone at the beginning that it's not an evaluation of the person, but rather a chance to analyze ourselves. Of course, we don't give opinions or perceptions, correct anything, or ask the classic "how did you feel?" ;)
The interview is filmed and, in some cases (also with prior authorization), broadcast to another office so that those interested can experience it without intruding on the interviewee. In the case of a user testing interview, everything that happens on the device is also recorded, and a front-facing camera captures the user's expressions.
At the end of the interview, the guest is offered some company souvenirs and something of greater value, which we modified: at first it was an object/gift, then we changed it to movie tickets, then to vouchers to use in the app (it was never cash, we didn't agree with that option).
After the interview research comes the analysis. In the case of testing, the process is evaluated step by step and reported in a spreadsheet (rainbow spreadsheet). We evaluate the user journey with its stages and corresponding emotions, searching for patterns, metrics, and more.
Depending on what is being assessed, we arrive at the definition of the journey map, outcomes, and what follows, if warranted: iteration and validation again. And then it moves on to development with the corresponding stages already described.
The 'type' process from a design perspective
To simplify a 'typical' case, the design process for each feature (or hypothesis validation) is always done by a team, and consists of the following stages (the reality is that it is much more complex, but I want to give a general idea):
-
A strategic (business) need arises or something that arises in the team and adds value to the user is investigated.
-
It is validated whether this hypothesis is real (with metrics, qualitative data, users).
-
The ideation process begins (post-its, brainstorming, iterations, wireframes).
-
A definite idea is reached.
-
It is prototyped.
-
It is validated with users according to the methodology that merits it.
-
It is iterated and, if there are changes, it is validated again (a cycle that can be repeated several times).
-
Enters development.
-
We move on to the initial stage of validation and QA, and iterate.
-
It moves to the Demo stage (PedidosYa Demo app), is validated and iterated.
-
It moves to the Night stage (PedidosYa Night app, which is prior to Production), is validated and iterated.
-
It goes to Production, is validated and iterated.
Interviews with users
One of the things we force ourselves to do every week is hold user interviews, whether to validate something, test, or simply have a knowledgeable conversation. This event typically takes place on Fridays, which is why I named it TGI Fridays (in reference to the American restaurant chain, whose acronym stands for "Thanks God It's Friday"). This gives an idea of the enthusiasm these conversations with users or potential users generate.
The person we'll talk to is carefully selected: depending on what we want to evaluate or validate (and also based on our user personas and jobs to be done), we pass the desired characteristics on to Operations so they can provide us with real-life profiles: whether they should be new users, users who stopped using the app more than a year ago, users over 80 years old, or whatever. Once the person has been contacted and the appointment has been agreed upon, everything is ready to organize the interview.
As a team, we outline the interview brief, meaning we clearly state in writing what we want to evaluate or test (a manifesto), define the job to be done if warranted, agree on the questions we should ask to achieve it, and so on. Our philosophy for interviews is to be flexible; we conduct them based on the planned narrative, but if things go a bit off-script, that's fine, as long as we redirect them to where we need to focus.
Typically, hours before the person arrives for the interview, we organize an office so they feel 100% comfortable, play with the lighting and atmosphere, decorate with pleasant plants to create a fresh air, provide certain foods, soda, and water, organize the camera that will film (with the person's approval), prepare the equipment (in the case of a test interview), etc. It's about creating a setting ad hoc for the occasion.
Contextual interviews
Through service design, we've conducted contextual interviews (in my case, in Colombia) to understand how people in their environment behave when ordering food delivery. This way, we can experience and understand the user's reality in everyday situations; we can analyze and capture their anxieties, satiety, and frustrations.
AB testing
We developed an internal system that allows us to test anything we want on the web and mobile for AB testing, choosing the percentage of recipients who should see it and configuring different features. Everything is documented and tracked, and we have complete freedom to test anything on demand.
As an anecdote: in the refreshed brand, we updated the colors of the partner rating. But we wanted to run a test to validate it. The rating was based on a row of 5 stars where the user indicated their level of satisfaction with the service: star number 1 was a poor experience, and star number 5 meant a perfect experience. Originally, the star colors ranged from red to green, but, at the request of the company's strategy, we wanted to "soften" this message and test how the user responded to a paradigm shift: going from light green to dark green. The results were what we had predicted: it didn't work, and we went back to the original version.
With AB testing, we also tested icons with different concepts to see if they worked better, changes in copywriting (titles, labels), changes in the color of the CTA, and countless other experiments.
Card sorting
When we launched Supermarkets, we managed to categorize products through card sorting workshops to arrive at common patterns that we found in the grouping.
Service Design
I was able to experience very enriching experiences with teams from Germany, Argentina, and Uruguay to learn how to make using the PedidosYa app an incredible experience.
See more information
Real cases validated through interviews:
-
One-page checkout
Before, to make the payment you had to follow 3 steps (that says it all ;). -
Vertical launcher
We tested countless launchers for different verticals to narrow them down until we found the best version. -
Payment method error
The alert indicating an error in the credit card payment wasn't entirely understandable or clear (it seemed to have been processed correctly). We resolved this through these qualitative interviews. -
Log in and Sign up
Of the tests and trials that we study and iterate the most. -
Swimlanes for Groceries
We tested different swimlane layouts, arrangements, sizes, and more.
-
Definition of User Personas
We managed to define 4 types of user personas (validating if the proto-personas we had were aligned). -
Notification center
Testing the notification and promotions center. -
Up-selling
Identify the best way to implement upselling while remaining non-invasive. -
Referral program
Evaluating how best to implement it and make it visible at launch. -
And the list goes on indefinitely.
Heuristics evaluation
Design Sprint
We invited the German design team to conduct a heuristic evaluation of the entire supermarket delivery experience.
We ran a design sprint (led by a design mentor from Germany) to generate new ideas for our self-service flow called Alan (bot), since the user experience was not good and that was where the biggest problem was in the main flow.
A day in my shoes…
To understand the experiences of others and empathize with other departments and their needs and problems, we decided to launch 'A Day in My Shoes...'
One of the most enriching experiences was "a day in the call center," that is, taking on the role of answering calls, chats, and emails. We previously had an induction workshop to understand the processes and methodologies they use and learn about their tools.
Thanks to this, we were able to see not only the other side of the counter but also "our side": the pain points our team was experiencing, improvements we could make to the customer call experience, the process, call, chat, and email management, and tool integration techniques. And, above all, we were able to empathize and understand.
As part of the service design process, we include what we call 'diaries': we ask selected users, via text messages or WhatsApp, to write down how their day went (a kind of personal diary) and to carry out some tasks such as purchasing products they need, while describing their step-by-step performance of that task, with photos and documentation, and focusing on their problems and perceptions.
