Mya is an AI chatbot that recruiters can use for inbound and outbound recruiting. Mya can talk directly to candidates to gather job-related information, gauge interest, answer questions, etc. While Mya may seem fairly autonomous, there is a ton of work going on behind the scenes, especially on the customer's end. To keep Mya running, customers were given access to the Mya Recruiter Portal (MRP).

Our typical user groups in the MRP were recruiters and recruiter admins/hiring managers. Users could do a variety of things, like launching Mya outbound recruiting initiatives, designing Mya's conversations, viewing candidate information collected from a Mya conversation, and much more. Essentially, the MRP was how customers communicated with Mya, the AI.

During my time at Mya, the company was rapidly growing, as was the MRP. I had the chance to contribute to many aspects of the MRP, from huge new features down to small UI updates. Though some of the updates felt small, they improved users' effectiveness with the tool. The following sections will detail UI and UX improvements related to settings configurations, search and filter capabilities, and navigation.

Initially, the search bar in the MRP functioned locally. Search criteria were only applied to the content of the page the user was currently on. If a user was in the Campaigns list view, their search results were tied to Campaigns. We introduced global search and search filters to help our users get around the MRP with more ease.

• With the new search, when a user clicks into the search bar, a search filter is automatically applied for the current page
• Beneath the search bar is a dropdown containing the object types a user could search for: candidates, applications, interviews, etc.
• Users could add multiple object types to search for

• If a user wanted to search globally, they could either remove the search filter or click "Globally" in the dropdown. Global searches resulted in a list view separating each result by object type.

The filters button surfaces a dropdown with filters that only apply to the page it is on. Each page had a different set of filters, so each filter menu looked slightly different. Some pages didn't even have filters.

As the AI became more robust and Mya conversations improved, we were able to capture and store more candidate information. That information went far beyond the basics of Candidate name, phone number, email, etc. We had information such as a candidate's preferred work location, work availability, experience, desired job factors. Now the challenge was to make that information even more valuable to users.

We decided to introduce advanced filtering for candidates. Users could now generate lists of candidates that meet fairly specific criteria.

• The initial filters menu had some quick filters that we knew users most frequently used

• Pressing advanced search surfaced a modal with several candidate information filters. We anticipated the type of filters to continue growing as we continued building out the AI.

• After applying the filters, they appear near the top of the list view above the filter results. The candidates that meet all the filter criteria are displayed first, followed by candidates who only partially matched. The filters did not contain weighted importance, so the order for partially matched candidates was based on the order that the user configured the filters.

Now that users could search by very specific candidate information, we needed a better way for them to view that stored information. Since they would be looking at dozens of candidates at a time, we wanted a way for users to quickly access each candidate's information without overcrowding the page, navigating the user away from the page, or surfacing modals that disable scrolling and requires the user to click to exit.

We decided to display the information in a candidate preview panel that pushed out from the right side of the screen.

• If a user clicked on a candidate row, the panel would push out. Some columns would be hidden from the list view and displayed in the preview panel to create enough space
• Clicking into a candidate application kept the user on the Candidates page (rather than navigating to the Applications page) and surfaced a preview of the candidate's application, which may contain more or new application-specific information related to the candidate.

The MRP previously did not have any settings configurations beyond managing a users' profile. Everything was configured on the Mya team's side. To reduce the number of interactions between customers and Mya engineers, we decided to build a separate Admin Settings section in the MRP. I developed a general look, architecture, and system of navigating, including a specific design for recruiter calendar management and email settings.

‍

I updated the MRP left-hand nav several times. My final version had some new features to it:

• User account settings could be accessed from the dropdown menu next to the customer logo.
• A condensed view of the nav. Clicking the recruit or manage icons would expand the menu again. The Analytics and Admin icons would navigate to those pages directly.

• A "Create New" button was added to give users quick access to creating new Mya Jobs, Campaigns, etc. Previously, if a user wanted to create a Job, they would go to the Jobs page, and find a Create Job button at the top right of the screen.
• Clicking into the Admin settings section would surface an entirely new navigation. Due to the potentially vast number of items, I introduced collapsable sections and removed the footer. If the menu expanded beyond the height of the page, the nav would become scrollable. The return to home button would take users to their starting dashboard.

‍