UX/UI Design Practice
The Story
I had just finished my UI Design course with CareerFoundry, and I wasn't having much luck in the job market (quite unemployed, in fact), so I looked at the freelancing platforms to find some real-life design practice, and I found this job ad:
The Problem
The users need to be able to switch between different categories of contractors, and the client wants them to be able to do it 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 started by asking the users what they thought would happen when they selected the categories button, because that would give me some insights into what they actually wanted to happen — so I recruited ten adults, since kids don't hire contractors, 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, so I made a note to try other icons later in the refinement process.
Ideate the Solutions
Now that I was confident the users expected some kind of overlay menu, I sketched a few placement options that would show them 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 (mostly other design students at CareerFoundry), and I sent them a link to a Figma prototype I built (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've preferred 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, so I made a note to try out that idea.
Iterate to Improve
As I moved to mid-fidelity, I also made some changes to the information hierarchy of the top navigation bar that I’d been thinking about ever since I first saw the client’s sketch:
Relocating the categories button was a good start, but it still looked like a global navigation item — and people had no way of knowing which category was selected without the overlay being active, so here's what I came up with:
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:
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 actually 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 up their time for testing purposes, and I actually had a couple of people back out because they just didn't want to make a new account for a software they were never going to use again, which was understandable. Guest capabilities would make this process so much easier, and hopefully Figma adds it eventually.
Thank you for reading this far, and if you'd like to see a more-recent project I've worked on, check out this Webflow website: IntegrityPowerSearch.com — cheers.