Groove Flow History Feature
OVERVIEW
Groove Flows is one of the most popular and widely used features on the Groove web app. Using Groove Flows allows sellers to scale up the number of emails theyāre sending to customers. Think of one email that can be sent to hundreds of leads and customers.
MY ROLE
Product Designer
TEAM
Taylor Burrows, Product Manager
Tammie Kahnhouser, Developer
TIMELINE
January 2023 - March 2023
TOOLS
Figma, Whimsical, Zeplin
PROBLEM
Unfortunately there can be errors when sending emails through Groove Flows. These errors are often very jarring for customers and until this project started, customers had no way of being able to debug errors on their own without contacting our customer support team.
Troubleshooting had been historically very difficult because the transactions and the corresponding data didnāt persist anywhere in our database. If there is a failure, we track those in the Event log, but it is only available to Admins and it is deleted every 30 days.
We needed a way to communicate successes and failures to end users. This was one of our most painful issues regarding Flows, and resulted in a high ticket volume because users were not understanding why someone was removed from a Flow, or why someone failed to be removed from a Flow.
Impact
The Flow History tab was released to an external beta group during Q3 2023. This feature helps provide transparency and improves user trust for one of Grooveās most used features and addressed a prominent pain point for Flows users.
Wireframing
For this project, I worked closely with the Flows product manager. Together we collaborated on low fidelity wireframes.
Since we wanted to create an event log of successes and failures, we decided that a table showing each event would help users troubleshoot more easily.
CHALLENGES
There were multiple legacy table and filtering designs throughout the Groove platform.
This project presented an opportunity to use our new updated design system to define a new table and filtering pattern.
WIREFRAMES
My first idea was to show all the available filters at the top of the table, however I determined that this pattern might be visually overwhelming for users. It would probably also present problems with scaling if we were to add more data.
The second idea I had allowed users to filter results in each column.
DEFINING A PATTERN
After showing my ideas to the Director of Product Design for approval, I choose a filtering pattern based on a pattern presented elsewhere in the application. We didn't want to introduce a new filtering patternt hat was too different from what was already in production.
This pattern uses a filter button with a dropdown menu, allowing users to select various filters in one place, and we would reuse it going forward.
High fidelity
Below are mockups of the Flow History table with all components created using the new Groove Design System.
OVERFLOW
In the second mockup youāll see tooltips informing the user about the creator of the Flow and contacts associated with the Flow. I used tooltips to would show the full name of the Flow step in case it overflowed. In hindsight, I'm not sure if this would have been the best choice because I think it presents accessibility problems and the potential for moving your mouse and missing information is high.
FILTERING
Users are able to quickly sort results by āSuccessā and āFailureā statuses. Both statuses are shown by default.
Selecting the āFilterā button opens a dropdown menu that allows users to search and select through Flow Step, Event, Result, and User. Once filters have been applied, the filter buttonās state updates to show the number of filters applied.
Retrospective
This feature was a great opportunity to show users our updated design system components and establish a new filtering pattern. I really love the combination of the button group sorting and the filter component together. Looking back, I would have loved to experiment with how we could have used data visualizations to show success and failure.