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.

The Backstory

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.

The Scenario

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:

The Users

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.

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.

Planning Session

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:

1. Simplify the process of adding and editing contact filters
2. Improve and clarify the terminology used in the contact filters
3. Provide a heuristic review to identify potential issues with the current implementation

Gathering Requirements

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

Defining Requirements

After consolidating the above list and comparing to the existing implementation, there were two gaps we would need to address during this process:

1. 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.
2. 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.

Research

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.

Comparative Assessment

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

Heuristic Review

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:

1. Can I easily manipulate the data to match the main Jobs To Be Done that were defined for this project?
2. Which key actions are most important for the majority of our users?
3. Are these key actions immediately visible and usable?
4. Is it clear which actions are important right now?
5. Is the terminology what a user would expect in our app? Is it easy to understand?
6. Is there extra information in this view that can be removed or moved down the visual hierarchy?
7. Does the visual and content design match the app’s current style guide for continuity?
8. Will the information displayed be viewable above the fold on different devices?

Opportunities

Based on this evaluation, I saw the opportunity for a few adjustments when designing the updated interface. The key ones were:

1. Making core functions easier to access: assign to a sales rep, tag, upload to CRM, email
2. Showing more data per screen (50 records instead of 25) to make contacts faster to review
3. 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.

Design

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:

1. 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
2. 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
3. Importing or merging contacts is only done occasionally (they were moved to the hamburger menu, far right, and not visible on page load)
4. 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.

Implementation

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.

Next Steps

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!

Duration

2 Weeks

Tools Used

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.

Accomplishments

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.