Case Study— RT Match

RT Match was designed to support the Teach For America Recruitment Team (RT for short) . When meeting with prospects, recruiters often put students in touch with Teach For America alumni who can share their story about their time and impact with TFA. RT Match is mobile-first, designed to be used in the field by recruiters to quickly facilitate real world connections.

The RT Match home screen, where a user can choose what categories they would like to search within.

The product, showing a list of people who match some or all of the criteria a user searched for.

My Role

My team conducted research with recruiters to understand the existing process for making these connections. We used that research to sketch and design a tool that was not only mobile-first, but also that could leverage the CRM (which was Salesforce.com) that they relied on for tracking prospect meetings. We went through several rounds of usability testing with recruiters while refining the application through close partnership with our software development team.

I did: Research, wireframing, interaction design and Lean UX.

My team and I working through some early concepts for how we could solve the challenge of matching alumni with prospects.

As part of these early whiteboarding sessions, we sketched out the process flows for how recruiters made these decisions.

Early wireframe we used to test how users would skim and select matches that weren’t perfect, i.e.. only met two of the three searched for criteria

 

Let me tell you a story…

TFA’s recruiters look at a wide swath of data for facilitating these connections. There was no concise data set that could be applied to achieve this goal. This in turn created some really complex database queries; our engineers brought this to our attention early on: there was no way we could meet the  speed required for this to be used in the field and search all of these categories. At once.

Using card sorting and information architecture techniques, we were able to discover that recruiters think about these searches in about “five” general buckets. Through testing, the category-based search approach proved intuitive to recruiters, while dramatically reducing the time it took for the system to produce results. Users were more satisfied with the tool because it performed faster. Our engineers were happier because it increased system reliability (and in turn, we also think our users really appreciated that as well).

The four over-arching bucket categories are illustrated at the left. When a user chooses one of those buckets, it changes what sort of fields the text search box will surface results for.