Background

Bullhorn is the leading ATS (Application Tracking System) and CRM (Customer Relationship Management) software for staffing agencies. 

Problem

From research and user feedback, the product team learned that our customers struggle to keep their data inside Bullhorn accurate and up-to-date.

For example, to make business decisions, a staffing company's sales leader needs to run reports from time to time to see how many clients are active hiring. But because her employees are not updating client status when a client stops hiring, the number of active clients might be highly inflated.

I teamed up with a product manager and a development lead to find out if we can help solve problems like this for our users.

My Role

With the help from the product manager, dev lead and colleagues from customer success team, I owned the UX of the project from ideation to launch.

Research and Product Strategy

First, I wanted to understand what's causing the problem, and their current workflow of addressing it. The product manager and customer success team helped me identify and recruit two dozens users and business leaders at companies who have these problems.

Through these conversations, I identified their common goals and frustrations regarding data upkeep, and mapped out their current workflow. I summarized the research, presented it to the PM and the dev lead. 

We worked together and came up with a feasible solution we think will best help businesses and their users reach their goals the most - we would provide a tool inside Bullhorn, an admin can use it to create data automations based on their companies' business rules and best practices.

User Flow

Because this feature doesn't exist in a vacuum, I first mapped out the entire user journey when an admin user deals with data upkeep, including steps before and after using this product.

Taking the context of this feature into consideration, I then zoomed in, and mapped out the user flow of this particular feature.

Design Challenges 

In both the trigger setup and action setup steps, configuring conditions is the most complicated part. I worked with the team and listed out the kind of structures of logics we thought we we have to be able to handle, and white boarded some ideas.

On one hand, I want it to be as robust as possible, to be able to handle any complicated logic.

On the other hand, although Bullhorn admins are mostly tech savvy, they are not developers, so I want the UI to do the heavy lifting. 

While evaluating these explorations, I consulted with our own customer success team for input, who have built most of these customizations for customers. They told me that more than 90% of the conditions they wrote only had no more than 2 levels of logic. In other words, conditions like:

(A or B) and (C or D)

is almost as complicated as it gets.

After discussing with the team, I landed on a design for MVP that is closer to the second option, and it only handles a maximum of 2 levels of logics. We’d rather have 90% of our user using this tool to solve their problems easily, than having 100% of the user having difficulty learning it. Besides, the 10% edge cases are not unsolvable, they have existing solutions to fall back on.

Lessons from Testing

Languages - since this project is so technical in nature, I used some more technical languages in the design. When users see terms like “Trigger” and “Outcome”, they take a minute to translate them into everyday language. So I went through a iteration that translate these terms. “Trigger” became “When”, “Outcome” became “What”,

Confidence in Automation - When asked if they will use this feature. Some of them say yes but with a high pitch. When I dig deeper, I found out that most users are skeptical of automations they build themselves through UI. To instill confidence, I put testing feature in each step of the setup, and added an activity log so users can debug.

Leaving and Picking it Up: Unlike other features in Bullhorn, users point out that they might take a while to think through the automations they need. So I added a “save draft” button so that users can leave the setup process and pick it up later.

Final Design