Contact Filter Planning & Design
ActiveConversion is a B2B SAAS application that digitally fingerprints people interacting with your marketing, qualifies them based on engagement levels, and provides avenues to nurture and engage with the most interested prospects.
ActiveConversion was adding a new and integral feature to its flagship product – contact filtering. Thus far in the product, each core function you wanted to perform with a specific contact had a separate screen and reporting. Want to add a contact to a mailing list? See a contact’s subscription status? Go to Mailing Lists. Want to see that same contact’s engagement level? Go to Prospects. Or Leads, if they have a high level of engagement. Want to see which sales rep that contact is assigned to? Go to Leads, Prospects, or the Sales Rep screen.
This new Contacts screen and filtering replaced four screens with one unified way to review and manage your contacts. Sounds great, right? Right. Not only would this make our users’ experience with the product a lot simpler and more enjoyable, but it would also reduce development complexity as the previous screens will no longer need to be maintained. Because we were merging four screens into one, we still needed a way to view and filter contacts to perform the same functions as were available on the previous screens. This is where a contact filter comes into play.
Our development team had already prototyped the new Contacts screen, along with a filter feature, in our staging environment. The product lead came to me for suggestions on how to improve the filter interface. He wanted to start implementing the changes as soon as possible, so I had to perform guerilla UX research and propose UI improvements in short order to get the most obvious challenges addressed. Here is what editing a filter looked like when I started working with the team on it:
Before you can do any sort of user interface work, you need to understand your users and what they’re trying to accomplish with the interface.
ActiveConversion is intended for business users involved with either sales or marketing. This maps out to marketing managers and coordinators, sales managers and reps, and VPs, directors, or leaders of these departments.
Our team previously had made proto-personas for all of these roles, but in this case, I chose to use Intercom’s Jobs To Be Done method to understand what our users need from the product. Although users’ motivations, behaviors, and needs can be very diverse, at the end of the day each piece of software solves a problem by getting a specific job done for their users. These jobs are the same, or very similar, even when the motivation for doing the jobs might be different.
Jobs To Be Done
Below are the 3 main types of users, along with the jobs users needed to accomplish via the new contact screen.
- I want to know which leads are ready to assign to my team
- I want to know if my sales team is following up with the leads I give them
- I want to know what specific leads are interested in
- I want to know when specific contacts are ready to engage
- I want to import my contact lists so I have all my contacts in one place
- I want to be able to filter my contact list based on tags and activity
- I want to easily add contacts from my filtered list to specific email or nurture campaigns
- I want to export my filtered list with email opt-in status for my records
Planning & Discovery
Since I’m a regular part of ActiveConversion’s product team, I already had insight as to who was responsible for the project (the development team lead), who had approval power (the software architect), and who knew about the history of the product and why decisions were made (our president, myself). Since I’ve been at the company and using the software for years, I already knew the target users (detailed above), product strategy, and success measures.
This made discovery quite simple: I needed to figure out what the feature needed to do (and why), apply it to my knowledge of our customer base and their goals, and then find the best way to achieve that in a short amount of time.
I sat down with the development lead one-on-one to hash out what the feature was, what it was replacing, what it was supposed to do, and how long we had to work on it. He also ran me through what the team had implemented so far. The outcomes we wanted to achieve were:
- Simplify the process of adding and editing contact filters
- Improve and clarify the terminology used in the contact filters
- Provide a heuristic review to identify potential issues with the current implementation
During the one-on-one meeting, I’d noticed that there were a few critical functions from the screens we were combining that were either missing or hidden in sub-menus in the UI. So after our planning session, I ran a feature audit on which core activities each of the screens to be combined contained.
|Prospects & Leads||View most recent contacts based on engagement/score, assign sales rep, tag, upload to CRM, add to an email list, add to a nurture email, show/hide, watch, delete, show most recent first|
|Contacts||View contacts from all time, sorted by name. See if contact is subscribed/unsubscribed, opt-in status, import or add single contacts, merge duplicate contacts|
|Sales Rep Activity||View contacts assigned to particular sales reps (or unassigned), which ones require followup, bulk assign contacts to specific sales reps, last lead & rep activity, add to nurture/mailing list, show/hide, watch delete, tag|
After consolidating the above list and comparing to the existing implementation, there were two gaps we would need to address during this process:
- The main screen needed to either add or bring forward the main activities our users would be looking to accomplish: upload contacts to a CRM, add them to a mailing list, import contacts, and sort by most recent activity/contact name/score.
- The filters needed an option to view a specific date range and filter by which sales reps contacts were assigned to.
Between our planning session and the requirements gathered, I now had enough information to start researching.
I flipped through my burgeoning arsenal of research methods to find the best fit for the situation, based on the aforementioned constraints. Here are the two methods I chose for this project.
People develop usability expectations from the products they use every day. Our software gets benchmarked against these pieces of software even if they aren’t directly competing with our application. This allows some freedom in competitive research in that we review not only direct competitors but also products with different intent but similar functionality.
I selected Pipedrive (our company’s preferred CRM) and Google Drive for insight into current filtering methods.
Many of our core users use both applications regularly as does our internal team. This makes them ideal applications to draw ideas from for user interface, since familiar interactions feel more intuitive than new ones.
Pros and Cons
After reviewing the two applications, I put together a list of the pros and cons of each application as it relates to our use case:
|Criteria||Google Drive Search & Filter||Pipedrive Contact Filters|
|Strengths||Simple, intuitive||Very customizable, can share filters with other users|
|Complexity||Simple||Takes some thought to use|
|Display type||Large dropdown||Modal window|
|How the filter is referred to & terminology||Not referred to, just exists. Uses application-standard language for contacts, date range, etc.||Filter (Filter Title), Conditions. Uses application-standard language and/or column titles for name, date range, etc.|
|More content/data than needed?||No||Creator, last modified, titles for all items when some could be assumed or minimized|
|General usage||Dropdown menus with multiple selects: Type, Owner, Anyone, In Trash, Starred||Stackable programmatic conditions: show contacts that match ALL or ANY of these conditions|
|CTA buttons||Reset, Search, Learn More||Delete, Preview, Save as New, Save, Add Condition, Visibility (Private/Shared)|
|Can edit titles||N/A||Bottom of modal|
|Ways to exit||X top right, click off of the filter area||X top right, click off of the filter area|
|Content expands with more filters||No – Static size||Yes – can get very long|
|Minimum screen width to access filter||850px||950px|
|Design consistency||On point||On point|
I reviewed the existing implementation in the staging environment to see how well it complies with not only recognized usability principles but also to the application itself. Some of the key questions I based my evaluation on were:
- Can I easily manipulate the data to match the main Jobs To Be Done that were defined for this project?
- Which key actions are most important for the majority of our users?
- Are these key actions immediately visible and usable?
- Is it clear which actions are important right now?
- Is the terminology what a user would expect in our app? Is it easy to understand?
- Is there extra information in this view that can be removed or moved down the visual hierarchy?
- Does the visual and content design match the app’s current style guide for continuity?
- Will the information displayed be viewable above the fold on different devices?
Based on this evaluation, I saw the opportunity for a few adjustments when designing the updated interface. The key ones were:
- Making core functions easier to access: assign to a sales rep, tag, upload to CRM, email
- Showing more data per screen (50 records instead of 25) to make contacts faster to review
- Simplifying the presentation and usability of creating and editing filters. This would involve transitioning from stackable conditions approach to a dropdown menu approach, as well as getting rid of the “conditions” terminology, which is more programmatic than user-focused.
Rapid Design Lab
The development lead and I met and we spent some time sketching out what the feature changes might be. We discussed implementation ramifications and co-evaluated the pros and cons of varying methods of displaying data. That meeting was invaluable as it gave us a chance to align on the logic behind the UI decisions and why and how each item was displayed. It also gave us a chance for the development lead to clarify how our clients use the different features in their sales and marketing workflows.
User Testing & Validation
The main stakeholders in this scenario were the lead developer, myself, and our users. I’m fortunate enough to have a marketing team member on hand who uses the software daily, so her workflow and requirements are very close to that of our marketing users.
I pulled her into the conversation to validate a few of the assumptions I had made when designing:
- The most common functions I’d want to do with my data are assigning a contact to a sales rep, tagging, uploading a list of contacts, or emailing selected contacts
- The above functions are now easy to find and align with the rest of the product in terms of how they are displayed and used
- Importing or merging contacts is only done occasionally (they were moved to the hamburger menu, far right, and not visible on page load)
- Providing CSV export for your data view would help with the parts of your processes that aren’t done in the software
All of our assumptions seemed on point, but the developer still had a few questions about how to implement the “show hidden” feature as he thought it should be more prominent and have additional functionality. I recommended we run that one by the product architect for clarification and a third opinion, which worked out well. That feature was planned to be phased out eventually, so we decided to keep the UI as discussed.
Wireframing & High Fidelity Prototyping
Once the plan was hashed out, I moved on to designing in Adobe XD. Using our pre-existing library of common elements, I recreated the most critical parts of the Contacts screen, the filter modal window, and what the dropdown for each menu would look like. Since we already have a fairly comprehensive set of guidelines on how the application elements look and behave, it was a matter of converting the wireframe elements into hi-res versions that matched with how our application already looks and functions.
The feedback provided validated that the solution we had come up with was ready to implement, so I handed it the Adobe XD designs off to the development team lead. He would then communicate what was needed with the developers and oversee the implementation.
Due to the existing development team setup and process, this was my last involvement with the feature until a post-release evaluation. If I had more time available to dedicate to this project, I would have loved to be in on QA and testing of the feature before the release went out to catch any potential issues that might arise.
Once any new core functionality or feature is launched, I cycle back to the beginning of the UX cycle – evaluation. This is an ideal place to do some UX monitoring with heatmaps to see how the screen is being used, review the analytics logs to check usage, review the help center for any feedback on the changes, and do some live usability testing with real users and real contact data. These reviews bring new user experience challenges to dig into. That’s where the exciting stuff begins!
Adobe XD, Adobe Illustrator, Adobe Photoshop, Microsoft Excel
Roles and Responsibilities
I was the sole UX and UI designer, responsible for requirement gathering, developing proto-personas, guerilla UX research, competitive assessment, user interface design, and prototyping.
Our development team lead better understands how our clients work with their contacts, the feature is simpler to understand and use, and visual style matches the rest of the application.