Document Management
The TL;DR
Qualifying a candidate’s fit for a job by tracking, collecting, and managing documents throughout their hiring journey is an important component of the hiring process for healthcare agencies, a core customer-base for Hireology. The Checklist and Document Collection features enable hiring managers to track tasks throughout their process and automatically collect qualification documents from candidates, helping them make an informed hiring decision.
The Challenge
Generative research conducted in late 2019 through early 2020 indicated that document management as part of candidate qualification was a major pain point for our healthcare customers and presented an opportunity to set ourselves apart in the market.
The research revealed a diverse reality around document management among healthcare agencies - a variety of documents are collected across multiple online/offline/in-person channels with material variation from state to state. We also saw through both anecdotal evidence and the UX research that healthcare users like using checklists to manage their tasks.
These takeaways led us to approach this problem in two parts: document tracking via a basic checklist feature and document collection. We also decided to take a tiered approach, with the checklist being a free, base-level feature available to all users, and document collection being a premium feature requiring upgrade.
Role & Responsibilities
UX/UI Designer
I was the lead UX Designer for both features and partnered closely with the Product Manager and Lead Engineer to define these solutions. This initiative was closely tied to company goals, so I presented to Leadership, internal stakeholders, and the company at large multiple times throughout the discovery and design process.
Scope & Constraints
While these features and the larger initiative were tied closely to company goals, the scope of the projects were very constrained. For the checklist feature, I was directed by Product and Engineering leadership to design a "quick and dirty" solution that could be developed and released as quickly as possible. For the document collection feature, Leadership made the decision early on to extend an existing partnership and integration with a third party company rather than build a native solution. As a result, I was constrained to come up with a solution that used the same API, UI, and functionality as our Onboarding product, which had been designed 4 years prior. I raised concerns about this decision throughout the process as my early discovery showed it would not solve many of our customers' pain points. However, it was decided to move forward with the original plan. So, while I don't believe the final solution solves the full problem, I worked within the constraints I was given.
The Process
Document Checklist
1. A new hiring step
Based on the requirements and the direction for speed and simplicity from Leadership, my Product Manager and I decided it made the most sense to make the Checklist a new hiring step that users could add to their hiring process when creating a job in the platform. This would allow users to create reusable, job-based templates and ensure they are collecting the same items and completing the same tasks for each candidate.
My first step was to review the existing hiring steps to determine whether there were any patterns that could be used for the checklist. I created wireframes using UI patterns from other hiring steps but, after talking to one of our Front End Engineers who had built the original UI, quickly decided it wasn't the right way to go. So, I explored a simpler, more straightforward design.
1st round wireframes
2nd round wireframes
2. Specific or generic?
While the original intention behind this feature was to build a checklist for hiring managers to track which documents they've collected from a candidate, our research and anecdotal evidence told us that healthcare hiring teams like using checklists for everything. So, in order to make this feature flexible and useful for not just healthcare document tracking, but also for task tracking and for our automotive and professional services customers, we decided to design a generic checklist that could be used any way the user sees fit.
3. The final solution
Due to the desire to develop quickly, we decided to keep the MVP scope as simple as possible. We considered adding a way for users to set expiration dates and issuers for documents they collected, as well as marking items as optional, and providing industry-specific templates. The final solution was a basic checklist that enabled users to enter any items they desired, save reusable templates, and displayed metadata around who and when an item was marked complete.
Final designs
4. Adoption & usage
This was the first project marked the first time that our Product team started tracking adoption and usage of a feature post-launch. We tracked performance metrics for 30 and 60-days after the feature was first released.
-
30-days post-launch
-
87 organizations adopted the checklist feature across 380 open jobs
-
Adoption was surprisingly higher among Automotive (49%) customers than it was among Healthcare (37%) and Professional Services (14%)
-
The most common checklist item was "Driver's license/Identification"
-
-
60-days post-launch
-
146 organizations adopted the checklist feature across 762 open jobs
-
Adoption among Healthcare (48.6%) customers was higher than Automotive (41.8%) and Professional Services (9.6%)
-
The most common checklist item had become "Onboarding/Orientation"
-
The goal was to have 10% of our Healthcare customer base (~110 organizations) using this feature by the 60-day mark, but we fell short by about 40 organizations.
Document Collection
1. Native solution vs. existing third party partnership
While the checklist feature was in development, the Product Manager and I turned our attention to the next level of document management, document collection. Early on in the project, there was question about whether we should build a native solution that would allow users to upload documents they had collected from candidates directly to the app or use an existing integrated solution from a third party partner called ClickBoarding. The Engineering stakeholders, as well as myself and the Product Manager felt strongly that we should build a native solution because it would allow us to fully solve the customers' pain points in a way that the integration would not, and it would be worth the investment long term. However, Product and Business Development leadership decided to move forward with extending our existing partnership with ClickBoarding because it would solve the most immediate pain points, lend it self to upsell and revenue opportunities, and it would be the fastest way to market. Engineering leadership agreed to this solution on the condition that there was minimal development effort required. This meant that the solution I designed had to utilize the functionality, API, and UI from our Onboarding product, which was built 4 years prior as an integration with ClickBoarding.
2. Understanding the customer's process
Before I could start designing a solution that allowed users to collect documents from candidates, I had to better understand how our customers were currently doing it. I reviewed the generative research from early 2020 and put together flow charts illustrating the hiring process for 3 healthcare prospects.
Hiring process - Prospect 1
Hiring process - Prospect 2
Hiring process - Prospect 3
3. Learning the ins-and-outs of ClickBoarding
Once I felt I had a stronger grasp on how and when customers are currently collecting documents from their candidates, I started familiarizing myself with the existing solution I was to be working within. I partnered with the Quality Assurance Engineer responsible for the integration to learn the ins-and-outs of what was possible and what the candidate would experience. I wrote down all open questions and considerations for the design phase, and documented the candidate's experience so it didn't get lost in the customer's user experience.
4. The design phase
The next step was to start designs and figure out where this feature makes most sense. While our app does not have a general place for users to upload documents, there is a documents section in the profile for each candidate on a job that contains their resume, cover letter, application, and prescreen survey. Because of this and the flexibility to build a custom, native solution in the future, I felt it made the most sense for this feature to live with the rest of the candidate's documents as an additional tab called "Qualification Documents". This tab would only appear if a customer has a subscription to Click Boarding through Hireology, giving them access to document collection pre- and post-hire. Throughout the design process, I made clear to all stakeholders which problems this feature would solve and which ones it wouldn't so everyone was on the same page.
Final designs
5. Adoption & usage
This feature is still in the development phase but is expected to be complete by mid-November 2020. We will be tracking the adoption and usage 30, 60, and 90-days post-launch and I will update the numbers here as they become available.