Hive Enterprise
ARTIFICIAL INTELLIGENCE FOR EMPLOYERS

Overview

FINAL DESIGN DASHBOARD

STRUCTURE OF THIS PROJECT

Throughout the 6 months of Phase 1 (Enterprise) we worked closely with AI Data Scientists to create artifacts and requirements for the AI workflow and process. With this product being feature heavy, we worked, testing and reiterated at a very quick pace.

MONTH 1
DISCOVERY AND BUSINESS RESEARCH

The Stakeholder/CEO of the company - thought there was a need in the recruiting market to be filled - matching candidates to a job and making a sale was a long and tedious process with large areas that needed improvement. He knew it needed to be compelling and different from LinkedIn and ideally would love for this product to replace human recruiters altogether and eventually have Hive do a bulk if not all the work of matching qualified candidates with postings.

BUILDING SOMETHING BETTER THAN LINKEDIN

MONTH 2
USER RESEARCH

HOW MIGHT WE ...

• Define the primary persona
• Needs of the recruiter

We started gathering data to answer these questions by conducting heuristic observations on the products we deemed our direct competitors.

IN SPECIFIC, WE OBSERVED RECRUITERS:

• Log on and create an account on LinkedIn and other products
• Create a profile for a client
• Create a job posting for a client
• Search for candidates for the job posting
• Reach out to targeted candidates
• Reply to inquiring candidates
• Schedule phone interviews

PERSONA BUILDING

We gathered a lot of preliminary data from the heuristic observational study. From that data we constructed a survey of 10 questions about using products like LinkedIn and sent it out to a list of 500 recruiters. We brought on an agency that had a great focused database and were able to get back over 280 responses which gave us great data.

From these 2 data sets we came up with our personas - Maddie, Pat and Cynthia:

We found the persona of Cynthia held the most points that were common with all the personas we developed and all the real people we observed.

FINDINGS: USER RESEARCH

From the observational study and the survey, we noticed a pattern of the following user NEEDS and PAIN POINTS:

PAIN POINTS

• Keyword matching accuracy in resumes

• Categorizing resumes using an application tracking system (ATS) such as Bullhorn

• Revising and helping edit candidate resumes in prep for client view

• Finding the perfect fit for her job posting

• Lots of manual, tedious, repetitive and time consuming labor when it comes to first wave screening of applications and resumes even when using an ATS

• Quickly finding through precise searching, PASSIVE (those not looking and currently employed) candidates

• Interview/hiring process system management

• Waiting on a client for hiring decision to be made

• Candidate “offer” management

MONTH 3-4
IDEATION, SKETCHING,WIREFRAMING & SPRINTS

THE PROBLEMS WITH LINKEDIN

• Hive for Recruiters needed to have a way of effectively showing results beyond keywords.

• One of LinkedIn’s biggest problems is authenticity. People use keywords to endorse themselves and others for skills that they don’t necessarily possess.

• LinkedIn also needed more support from the Artificial Intelligence in other tasks like creating job posts and communicating with candidates natively.

• LinkedIn needs to integrate into current client work methods like Application Tracking Systems.

From our previous discovery phase research my team narrowed down what we needed to focus on for our Recruiter persona:

• Finding more relevant candidates and less searching through hundreds of results using Artificial Intelligence. For instance:

— Out to 10 candidates 1.3 will respond in total.

— Out of 100 emails sent, the recruiter may identify 1 potential viable passive candidate.

— Out of 500 candidate the recruiter will have 3-5 viable passive candidates to send to a client.

— Out of 30 potential passive candidates, on average, only 1 will show any interest.

• Redesigning the candidate search process using Artificial Intelligence

• Using Artificial Intelligence to auto tag and classify potential candidates and be constantly building search sets for anticipated search criteria from the recruiter.

• Using Artificial Intelligence, create a many offline searchable candidate databases for the recruiter

We needed Hive to be both competitive to LinkedIn as well as an appealing add-on enhancement to LinkedIn. We kept referring back to our competitive landscape and Engagement analysis to guide to our design of Hive Enterprise.

We used SimilarWeb.com to obtain a keyword search for recruiters that were using the LinkedIn RPS (Recruiter Professional Services) on their product. We gained great insight from the below list to guide us through our ideation of Hive Enterprise.

IDEATION

Taking in both business and user data, we first did a white board exercise categorizing the most important things we needed to fix about this process for Cynthia the recruiter.

FOCUSED SPRINTS (3, 2-WEEK SPRINTS)

RESULTS FROM SPRINTS

1. ENTERPRISE SITE MAP

We eliminated features and pages that did not serve the recruiter to make the experience focused on getting to a relevant candidate. Some of the features eliminated:

• Advanced Search. Eliminated in both logged out and logged in state. It created a higher bounce rate once they didn’t find what they were looking on their own criteria.

• Recommended candidates feature. Having carrousel displayed of recommended candidates in irrelevant pages derived recruiters from their search goals.

• Less onboarding steps. Making it all about payment, creating a company profile and posting a job.

2. ENTERPRISE SITE FLOW

• Logged in experience. We eliminated the logged out candidate database with the advanced search tool to make make a better and more customized match for the recruiter.

• Payment first. We wanted to make sure to secure payment before using our product and for the recruiter to be able to customize his experience (optionally) before showing our match results.

• Post a job, find a candidate. In order to create a more effective experience with the Artificial Intelligence algorithms, we decided to match candidates to a specific job. It’s a mandatory requirement.

3. PRELIMINARY REQUIREMENTS FOR CANDIDATE SEARCHING

• Identifying best practices for candidate searching.

• Information Architecture. Identifying what information could be displayed in our dashboards and candidate profiles with the power of our AI algorithms.

• Designing for Artificial Intelligence. Defining our data decision making system with coverage, salience, transparency, malleability and instrumentality for recruiter’s success. Uncover crucial patterns and edge cases.

ACTIONS FROM SPRINT

Discoveries and Needs from Sprints

• Contextual AI - focused on the meaning of words and their context in sentence structure and in relation to each other sentence and paragraph - such as when certain words are used in a sentence and not just the meaning of an individual word on it’s own. This was used to determine eligibility of the candidate compared the candidate resume to the job description.

• Job Description Tool

- AI as Tool - AI was also needed to be used as a responsive editing tool for the recruiter to write job descriptions and job requirements with scoring.

- Job Description Scoring Tool - After writing the job description - AI would score it, and give recruiters suggestions for improvements and optimization. The AI would also give feedback on the ideal amount of words, measurable results listed, job level, words to avoid, additional keywords, identifying soft skills from hard skills as well as suggesting improvements according to the semantic of the description.

Failures

• As we tested our initial on-boarding we found it was too extensive and feature heavy which made it complicated to the user. Feature heavy made it difficult to create a job or to execute candidate matching to a job posting for the recruiter.

• Our way of grouping and displayed candidates in a carousel with matching percentage was overkill and unnecessary - the user wanted to see things in grids and more straight forward without gimmicks or bells and whistles.

• We found that our work focused mainly on the Recruiter and did not test for Job Seeker - we made a decision to break these apart and create a PHASE II of this product focusing on the Job Seeker.

MONTHS 4-5
FINAL DESIGN AND TESTING

After testing the comps from the Sprint, we realized testing failed because the Enterprise/Recruiter dashboard was too feature heavy.

We did some more ideation and modified the designs and retested (images 1, 2, 3 below):

• Candidate Match Display - was modified to look as a continuous list instead of being

• We eliminated a section of “Recommended candidates” that were being displayed in pages where they weren’t relevant. (Matches - image 1 below.)

• Recruiter Dashboard - menu was simplified in it’s display to match a hierarchy of relevance to the users best interest. (Dashboard - Image 2 below.)

• Eliminated Advanced Search because if we are doing the matching and the AI is accurate and not using keywords, it’s unnecessary at that time in the sprint process. Our tests showed that really relaying on the accuracy and innovative technology we had to eliminate the advanced search feature which works with keywords instead of semantic technology.

• We created a feature for the recruiter to see how many times that candidate’s profile has been viewed by other recruiters.

FINAL DESIGNS

Enterprise Candidate Results.

Enterprise Candidate Match

Enterprise Job Post

Enterprise Calendar

Enterprise Mobile Designs

MONTH 6
FINAL TESTING & HANDOFF TO DEVELOPERS

We designed and built-out the whole product, tested and handed off the files to the development team.
What the Developers received:

• Annotated screens

• LinkedIn implementation recommendations

• AI requirements, justification, logic patterns and organizational groups of data

As the product was built, we tested it with recruiters and refined usability and design. We utilized moderated in-person and remote testing with both external and internal (inside a company) recruiters.

END OF PHASE 1

After 6-months the stakeholders decided not to launch the product because the Data Scientist was still composing and building the AI engine.

Since this project was broken up mid-stream into 2 products, Recruiter and Job Seeker or Enterprise and Consumer, we planned a 2nd phase build.

CONCLUSION & SUMMATION
+ FINAL THOUGHTS

What I learned from working on this project?

This project was a fantastic opportunity to dive deep into the territory of AI, which I had previously little knowledge of. Understanding the process and adapting its technology to an effective experience, eliminating assumptions, starting over and over was a challenging and rewarding mountain to climb. By observing our users carefully and creating multiple user personas led us constantly into what was most important while building the interface.

What you would I have done differently if you knew then what you know now about the project?

If I had the opportunity of starting over I’d definitely would’ve stood my ground while defending our user more. Sometimes stakeholders had strong interests that did not provide value to them. I would’ve also tried to complete more sprints and tested many more times, and absolutely incorporate more of the AI personality we created into every interaction throughout the interface.

What you would have done next had you continued with the project.

• Creating a system of implementation from and to other platforms like adapting Google Hire or using Hive’s API to integrate into ATS systems and to train our AI to adapt to those other systems.

• Creating customization options for customers who use it as an integration tool - like internal HR department could customize Hive according to their unique workflow.

• Create a better experience for recruiters by simplifying the dashboard even more, and giving them more access to data.