One the most satisfying things about being a UX Designer is updating and refining an existing user interface, especially one that customers have been using heavily for a long time. It makes a timeworn feature feel brand new. The payoff, of course, is getting to directly observe customers using it and hearing how much easier and more enjoyable it is to work with. After all, who doesn’t love hearing their work be praised? The path to success, however, is never quite as straightforward as you expect it to be, and updating AWeber’s subscriber search was no exception.
Implementing the ability to segment your subscribers using tags required some major changes to the underlying structure of the AWeber app. With that came the opportunity to freshen up the user interface and make some welcome improvements.
The old search interface consisted of a way to build basic queries based on a number of data points collected in the app.
The searchable fields were all presented in one big dropdown list and lacked a discernible organization strategy. After choosing a field, you can choose an applicable operator and value to complete the filter. Pressing “Search” would return all subscribers for whom the statement evaluated as true.
A new filter could be added by clicking the green “+” button. By default, this would create an “AND” statement, meaning that the results returned must evaluate true for both the first statement AND the second statement. So, in the query below, the subscriber must be currently subscribed AND be located in the United States.
To save this group as a segment, you would simply fill in a name for the segment and press “Save.” This would create a custom segment in the sidebar of the Subscriber Management page.
In our quest to update the search query builder, our first major requirement was to allow both “AND” as well as “OR” searches, in order to make searching much more powerful for our customers. This was a top request that I often heard in customer interviews while conducting research for this project.
Rather than having to completely roll our own solution, we first searched for existing query builder UI components that could be customized to fit our needs. jQuery QueryBuilder gave us everything we wanted out of the box and was relatively easy to implement. We had some concerns about the default UI design and anticipated that we may need to address these later, but the plugin allowed for AND/OR searches, nested groups, and the ability to compare nested groups to each other.
Thus, the first incarnation of the new query builder retained much of the default design of the plugin, with some basic AWeber visual styles incorporated (see below). We also added the “+” and “x” buttons in order to make adding and deleting rules a bit easier.
The plugin defines a single line of a query as a “rule” and any direct comparison of rules (with the AND/OR selector) as a “group.” A “tree” structure along the side shows the levels of comparison. We initially considered this feature to be a helpful visualization, so we left it in the initial version.
Out of the box, jQuery QueryBuilder allows for unlimited nesting of groups. As you can see, however, this can quickly get out of hand!
Honestly, though, the likelihood of anyone needing to nest a search that deep is remote, so we decided right away that there should be a definite limit of one sub-group within any existing group. Groups and sub-groups can contain unlimited rules.
With these basic settings in place, we decided to conduct our first round of usability tests to see how effective the query builder would be. Using a web intercept on the Subscriber Management page, I recruited 6 customers of varying technical knowledge of AWeber (beginners, mid-level, and long-term customers). We connected via video conference and I had them perform some basic searches and some more advanced searches that required them to create and compare groups using both “AND” and “OR” comparisons.
When asked to complete a basic search, most of the participants did so with no problems. When asked to complete a more advanced search, many participants didn’t see the “add rule” and “add group” buttons for quite a while. They seemed to grasp the concept of why you would want to choose an “OR” versus an “AND” search, but most of them attempted to click on the “AND/OR” button before adding a second rule to the query. They attempted this many times, even after it was clear that it couldn’t be clicked on until a second rule was added. Also, about half of the participants asked me what the difference was between a group and a rule. When I asked them to see if they could figure it out, most did. For some, however, it took them longer to get the concept of how to use them together.
In general, the results were mixed. Two of the participants were unable to build the advanced search without coaching. Another was able to do it, but it took him a few tries and a lot of time. The rest were able to do it with no problems. This proved to us that there was a lot of opportunity for usability improvements. We went back to the whiteboard and hammered out some ideas based on our observations.
The first lesson we learned was that our users tended to focus their vision in a tight radius around the left-hand edge of the query builder. This was where they chose their search fields, so their eye naturally gravitated there. We were quite surprised to see that the big red and green buttons on the right went relatively unnoticed simply due to their positioning. With that in mind, we opted to soften the buttons and put them in the middle of the builder. We also encountered a lot of confusion around the terms “rule” and “group.” To make this more clear, we opted for the term “filter” (since you’re filtering out specific members of a larger list) and “filter group,” which tied the two concepts together. The result was a visually softer UI.
We also opted to hide the AND/OR selector until a second rule was added. This removed the temptation for users to try interacting with it when it was not available.
In addition, we discovered that the tree structure on the left edge really didn’t make it any more clear how the statements were being evaluated. It simply required a modicum of cognitive load when the query got at all complicated. Instead, we observed our test participants trying to read the queries in a linear fashion, from top to bottom. With that in mind, we added the words “and” or “or” between each line so that it could be read easily.
Another thing to note – when we asked our test participants to search their subscribers, some of them couldn’t find the “search” interface. We therefore changed the section label from “Show All Subscribers Where” to “Search Subscribers.”
In the case of nested groups, we anticipated that it may not be immediately clear what will be affected when you delete one of the levels. Therefore, we displayed a red stroke around the items that would be affected when you hover over a delete button.
With these new design changes in place, we were ready for our second round of testing. This time we tested with 14 new participants, using the same plan as the first round. The only difference was that the second test was unmonitored. The participants were given instructions via a private Facebook group, describing which searches to perform and were required to submit a screenshot of their search queries to me by a specific time of day. I went back later and reviewed FullStory sessions of each participant to see how long the search took them and how difficult it was for them to construct. We saw a sharp decrease in the amount of time it took for participants to complete the queries, and most of the participants breezed through them relatively quickly. I received a lot of positive feedback about what an easy test it was.
The only thing I noticed was that there was no immediately obvious way to clear a search when you want to start over. We solved that easily by adding a shortcut in the top right corner of the interface.
Based on the testing we did, I’m confident that we’re now able to launch with the strongest version of the query builder that we’ve had yet. I had the support of some amazing UI designers who really nailed the visual presentation and whose passion for solving problems and helping our customers succeed led us to a truly elegant and user-friendly solution.