← Back to home

← Back to home

← Back to home

Case Study:
Improving granularity on Palabra's funnel view

Case Study:
Improving granularity on Palabra's funnel view

Case Study:
Improving granularity on Palabra's funnel view

2021

2021

2021

Context

Palabra.io is a PLG tool for SaaS B2B teams to understand funnels, grow accounts and drive revenue. I joined a team of engineers as the first designer in the early stage, and helped build the product’s initial MVP. As we engaged with our early prospects, it was time to iterate and refine the product.

Palabra.io is a PLG tool for SaaS B2B teams to understand funnels, grow accounts and drive revenue. I joined a team of engineers as the first designer in the early stage, and helped build the product’s initial MVP. As we engaged with our early prospects, it was time to iterate and refine the product.

Palabra.io is a PLG tool for SaaS B2B teams to understand funnels, grow accounts and drive revenue. I joined a team of engineers as the first designer in the early stage, and helped build the product’s initial MVP. As we engaged with our early prospects, it was time to iterate and refine the product.

Team

Team

Team

Engineers

Founders (sales, product)

Product Designer (myself)

Problem

Problem

Problem

We launched Palabra’s web application as a MVP and we received considerable interest. We conducted interviews with potential users who appreciated how simple and clean our approach was for visualizing funnels. However, we faced challenges in converting these prospects. Although they admired the simplicity, users lacked the precision needed to construct their funnels accurately.

We launched Palabra’s web application as a MVP and we received considerable interest. We conducted interviews with potential users who appreciated how simple and clean our approach was for visualizing funnels. However, we faced challenges in converting these prospects. Although they admired the simplicity, users lacked the precision needed to construct their funnels accurately.

We launched Palabra’s web application as a MVP and we received considerable interest. We conducted interviews with potential users who appreciated how simple and clean our approach was for visualizing funnels. However, we faced challenges in converting these prospects. Although they admired the simplicity, users lacked the precision needed to construct their funnels accurately.

In order to increase user conversion, we needed to provide more accurate funnels. This meant improving Palabra’s funnels by incorporating both quantitative and qualitative properties into existing users and events. To move forward, we had to define which properties to add while preserving the simplicity that our users loved so much in our product.

Process

As first designer I took charge of addressing this challenge. There were two main issues to address: which properties we were going to include, and how.

I conducted research to understand what similar products were offering, met with the sales team and founders to learn about our users and past interviews, and discussed the scope and technical possibilities with the engineering team.

Incorporating user and event properties into the funnels also meant introducing multiple variations and states. This level of complexity demanded solving the how problem at a system level. We already had a first iteration of a design system on the go. I had to define how to expand the design system to accommodate the new features, while keeping it simple.

Incorporating user and event properties into the funnels also meant introducing multiple variations and states. This level of complexity demanded solving the how problem at a system level. We already had a first iteration of a design system on the go. I had to define how to expand the design system to accommodate the new features, while keeping it simple.

The platform’s existing navigation was based on direct manipulation UI. This is a strategy that we defined to make funnel visualization feel more simple. 

Based on the research to determine which properties to display and the design patterns I had defined earlier, I established the framework to bring the UI solution to life.

Based on the research to determine which properties to display and the design patterns I had defined earlier, I established the framework to bring the UI solution to life.

Based on the research to determine which properties to display and the design patterns I had defined earlier, I established the framework to bring the UI solution to life.

We had existing UI components that visualized essential elements, such as users and events. The properties we intended to add were specifications related to these events and users. Therefore, while using an item component for the core, which included cards and avatars, we opted for a descriptive component to handle the additional properties: tags.

We had existing UI components that visualized essential elements, such as users and events. The properties we intended to add were specifications related to these events and users. Therefore, while using an item component for the core, which included cards and avatars, we opted for a descriptive component to handle the additional properties: tags.

We had existing UI components that visualized essential elements, such as users and events. The properties we intended to add were specifications related to these events and users. Therefore, while using an item component for the core, which included cards and avatars, we opted for a descriptive component to handle the additional properties: tags.

Defining and scaling the navigation logic

Using this reasoning, I could move forward with the system components exploration. After revisiting our research, exchanging feedback with the team, and further analyzing our existing patterns, I identified three levels within our navigation and component logic. To maintain the simplicity of the funnels view, I recognized the need to introduce properties within this existing logic.

This, naturally, was not the final solution but rather the initial direction. I exchanged insights with the team and returned to wireframing and prototyping to assess potential outcomes of this approach. The main challenge now was solving the flows for adding, visualizing and editing these properties.

The integrations challenge

As Palabra operates with real-time data, integrations are crucial. Initially, we seamlessly integrated with Segment and Webhooks. However, the demand for precise funnels led to exploring Stripe and Salesforce integration—highly requested by users. The initial assessment guided property selection. Challenges arose, especially with pulling from Segment and Stripe, and integrating Salesforce. To navigate, we adjusted the scope, starting with Segment filters. Gradually, we expanded to include user and event properties from Stripe and Webhooks, while Salesforce was left out of scope for the project.

Flows and variants definitions

After a series of iterations and enhancements, shaped by peer review sessions with engineers and founders, internal user testing, and presenting the prototype to prospective users, we completed an iteration ready for implementation.

Moving forward

Moving forward

Moving forward

We started by implementing a first iteration of the project. As is typical in startup life, shifting priorities brought forth additional challenges.

We started by implementing a first iteration of the project. As is typical in startup life, shifting priorities brought forth additional challenges.

We started by implementing a first iteration of the project. As is typical in startup life, shifting priorities brought forth additional challenges.

← Back to home

← Back to home

← Back to home

Let's work together :)

Get in touch.

© Sof Andrade 2024