A new kind of notification reminder system

Torre.co is a job matching network startup focused primarily on remote jobs, with over 1.5M users. It has a powerful matching algorithm that uses 121 different factors to determine if a person’s genome is a good fit for a job and vice versa.

If candidates are notified through different channels whenever a recruiter texts them on Torre Messenger, and the recruiter can know when these channels were used, we can increase the speed of hiring processes.

One of Torre's ultimate aims is to shorten the time it takes a candidate to complete the recruiting process. It helps businesses achieve their goals more efficiently and makes life easier for applicants.

The lowest-hanging fruit to accelerate overall hiring speed is to improve communication. Some processes, like reviewing profiles, or completing technical tests have fixed time costs that are difficult to reduce, but any in-between moments in which one side of the conversation is awaiting an answer is lost time.

So, because Torre Messenger was not yet a tool that candidates were accustomed to checking frequently, we were getting many reports of unanswered messages from candidates who were likely interested in the process. We had to let them know if they had a pending message about their open process.

But sending reminders to candidates wouldn’t be enough. We needed to build a place for recruiters to check what efforts were going on in the background for their message to get across.

This design was divided into two parts:

Determining through which channels users would be informed about unread messages, in what order of priority, and in what time intervals they would be sent.

This process was simple. During a workshop with the squad’s tech lead, we determined a list of channels based on the following criteria:

The result was a list like this:

Designing a way to show a recruiter the exact status of their message. They should know if the message was read or what channels had been used to let the recipient know there was an unread message waiting for them.

Here’s how Torre Messenger looked before this new system was launched:

Notice in the picture above how the space right above the textbox was already being used for a notes functionality. In essence, there wasn’t a lot of space where we could develop a new system. So, I decided we would add a read/received component similar to what is common in most chats, but with a few twists.

First, our component could not be linked directly to each message because of a technical obstacle that would take too much effort to solve, so it would have to be in reference to the whole conversation.

Second, normally a component like this would only indicate if a message had been sent, received, or read. Because of the nature of the functionality, we would have to add several other icons and would need to educate users about their meaning.

Here is a screenshot of the component I came up with and some of its different states.

In the picture above, you can see four different icons, each with their active and inactive states, and a bar that separates two different groups. Whenever a message has been sent, a single check mark should appear on the left side of the bar and the remaining icons would be shown as inactive on the right side.

As reminder messages are sent, their corresponding icons would change to their “sent” state and move to the left of the bar. This would continue until the user would open the conversation and the check mark would turn into its “read” mode.

However, having this component wouldn’t be enough. We knew this new system wouldn’t be 100% intuitive at first for all users and it would require some additional information. So when you click or tap on the component you would be able to see the following dialog:

The system was designed so we could continue optimizing the timing intervals in the future if we considered they need adjustment, hence the generic copy for days and hours.

After the product was launched for internal use, I conducted a usability test with 12 different users. Most of them were recruiters and other internal stakeholders who would likely be using it in the future.

The tests confirmed several of our assumptions. As we had imagined, the main component with the icons was difficult to understand at first, but the dialog would be helpful.

As you’ll see on the chart below, most users were either detractors (ranked 0-5 out of 10) or neutral (ranked 6-8 out of 10) about understanding the functionality before seeing the dialogue. But after seeing the dialogue, most became promoters (ranked 9-10 out of 10).

However, there was one common complaint about the placement of the component that needed to be fixed before launching it to the public. Since the component was in a fixed location right below the last message being sent, some users were unsure if it referred to the delivery of that last message or if it related to the whole conversation.

In order to fix this quickly, we decided to add a simple animation for the component to disappear as the user scrolls to previous messages. This would help users understand that the component was providing information in relation to the conversation, not just one message.

The following GIF shows how the end result of this project in production.