About the product

The phrase "Data is the new oil" has become widely used, especially in tech companies where making decisions without data or effectively monitoring results is nearly impossible. In this product’s context, data was the core focus. The company, which was experiencing rapid growth, faced increasing challenges in centralizing its data within a single platform.

Although there was a promising internal tool, its usage was limited to people with SQL knowledge, making it inaccessible to most employees. Teams across different departments relied heavily on the data team to create visualizations and track their products and revenue. As a result, many teams turned to unofficial tools, jeopardizing the integrity and consistency of the data used for strategic decision-making.

Challenge

The main challenge was to improve the internal tool, making data more accessible and user-friendly for the product and sales teams, reducing their dependence on the data team. The goal also included centralizing relevant studies and analyses within the platform, minimizing rework and increasing efficiency.

My role

As a Product Designer, my role was to research and understand the needs and challenges of the teams relying on data and to create solutions to enhance the usability of the internal tool, making it more accessible and valuable to everyone.

Impact

The data team was overwhelmed, with most requests being urgent. The sales team received priority, leaving the product teams underserved, which hindered their access to critical information. Consequently, teams shifted to alternative tools, which were not always reliable, compromising the quality of decisions based on inconsistent data.

Context/Problem

Goal

Increase the adoption of the internal tool, raising the percentage of active users from 30% to 80% among the company’s employees.

Discovery

Note: The text in the images is in Portuguese, reflecting the language used during the project.

To understand why people were not using the internal tool, we facilitated a workshop with participants from various product, data, and sales teams to uncover their needs and frustrations with the tool. This process allowed us to identify three key personas who either used or needed to use the tool—both to access data for decision-making and to create visualizations for others to access.

Personas

• Lack of access to necessary data;

• Uncertainty about whether relevant queries or dashboards already exist;

• Lack of technical knowledge to create data queries for daily needs;

• Distrust in the accuracy of the data;

• Lack of clarity on business metric definitions;

• Limited options for basic charts to create dashboards;

• Difficulty using the tool.

Interviews

To complement the workshop findings, I conducted interviews with individuals from the identified personas, highlighting the pros and cons of the internal tool, as well as the alternative approaches they explored to meet their data needs.

Based on the key issues identified, we conducted a brainstorm session (How Might We's) to come up with quick and efficient solutions to improve the tool and drive adoption. We voted on the most viable ideas and created an opportunity tree (backlog) outlining the next steps for future development.

Key Issues Identified:

Brainstorm

After these steps, we consolidated the personas and identified their main needs and frustrations at that point in time.

Solution

As a parallel action to the tool, but something we understood was essential to spreading its use, we (the entire data team) created a training program. In addition to teaching how to use the tool, we also explained all the steps related to the data, why it was important to use it in the product, etc.

All the available data in the tool was previously restricted to technical people who were part of the product, specifically the data analysts. Product managers, even with technical knowledge in SQL, couldn’t access the data, and their developers couldn’t enable this access either. Everything was handled by the data team. Because of this, we created a folder structure and sharing system with groups to make it easier for the right people to share the files.

Problem #3 Lack of technical knowledge to create data queries for daily needs;

Problem #1 Lack of access to necessary data

Problem #6 Difficulty using the tool

Problem #4 Limited options for basic charts to create dashboards

Problem #2 Uncertainty about whether relevant queries or dashboards already exist

Many users didn’t even know what was available in the tool that they could already use for their product or analysis. So, we created a section where users could explore the queries and dashboards that were already made, along with their descriptions, and then request access. For those who had access to the file, a screen would appear with the option to approve or deny the request.

Even with permission to create queries, many didn’t have SQL knowledge and needed data from some important company indicators, which were common across many teams. Because of this, we created a homepage where, depending on the user’s permission, they could access official dashboards created by the Data team. These dashboards allowed us to track indicators throughout the year, as well as customer information.

For the Data team to create data visualizations for other teams in the tool, it needed more types of charts, beyond just bar, line, and pie charts, which were the only options available until then. We also needed additional features like chart labels, colors, etc.

Problem #5 Distrust in the accuracy of the data

Since many people were creating queries in the tool, it wasn’t always clear if the query was recent or reliable. For this reason, we developed a system where the data team could mark queries they had validated and ensured were up to date. This process was more difficult because it depended on the work of the Data Analyst, who already had many tasks to do, so it took some time to be implemented and used.

Validation

Before each change, we tried to run some tests with users matching the personas we had identified. We aimed to include both frequent users and those who didn’t use the tool much. This way, we could identify the level of difficulty at each step. We found some issues, such as button design, naming conventions, and problems with the flow.

I always tried to document this information somehow, and even though it was qualitative data, it gave me an idea of recurring patterns.

Monitoring

To improve problem monitoring, we added easier options for users to open support tickets directly in the tool. Additionally, we tracked the engagement with the new features that were being added.

I added an option to the menu where users could report an issue ("Reportar problema"), which would open a ticket for the team to address. They could also consult support materials ("Ver documentos de suporte") or submit a suggestion for improvement ("Dar uma sugestão").

We were able to review these items through a dashboard in Looker Studio.

Results & Learnings

• The adoption of the tool reached more than 80% of the employees initially targeted. This success was due to the creation of a "data evangelization" group within the company, and we used the tool itself to present data to other departments. This was very important in sparking interest among others in the company to use the tool.

• We had to work in partnership with the company's internal communication department to ensure that update materials about the tool were sent out, keeping users informed and interested with each new feature.

• There are several amazing data tools available in the market that could potentially replace our internal tool. However, we believed that the evolution of our tool could eventually turn it into a product for external customers. This actually happened some time later, after I was no longer the product manager of the tool.