UX/UI Design Task for Contractor App

The Story
I wanted a new design challenge to work on, but most of the suggestions I found online were to create an entirely new app — which seemed a bit outside of my pay grade — so I went to a popular freelancing site and found this job post:

Now, ideally I would’ve had a kick-off meeting with the client to learn more about their users — and which metric(s) they wanted me to prioritize — but that wasn’t an option here, so first I had to frame the task:
The Problem
Users need to be able to switch between different categories of contractors without leaving the contractor profiles screen. The user must be able to see the contractor profiles as they make their selection.
Assumptions
There will be a single layer of category selection. For example, yardwork will encapsulate tree removals, lawn mowing, gardening, etc...
The Visual Design hasn’t been done yet (judging from the job post) and isn’t required for this task. All styling elements are placeholders.
The app is still in the early stages of development, so the client is still willing to hear any ideas for improvements — but only if they’re directly related to the task.
User preference will be the deciding metric — in lieu of client direction.
Understand the Users
I wanted to start by asking the users what they thought would happen when they selected the categories button, because that would give me insights into what they actually wanted to happen. So, I recruited ten adults, (since kids don’t usually have to worry about washing machine repairs) and I asked them one question:

Insight: Several users were confused by the filter icon, because they expected more than one option to filter by. I made a note to try other icons later in the refinement process.
Ideate the Solutions
Now that I was confident that the users expected some kind of overlay menu, I sketched the placement options that would allow them to see the contractor profiles as they made their selection.

Prototype for Testing
Next would be preference testing, so I built a hub prototype to simplify the process, combining four prototypes into one. That way, the users could easily switch between prototypes, reducing their mental load, while also making the test more enjoyable.

Preference Test
The test was fairly simple: I recruited ten users and sent them a link to the Figma prototype (similar to what's shown above). Then I asked them to choose the one they preferred — and to explain their decision. Here's what they had to say:

Insight: Several participants said they would prefer it if the horizontal list (Number 2 in the chart above) didn’t close when they made a new selection. They thought it would be easier if they didn’t have to open the selection menu each time. Made sense to me, so I would test it.
Iterate to Improve
As I moved to mid-fidelity, I also made some changes to the top navigation bar that I’d been thinking about since I first saw the client’s sketch:

Relocating the categories button was a good start, but it still looked like a global navigation button. Functionally, it wasn’t, but the user had no way of knowing that — and they also had no way of knowing which category was selected without the overlay being active. To solve this, I changed the label to show the current page, so it doubles as a category selector and signpost for the current page.

Prototype and A/B Test
First, I wanted to check the insight that I gathered earlier: that the users preferred the category selection to remain fixed once they’ve opened it — even after they’ve changed categories. Here’s what they had to say:

Insight: A small number of users thought that the button to open the category selection should say “Categories” instead of the current selection. I didn’t think it was a big issue, since an onboarding tooltip would solve this fairly easily, but I did wonder is the users might prefer to have the current selection located in a header, placed with the main content on the screen.
Deliver the Prototype
And with that, the basic design portion of the task was finished, so I finalized the prototype for my imaginary client (as an animation, because Figma embeds are an absolute nightmare to load on phones), and here it is.

Lessons Learned
I’ll start with something positive: based on the feedback that I received, people enjoyed watching an animation of a specific interaction rather than interacting with a prototype. This could be useful because, although the technology is still improving, prototypes are often limited in what they can do, and time-consuming to get up and running. By using animations for my A/B tests, I was able to show exactly what I had in mind, and the users were able to focus on the task instead of the prototyping tool.
Now, for the negative: Figma really needs to allow guests to leave comments without having to create an account. Invision and Adobe XD already have guest capabilities built in, but figma doesn’t, and it would make it such a great platform for running A/B and Preference Tests. It's already hard enough finding people to give their time, so let's not make them sign up just to say: "I like it!" and then never use it again.
Well, that's it, so...
Need a Designer?
If you would like to check out a more recent design, there's the website design for Jessica Rose Counselling Therapy — or the project I did for Integrity Power Search, a search firm for tech companies and startups in North America.