DeepDive
πŸ•΅οΈ

DeepDive

Problem Statement:

‍DeepDive was a product that came through a real need to solve a pain point the company was having. As part of supplying labour to the heavily regulated security industry, we needed to ensure all our users were fully background checked and compliant to the BS7858 (security specific) standard before they were allowed to be booked in for shifts on the app.

Our current solution was to outsource this to a third party who would handle the capturing and checking of the information. However, this was a huge cost to the business and because of the poor user experience also a massive drop off point for our users. By bringing this in house it would save the business at least Β£375,000 in costs each year, as well as retaining a larger percentage of our user base and improving our percentage of fully compliant workers.

We had recently hired a Head of Compliance who had deep expertise in the area and proved to be a fountain of knowledge on anything relating to compliance. This platform would allow her and her team to background check our workers in-house.

‍

‍

‍

Process

‍The first step was to gain a deep understanding of the problem space. We conducted competitor analysis on various background checking providers and went through the current flow our third party providers sent out to our users. It was quite obvious to see why this was such a pain point for our users, it was a long and tedious process that most of the time was just down right confusing too. This was the same feedback we received from our users through intercom, a lot of the time they didn't receive the emails, didn't have time or were just confused by the process.

‍

‍

‍

image

A circular design thinking approach

image

Example of the email our users would receive. All information capture would take place off the app

image

Not the most enticing screen when trying to convince our users to go through a lengthy background check

image

Obviously our users were struggling with it too

‍

I spent lots of time with our Head of Compliance to understand the nuances of what information we needed to capture and in what form. It soon became apparent this was not going to be as straightforward as initially thought, we had to capture everything. From performing RTW checks, 5 year employment history, 5 year address history, name aliases, and licenses. Each section had strict criteria for what was accepted. As an example: employment history had to date back to a minimum of 5 years and all gaps over 30 days had to be accounted for, for every entry on the timeline 2 pieces of supporting evidence needed to be provided such as bank statements or pay slips, if the user travelled they had to upload proof such as travel stamps and overseas payments. From this I could start to detail the product requirements and share with the rest of the business.

‍

‍

image

Flow diagram for just one section of the background checking process we had to build

‍

‍

After we had captured this information from the officers in the worker app it would then come through to the DeepDive portal used by our compliance team to cross check and examine everything that was submitted and allow them to ask for resubmissions and message the officers.

‍

Design

‍For each section I created various low fidelity sketches to test out ideas quickly and try to think outside the box. After sketching some initial concepts we created some user flows to figure out how each section would fit together.

‍

image

A simplified user flow for on-boarding new users and getting them fully background checked

‍

From the user personas I had created during building theΒ Worker AppΒ I knew the best way of getting our users to successfully complete the process was to make it guided, simple, and visual.

‍

image

We focused on making the UI as guided and visual as possible

‍

I then built out prototypes to test the end to end flow myself and with the wider business. The most recent prototype was also shown during our weekly product showcase for feedback. I would have liked to have done more testing of the prototype on users but it proved to be a difficult to create a suitable test prototype for as the behaviour we wanted to evaluate was whether the user could fill out each form correctly. Data entry was required to get real value out of the testing sessions, and for that we needed engineering resources to build out a prototype.

‍

‍

‍

‍

‍

NoteΒ Unfortunately I can't show the internal web platform for confidentiality reasons. I'd be happy to talk it through in person though.

‍

‍

‍

Outcomes

As this is still an ongoing project there are no outcomes yet. We have been building out sections to bridge the gap between moving from a third party provider to bringing it all in house and have seen success in what we have built so far. The main outcome we will be measuring is the % of workers who become fully vetted on the platform.

‍