DEI UM TEMPO
Redesigning the most access page to reduce the bounce rate
When
Jun 2019 – Aug 2019
Role
Product Designer
Platform
Web
Overview
Reclame AQUI (which means "Complain here" in Portuguese) is the 11th most accessed website in Brazil* and it is a communication channel for consumers and companies when there is some type of consumer problem between them. But, despite its name, it does not work only for complaints. Today, it is one of the main tools for researching products and services for Brazilians and being a great data generator. With more than 20 years of existence and more than 30 million registrations, it is a huge ally of the consumer.
* (According to Alexa in 2020).
Role and responsibilities
I was the Evolution Team’s leading designer, responsible for adjusting and improving the website's main features. I worked together with a Product Manager and another Product Designer, and we worked closely with the development team.
Create design solutions for internal and external use, leading the project from the start through an end-to-end design process, creating user flows, wireframes, prototypes, and final pixel-perfect deliverables. Also, testing the solutions with users and propose iterations.
Work closely and collaboratively with the developers to create a scalable style guide and implement the design system.
Led the team of Product Design, instructing/mentoring new team designers and implementing several new processes.
The challenge
The bounce rate of the results page was increasing, and we didn't know why.
Due to its immense success and access, when searching for a Brazilian product or brand, usually one of the first links on the google results page will redirect to Reclame Aqui, making the landing screen the most important of our site, since most of the accesses are through google and this is what makes us remain so relevant.
This page was neglected for a long time by the development team. With the constant changes in the Google algorithm, we noticed an increase in the bounce rate and a notable rise in the number of tickets and complaints from users about the results page in the customer service, raising a red flag for the team.
DISCOVERY
What do we need to know?
Gathering the team to raise questions and hypotheses.
To start the project, we began with a dynamic between all involved in the project (product designers, project manager, developers, data specialists, and customer service) to level the knowledge among the team, raising hypotheses and what everyone knows about the subject, and raising questions to create an action plan:
* How the users can get into this page?
* What is the primary information the users are looking in this page?
* What is the behave of the users on this page?
During the CSD Matrix dynamic.
Exploring the problem
Analysing user's recordings and heatmaps.
We surveyed heatmaps and watched +100 recordings of visits from our users to see where users click, move, and scroll on the site, so we could learn how users behave.
Mapping how it is possible to get into the results page.
With the help of the data team and with Google Analytics, we raised the primary means for a user to reach this page and what possible reasons led him to it.
The survey was online for six days, and 65.000 interacted, 31.000 accepted to answer and finally, 8.883 finished the survey.
Online surveys & interviews
To close the gap on some unanswered questions, we put a survey on the main page for users to answer, and we also called some users to ask the rest of the questions.
“This page is very confusing. I feel so lost. I click on a place, thinking I’ll see more about what I’m looking for, and it takes me to another page. It’s easier to go back to google.”
Identifying the problems
Flow issues
During the research and interviews, we noticed a problem in the flow, increasing our bounce rate. When searching for a product or company on Google, users enter the results page. However, because it is a very confusing page, users prefer to go back to google and then enter another page of Reclame Aqui instead of browsing the website internally.
Usability issues of the page
Some of the usability problems discovered.
DEFINE
Creating personas
Personas created based on the behaviour patterns found during the research.
After the research, we identified several scenarios that converged to four patterns of behaviour, which we represented as personas, and we created storyboards for each of them, which was the pillar for the rest of our process.
Personas created based on the primary goal
With the personas defined and the results of research and interviews, we created storyboards and empathy maps for each of them. After this, we could determine the primary information they were looking for when they enter this page.
DESIGN
Early concepts
Sketches
Knowing what information the users were most interested in, we brought the team together again for designing possible visual solutions, so we drew all the components on paper and organized them so all personas could find what they were looking for easily. After this, we did a focus group with the same dynamic with real users, and we could compare the ideas.
Wireframes
With sketches, we move to wireframes/medium resolution prototypes and use them to get the managers' approval and do usability tests with users. After that, we made some slight design changes, and we moved to create the final prototype.
Design decisions
Styleguide
The design of Reclame Aqui is clean but also very outdated. The design team wanted to change the whole design, but due to insufficient resources and the difficulty of working with ten years of legacy, this wasn’t the priority.
Although we seized the moment to make light changes in the design to make it more modern, we gathered all the design team to create a unique style guide for all products to reduce inconsistencies. I also started new components to accommodate the new layout.
We also pitched to implement a design system showing all the benefits this would bring to the company, but managers thought it wasn't the right moment.
Final prototype
The difference in the design
Old x new version
DELIVER
Develop & Launch
Hand-off & QA
To make the hand-off for the developers, we did a meeting with the team to show the project, and we also delivered the InVision prototype, the documentation with the behaviour of the components and a checklist for the QA. The designers followed the development closely, reviewing each sprint delivered.
Launch & Analyse data
The developers coded the page and we made an initial release to 50% of users in our base as A/B testing to measure the performance of the new results page. We did the monitoring through Google Analytics, and HotJar (recordings and heat maps).
Results
We decrease the bounce rate by 46%, and we increase the time on the page by 62%, exceeding our initial expectations. Besides that, we drop 78% of the tickets in the customer service related to the results page and we received a lot of feedback from the users on how the new results page is easier and faster to use.
* Approximate numbers due to the NDA.
Accidents that led to changes
Component standardization meeting for the creation of the Design System.
The filter incident
Due to a failure in communication of the teams, the developers of two different squads implemented the same filter component. However, due to the difficulty of dealing with legacy code, the component's behaviour ended up being different, and we only noticed this after both delayed the sprints.
To solve this problem, we brought all the teams together to discuss the best strategies to deal with it, and it became clear to everyone that we needed to start a Design System to solve these internal problems.
The managers understood the necessity of having a centralised collection of reusable components, guided by clear standards to reduce redundancy and avoid repeated work, making its realisation finally possible. Also, the developers became interested in the subject and started to participate in the creation actively.
Challenges & lessons learned
This project was a big challenge for me since I was the lead designer working with the primary way the users get into the website, and any change I suggest would impact a lot the numbers of the website, but also was a fantastic opportunity to make a difference for the company and get to know more the users.
Also, after the filter incident, I understood how important it is to create opportunities for better communication in the team, especially between squads and collaborate and evolve the stakeholders during the project. This incident made our team stronger and united, and we could accomplish bigger goals working together.
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of the company.
