top of page

Fetcher Extension


About Fetcher

Fetcher is a SaaS company that assists recruiters and companies in identifying and sourcing ideal candidates. Utilizing artificial intelligence, Fetcher identifies suitable candidates and then includes a human verification step to ensure an accurate match. Once suitable candidates are identified, Fetcher then sets up a system of automated email touch-points, freeing clients to focus on relationship building and prioritizing communication with their prospective candidates.



Fetcher's extension, while functional and capable of fulfilling its intended purpose, faces a significant user problem resulting in widespread dissatisfaction. Numerous users, bo
th new and experienced, struggle with understanding the extension's flows, encountering unfamiliar terminology, and relying on trial and error to navigate its functionality effectively.

User Problem:

"As a recruiter and loyal Fetcher client, I am facing significant challenges while working with the extension. While I can handle basic tasks, I encounter frustrating dead-ends, confusion due to unfamiliar terminology, difficulty accessing essential information, and struggle to find crucial details and actions. These usability issues not only annoy me but also hinder my ability to work efficiently, impacting my performance and success rate."

Vector 221.png


Jasmine Agosti, Hillary (Sr. Product Manager), Chris (Chief Product Officer)

My Role: 

The sole UX designer on this project


Figma, Figjam, Jira, Pen and paper


Redesign, Improve User Satisfaction, and Improve Task Efficiency

Below of the current version of the extension prior to this current redesign. Footage of user's behavior with the extension. 

User Discovery

Together with Senior Product Manager, Hillary, we conducted interviews with 10 clients on the Fetcher Extension, using Google Meet to ask them open-ended questions. Our aim was to gain a comprehensive understanding of their perspective, comprehension, usage, challenges, requirements, and desires for the extension. During the interviews, we took notes, collected quotes, and observed their behavior as they demonstrated pain points and showed us how they navigated the extension. On occasion, they also shared competitor features they would like us to incorporate.


1O Clients


Moderated Google Meet


Open-ended qualitative questions 

Below are user quotes from user discovery 


Screen Shot 2023-05-13 at 12.56.36 PM.png

Affinity Diagram

I utilized an affinity diagram to identify and comprehend the themes underlying the user issues. To achieve this, I gathered all the feedback provided by the extension users and employed heuristic analysis to categorize them into themes, which enabled me to gain a better understanding of the modifications required for future improvements.

Screen Shot 2023-05-26 at 12.33.39 PM.png

User Problems

Inadequate Alignment of Fetcher's Information Output with User's Needs


Group 2301.png

Limited User Flows/ UI Design:

Group 2302.png

Limited Match between System and Real World Terminology\ Limited Help and Documentation: 

Group 2303.png
Screen Shot 2023-05-11 at 1.01.43 AM.png

Extension Goals:

We discussed with the stakeholder and product managers and established the extension goals. We did this by grouping user problem statements, pain points, needs, and Fetcher company goals together.  Here's a little chart to show how it all fits together.

Below is an image of the flow of how the problem statements, business goals, and extension goals all link together.

Increase Product Adoption:
Increase product adoption by designing an experience that is easy to use, enjoyable, and effective, leading to increased user engagement and satisfaction.

Improve User Satisfaction:
Increase user satisfaction by identifying and addressing pain points and usability issues, resulting in a better user experience.

Improve Task Efficiency:

Improve task efficiency by streamlining processes, reducing the number of steps required to complete a task, and providing clear guidance throughout the user journey.

How Might We Statements 

Upon comprehending and comprehensively understanding the user statements and goals, I sought to translate these pain points and objectives into How Might We Statements. This approach would help me stay focused on achieving desired outcomes as I designed the product.

All of the questions that were formulated were related to the issues and challenges I sought to resolve, but I considered the ones with thumbs up to be the most effective.

Screen Shot 2023-05-12 at 10.40.31 AM.png

Red Routes


After discussing with the Chief Product Officer the main functionalities of the product, we had determined what the main MVPS of the extension were. We made sure that I was going to ask the testers to accomplish these during our usability and A+B Testing:


Red Routes (numbers on the list refer are referred in the diagram below)
1. Save PDF on LinkedIn to load information on the extension
2. Add profile from extension to fetcher
3. View and edit the profile’s email address 
4. Schedule an email or email now 
5. View the profile’s
history within Fetcher 
6. Vet candidates on the extension

Screen Shot 2023-05-10 at 1.16.37 AM.png

Iteration 1 


The CPO provided me with his initial Round 1 design for the extension, and he explained the flow and the reasoning behind his decisions. However, it's worth noting that he didn't conduct any prior testing, heuristic analysis, or usability testing on this design. Instead, he relied on his interpretation and brainstorming of changes that he believed would be beneficial.

Initial Review of Iteration 1


During my initial independent review of R1, I noticed that several of the flows, icons, terminology, and documentation were effective. However, I also came up with some alternative ideas for the critical paths and discussed them with Hillary, a Senior Product Manager. Together, we arrived at a great solution that involved testing both designs:

Prototype A: CPO's original design (with some minor changes)
Prototype B: My proposed design solution

Group 504.png

Testing Strategy

To validate our designs, we aimed to conduct testing that would help us achieve the following goals:


Open-ended questions:
Our objective was to obtain qualitative information and understand the state of mind of the recruiters by asking open-ended questions.


Part 1. Usability testing with A/B Testing:
We aimed to test the red routes to evaluate if the users could complete them correctly. Additionally, we planned to perform A/B testing within the usability testing and ask the users to perform on both prototypes to gain what was most successful.


Part 2. A/B Preferences:
We wanted to gain insights into the user's preferences by understanding what they thought they preferred over how they performed on the usability test.

Overall, the testing would allow us to identify the following:

  1. What terminology did the users relate to the most (A/B test)

  2. How the red routes performed

  3. Which prototype had a higher success rate (A/B test)

  4. What was the user's preferred design (A/B test)

  5. Any additional information, feedback, needs, or pain points they had

Part 1. Usability and A/B Testing

Usability Testing: Below are questions in reference to the red routes 

  1. When you open the extension what is the first thing you'd do? 

  2. Where would you add this candidate you've uploaded on the extension to Fetcher?

  3. Where would you go to view and edit a profile's email address on the extension?

  4. Where would you schedule an email or send an email immediately through Fetcher?

  5. Where would you go to view the profile's history within Fetcher on the extension?

  6. Where would you go to vet a candidate?

A/B Testing: Below are the main key differences between the A+B Prototypes

  1. Location of instruction

  2.  Button and instruction modal 

  3. Email CTA

  4. Transfer Profile to Fetcher Directory

  5. Layout

Images below show to differences between the A and B preferences. 



Results of Usability Testing and A/B Testing


After conducting A+B testing and usability testing with 6 clients/testers, we understood their needs and preferences that worked best for them. We asked them to complete usability tests which gave us insight into their behavior, insight, and expectations. We asked them to choose between the A+B preferences to see which ones they subjectively liked. There were some disconnects between what they initially thought was better and what they understood to be more functionality. But most of the tester's chosen A and B preferences aligned with their successes passing the red routes. 

Usability Testing Results 

We assigned the testers specific tasks to complete. Only three red routes were tested in prototype B.

Group 691.png

I present to you the success rates of six users who interacted with both prototypes. These statistics indicate whether the users were able to successfully navigate between the two versions.

Group 690.png

Insight from Usability Testing

Our findings reveal that the most significant user experience issues are related to "Saving PDF", “viewing email address”, and “Email CTA”.

Save PDF:
During testing, users struggled with locating the "Save PDF" function and required multiple redirections to view their profile's first name to view the instructions, after which they understood the instructions. A possible solution could be to move the instruction to the top of the extension with a solid
color background, based on the hypothesis that users tend to read from top to bottom.

View Email Address:
During testing, users mistakenly clicked on the Email CTA button when asked to locate the profile's emails. A possible solution is to add the email information to the contact information section, along with the profile's name and job title, based on the hypothesis that it would make the information more accessible.

Email CTA:
Some users had difficulty understanding the term "Email" and were uncertain if it referred to immediate or scheduled messages. Prototype B addressed this by offering a dropdown selection with options for Email Now, Schedule Email, and Custom Email.


Part 2. Overview of A+B Preferences

Testers picked a theme between Prototype A and B by providing feedback on their preferences.

  1. Location of instruction 1

  2. Button and instruction 2

  3. Email CTA

  4. Transfer Profile to Fetcher

  5. Layout

Group 692.png

Insight from A+B Preferences

After analyzing the A+B preferences of the user, I understood that users wanted clear, bold, and simple assets based on their preferences. Below are a couple of examples:

Button and Instruction 2: 


We wanted to see if users would prefer and align more with

  1. Modal with a graphic image with instructions in 1,2,3 step format

  2.  The tooltip provided quick instructions with commas.

Initially, I assumed that the testers would prefer the (1) graphic modal over the (2) tooltip because it appeared clearer and offered a more visual representation. However, upon analyzing their decision-making process, I found that their preference was based on the fact that they only needed to learn the action once and could repeat it multiple times. They desired clear instructions that did not occupy a large portion of their screen when performing a simple task. From this, I gathered that testers prioritized efficiency and straightforward instructions, over something that required numerous clicks or occupied too much space.

Email CTA:

In Design 1, the primary call-to-action button was "Email." However, during testing, it was observed that people misunderstood this button as the location of the profile's email, rather than the intended function of sending an email. To prevent further confusion among testers, I designed Prototype B with three distinct options (Email>Email Now, Schedule Email, Custom Email). The new design was well-received by all users as it provided clear options instead of vague and misleading actions.


Final Design Iterations 
Save PDF User Flow

Rectangle 1320.png

Instruction Location: 

Option B was preferred by testers because the instructions were located at the top rather than being buried in the user's profile information.


Due to the excessive clicks required for a short task, testers favored the hover-over option over the modal with the image and instructions.

Information Icon: 

Testers were observed to immediately click on the information icon.

Drop Shadow:

A considerable number of users found it challenging to distinguish the extension from LinkedIn. To improve the contrast, adding a drop-shadow has been suggested.

Group 511.png

UX Personal Iterations:

Text Size: 

I increased the font size to range from 14x16, but several testers reported difficulty in reading the text.


To capture the user's attention, a solid background was included behind the instruction.


I modified the instruction's wording to ensure that it is extremely clear to the user.

Profile, Keywords, and History Interface 

Profile Section: 

The "Edit" tab has been taken out and an email address field has been included in the profile information. Additionally, a "more" icon has been added to allow for modifying or changing the email address.


The term "Matches" has been replaced with "Keywords" to prevent confusion among testers, who found the former term misleading.


Group 519.png
Rectangle 1320.png

CTA Buttons:

After receiving positive feedback from users who successfully completed the task from Prototype B with three email options, we have added three options to the final dropdown: (1) Email Now, (2) Schedule Email, and (3) Custom Email.

# Matches:

I introduced a feature that displays the number of keyword matches between the user's search criteria and the candidate's LinkedIn profile picture. This enhancement aims to boost user confidence in evaluating the candidate's suitability.

History Interface and more options 


To make it easier to understand, icons have been added to indicate the action taken.


The user who carried out the action is also identified. 

CTA button visibility:

I ensured that the two main call-to-action buttons are displayed on this view, rather than being limited to the keyword view only.


UX Personal Iterations:

Grouping of more options: 

The "More" options have been reorganized and divided into three categories: search, profile, and communication. This new organization aims to improve the user experience and make it easier to find specific options.

Frame 113.png
Frame 114.png

Add candidate to Fetcher Flow (image below)

We conducted A/B testing and gathered feedback from users to determine the most functional, user-friendly, and clear flow. During testing, we found that users were confused by the "+ Add Profile" button in Prototype A, mistakenly assuming that it would add another profile to the extension. Therefore, we concluded that "Add to Fetcher" was a better option because it was clear and concise. Additionally, testers repeatedly requested confirmation of the candidate's status, so we have included a confirmation button to indicate that the candidate has been successfully added to Fetcher.


Email Candidate Fetcher Flow (image below)

Initially, the email call-to-action (CTA) was labeled as "Email", but during user testing, we found that these left users confused. When we asked for clarification, users had different interpretations of what "Email" meant. The original intention was for it to schedule an email, but users didn't understand that terminology. The other two email actions were located in the "More" section, which users didn't realize was there.

To address these issues, we introduced a dropdown in Prototype B that offers three options for emailing. Additionally, we added a sense of accomplishment by including a green color and checkmark upon successful completion of the action. This improves the user experience and makes it more clear and user-friendly.


Final Design Loom Video

bottom of page