Creating a Research Recruitment Program from Scratch

On Day 3 at my new job, at about the same time I got my laptop, I met the Head of Digital Product. They had just joined as well and were in Week Zero of a discovery sprint. We started to chat and they asked me, how do we find people to speak to about homeowner’s associations?

‍

At the time, there were a couple of options: Hire a recruiting agency; meet with internal referrals; or with people the Relationship Managers suggest. Alternatively, we could, scour the internet to find people that match the perspectives needed through laborious manual search practices.

‍

The first option, hiring a recruiting agency, was a decent idea if we had a budget and a timeline that would allow for it. The second option, internal referrals, had its upsides but the downside was it introduced bias and placed a burden on the referrer to help with introductions, scheduling and a lot of back and forth they didn’t sign up for. The third option was the best option given the timeframe and available resources.

‍

The Need

‍

It became obvious we would be spending a lot of time planning research and less time doing research unless I found a solution to recruiting.

We needed a system that allowed us to recruit and manage thousands of people in a research community so we could eliminate bias, match the right people to research projects and increase the integrity of our research, which would build the foundation for actionable insights and inform the strategic direction of the company.

This system would help research requestors, research coordinators, and research participants.

‍

The Solution

‍

Over 42 days, a small but mighty team conceptualized, designed and launched the CX Co-Lab, a community that will help create a better banking experience by providing ongoing insights and inspiration. The community is powered by the Salesforce platform.

‍

‍

‍

‍

‍

Users and Problems We Wanted to Solve

‍

We had three users with different needs.

‍

The first user was the research participant. We wanted to give people a way to participate in building the future of the bank and provide a research experience for these future participants that was professional and mirrors the integrity of the bank.

‍

The second user was the internal user requesting research. We wanted to create a consistent, transparent way for internal business and technology teams to request user research and provide a feedback loop to these requestors.

‍

Lastly, we wanted to help our research coordinators keep participant data protected and private, match participants to projects and track research participation.

‍

Where to Build the Data Store

‍

There were a couple of options for where we could create our participant database. However, the company was moving to Salesforce for Customer Relationship Management so this was a natural place to start our research.

‍

Many jobs ago I researched Salesforce’s Lightning Design System before building my own design system. I knew the team was a trailblazer when it came to thinking in systems and sharing these systems with others. Lightning was one of the first open-source design systems, though Pantsuit wins for the most memorable name.

‍

I had a hunch (and hoped it was correct) that the Salesforce Research Team would be open to sharing their experience building their research operations system in Salesforce. After a couple of conversations with current and former Salesforce employees (thank you Anna, Rebecca and Alex!), I was finally connected to Noel Lamb, Manager of UX Research Operations at Salesforce.

‍

Noel architected the system Salesforce uses today, with a little help from her partner Matt. But that’s a story for another day.

‍

Noel graciously walked me through how the Salesforce Site and Salesforce app was setup and offered to connect me to others on her team as well. After these conversations, we were convinced Salesforce was right for the job.

‍

Perfect Time to Sprint

‍

The problem and the users were well defined and thanks to Noel at Salesforce, we had an early spike on a path to the solution. So, we decided to leverage the GV Design Sprint process to get a prototype shipped and in the hands of customers as quickly as possible.

‍

The GV Design Sprint has five phases: Understand, Sketch, Decide, Prototype and Validate. It’s suggested these five phases should happen over five days.

‍

We created a compressed three-day sprint schedule, starting out the “understand” phase with internal stakeholder interviews and external subject matter expert interviews.

‍

‍

Then, we mapped the research project intake, the research recruitment and scheduling, and the participant signup flow. We drilled into areas that didn’t exist today and ranked them as feasible or not, as well as, nice to haves or must haves (based on our sprint objective).

‍

We ultimately decided to focus on the participant signup as a must-have so that participants could join the CX Co-Lab. The functionality that allowed us to manage the participants was also prioritized, alongside the workflow around the project intake process.

‍

For the minimum lovable product (MLP), we decided to cut tasks around screening and scheduling research participants. We also made the signup process as lean as possible, focusing on getting a signup form launched and improving the experience after. We are hoping our new Research Coordinator will help us with this!

‍

In one day, we were able to create a working prototype of the Salesforce application that we would use to internally manage projects and participants, and the site where participants would signup. Following this sprint, we focused on improving the user experience for two weeks. We spent the most time making sure the form flow was smooth. It was the most important piece because we didn’t want to risk people dropping off during the signup process.

‍

We used form logic to create different paths for the different types of customers, in addition to, a path for non-customers. This helped eliminate non-essential questions. We also focused on using plain language instead of “banker speak” throughout the signup process. This helped reduce the chance that people would respond incorrectly to what was being asked because they didn’t understand the question.

‍

Then, we tested the site and shipped it.

‍

Is Salesforce Right For You?

‍

If your organization is using Salesforce already, it may also be a resource for you. The build process itself — internal application and Salesforce site — was pretty straightforward. You’ll need a Salesforce developer, someone that can help you think through the data structure, and a UX designer. There was also some light CSS work. Someone on your team should be comfortable working on the frontend design. But, for the most part, the templates for Salesforce sites will do the heavy lifting.

‍