Embedded Files
CASE STUDY: CREATION OF UNIFIED ORDERING MANAGING PLATFORM
Enterprise, B2B, Human Resources, End to End Design
Background
Sterling, a company that performs pre-employment background checks, had 2 main platforms. One was for people applying for a job (referred to as Candidates) to submit information such as work, address, and education history, in order that it could be verified. The other platform was aimed at the businesses who were hiring these prospective employees.
Who is this for?
There are two different sets of users that utilize Sterling's background check services:
Candidates
Candidates are people applying for a job who need their background information to be verified. Sterling had a fairly modern candidate-facing application to collect this data and start the verification process.
Clients
Clients are the companies hiring these prospective employees. Sterling did not have a unified client-facing application where clients could order different kinds of background checks.
Goals
The goal was to unify a variety of disconnected systems and platforms into a single client-facing self-serve platform called Client Hub. This platform would allow clients to:
directly place an order for different background check services
monitor in-flight checks
be able to adjudicate (decide if they wanted to move forward with the hiring process of a given candidate)
walk the client through the "adverse action" process (a legal process required by some states and jurisdictions when an employer decides not to hire a candidate based on some result in the background check)
Additional Context
Up until this point, there was no unified platform for clients. Different products (e.g. education verification, pre-employment drug screen, sex offender checks, etc) had to be ordered through different platforms whose look and feel were inconsistent. Some products could not be ordered directly by clients at all, and required Sterling employees to order them on behalf of the client using manual or internal systems.
User Interviews
The first step was to conduct user interviews of some of the client-facing success teams and clients themselves to better understand the needs and current pain points. These interviews varied from informal one-on-one meetings with Sterling Client Success reps all the way to formal, structured meetings with entire HR teams for some of the larger clients.
Findings
It became apparent right away that a few areas would have the biggest immediate impact:
Self Service Ordering
Self-serve ordering would greatly reduce how much time Sterling customer-service teams spent in the day to day management of these client orders. Some products could not be ordered directly by clients themselves.
One-Stop Shop
Aggregating all in-flight orders would be a massive improvement for Client HR teams to manage and track. Since these systems were all disparate up to this point, it was very difficult for clients to see the whole picture, as they would have to check statuses in multiple systems.
Sorting and Filtering
The ability to sort and filter orders would be critical. All orders needed to be in a single place, but with larger HR teams, the ability to filter orders by type would allow both a big picture view of all orders as well as orders in a given state (e.g. orders waiting for candidate action)
Initial Designs
Since a significant percentage of clients were large enterprise level companies with potentially large amounts of orders in flight at any given moment, we landed on a large table format. This coupled with filter-tiles would not only allow user filtering, but also metrics to be displayed about how many orders were in any given status. A user would be able to look at the dashboard and immediately see how many orders were in a given status. By clicking on that filter-tile, they would be able to focus solely on orders in that category. We also created a status of orders that were waiting for client action, effectively creating a task list of orders that were stuck awaiting client action.
User Feedback
We were lucky to have a number of clients sufficiently invested who were more than happy to participate in user testing and share their feedback.
The initial round was more feedback gathering. While clients brought up some relatively minor points, they were generally pretty excited about the designs, saying that this would greatly improve their efficiency.
One Big Miss
One thing that came out of the user feedback sessions that we failed to account for in the initial round of designs was the ability for a client user to filter based on assignee. Different clients' HR teams were structured very differently from each other. They wanted a way to assign orders to certain specialized team members (e.g. one HR person who only handled pre-employment drug screens). It became evident that we could not make assumptions about how their HR teams were structured. By allowing the clients to assign these orders to the HR teammate, they could better organize their orders in a way that made sense to them without us dictating how their teams needed to be organized.
User Testing
Once we had a solid idea of what we were going to develop, we spent a fair amount of time conducting user and usability tests. These took the form of:
un-moderated usability testing using the usertesting.com platform
moderated testing with actual clients using high fidelity prototypes. We paid special attention to making sure these testing sessions included different roles in the Client’s HR teams (high level managers, general HR team members, and specialists)
Engineering Challenges
Once User Testing was complete and we were ready to start development, we ran into some engineering challenges. The initial approach from an engineering perspective was to have a single unified front-end, that would interface with the existing legacy platform back-ends. That way, we didn't need to recreate all these disparate legacy systems from scratch. We would simply integrate with the legacy back-end systems. However, from the user's perspective, it would feel like a single unified experience.
The problem was how to prioritize the migration effort of our existing clients. Prioritizing this work became much more complex than originally expected.
Dev Resource Intensive
There were a number of these legacy systems, and only a finite amount of development resources. We had to prioritize which systems we integrated first. Not all clients used every system. This meant that existing clients could only be migrated to the new system once all the systems they relied on had been integrated. This created a complex client migration strategy and resulted in some clients not being able to use the new system until certain critical pieces were in place.
Legacy Tech Stacks
Since the legacy systems were built with a wide variety of tech stacks, it would be easier to integrate some than others into this new Client Hub platform. A great deal of thought had to be put into how to prioritize the order in which these systems were tied into the new Client Hub. This would delay when we could migrate clients over.
Migration Challenges
The result of this was that some clients would be working on the new Client Hub, while others were still working on the legacy systems while waiting for certain pieces to be integrated. While this created challenges for the internal Client Services teams, the clients themselves did not necessarily have visibility into this issue as they were either migrated or not.
Outcome
Despite a relatively drawn out migration process, Client Hub was eventually rolled out to all clients with great success. This platform has since enjoyed universal adoption amongst clients and was recognized in the industry as a standard to aim for. Additional net-new functionality is continually being added. Sterling was recently acquired in a merger by one of its competitors largely based on the success of this platform and will be abandoning their legacy client-facing system and migrating all their clients over to the Sterling Client Hub.
Artifacts
Client Hub Dashboard in its most recent iteration. Filter-tiles are color coded to match status (while remaining accessible). Clicking on any of the filter tiles, will filter the table to show orders by status. Users can also filter by who the order is assigned to. In the case of a large client with a large team of HR specialists, orders are assigned to individual team members. These team members can then filter the list to see only orders assigned to them and use this as a task list.
In this example, clicking the filter-tile for Started reveals secondary sub-filters. Users can further refine the filtering parameters for this view. This is useful when the table contains large numbers of results.
Clicking any of the rows will open up the "drawer" which slides out from the right. The drawer contains details about the highlighted order and allows users to take action. Notice that the drawer does not overlay the entire table. This allows a user to click on a different row, changing the contents of the drawer to that newly selected order. This is useful to users who need to go for a deeper dive into a number of orders, without having the drawer open and shut every time.
Google Sites
Report abuse