List Builder
Flexible filters for building powerful contact lists.
Bananatag is an employee communications tool where internal communicators can create, distribute, and later measure the engagement of sent messages. It's mostly used by professionals from departments like Internal Communications, Human Resources, Marketing and IT.
One of Bananatag’s web app features is an employee directory, where customers can manage their contacts and build targeted lists for sending communications. Filters for building lists existed in the app since the first release, but the initial functionality was becoming too superficial for some customers. Work on filters was prioritized after customer requests reached Account Managers.
Here are more details about the design process:
Product designer
Gather and analyze customer feedback
Prototype
Test and iterate
Refine interactions
Collaborate with development
Plan feature documentation
Analyze post launch performance
1 product designer
1 product manager
2 front-end engineers
1 back-end engineer
1 QA engineer
DISCOVERY
Limited access to customers makes designers rely on Account Managers and the Customer Success team to collect user feedback. More than gathering requests from them, we try to learn about use cases that can help us understand user pain points better. In this case, this is an example of a list that one of our customers was trying to build:
+ included everyone from all countries
– except everyone in Bolivia
– except managers in Canada
The filter above and other use cases showed us that, more than having only exclusion filters, it was necessary to:
• Exclude specific groups of contacts from a filter
• Select attributes in bulk
• Combine inclusion and exclusion queries in a single filter
IDEATION
With the new information collected, we turned to our existing interface.
Initial explorations tried to build upon the existing filter format, aiming for fast development. We tried to use a basic IS/IS NOT approach for building queries.
The first designs were reviewed by the entire team, and we came to the conclusion that it was worth exploring more radical options
PROTOTYPE
2 prototypes were created with different levels of development complexity and technical knowledge required:
• Basic version: the simplest to develop, using IS/IS NOT to determine which contacts would be included in the list. Possibly more complicated to users.
• Conversational version: a deeper redesign, using a more conversational interface to determine which contacts would be included in the list. Possibly simpler to users.
TEST
Tests were intended to verify if our hypotheses about the simplicity/complexity of designs reflected real life. Usability tests were run on the 2 options. We took the original real customer problem and turned that into a test task:
Imagine you work for a company with +10,000 employees across 5 countries. You are responsible for sending internal emails to employees from all locations. Your latest email is ready and you are preparing a list of recipients for this particular message.
Create a filter that:
(-) excludes everyone from Bolivia
(-) excludes managers from Canada.
By asking users to complete this task, we evaluated:
• If the inclusion/exclusion filter was clear enough
• If the separation between different groups of contacts was clear enough
• If copy was clear enough to guide users
Participants ended up creating the first filter set correctly on both versions, but instead of separating the Managers from Canada they were trying to add this part in the same segment, which would break the filter.
The first round of tests showed that the inclusion/exclusion was being understood. Our problem was making it clearer when the user had to start a filter set, so the attributes of different segments wouldn't be mixed up, resulting in incorrect filters.
ITERATE
Since the issue was showing on both prototypes, we decided to iterate both and see which would have the best results:
• Basic version: a container was added to separate groups more clearly. Also, the key action buttons that were previously positioned side by side were separated more clearly.
• Conversational version: new copy was added above the attributes to show how each would be combined with the next.
Taking the conversational style one step further helped users understand how attributes had to be connected: on the second test all users on the Conversation version were able to separate the filter groups correctly.
We moved forward with this version.
REFINE
With the solution defined, I went back to Sketch to refine the interface and build the remaining component states. During this stage, I also planned the basics of the filter interface on our upcoming Design System style.
HANDOFF AND DEVELOPMENT
With all the designs ready and reviewed by the team, I provided the files on Marvel for Handoff. During this stage, there can be frequent communication with developers to clarify some styles and interactions. When necessary, animated prototypes can be created to define the ideal timing of component movements. Also during this process, there are reviews to live interfaces, as the development advances.
