Project type: Speculative

My roles: End-to-end product designer

Duration: March-June 2021



The context

Creating an end-to-end mobile application for social good.

The problem

Members of the LGBTQIA+ community often struggle to find mental health providers who have the necessary expertise to assist with their unique needs.

The solution

Build an app that makes it fast and easy for LGBTQIA+ users to find experienced mental health providers who understand them and their communities.


Pinpointing the problem

The LGBTQIA+ community disproportionately experiences mental health issues, but the community isn’t a monolith

Many sub-communities make up the beautifully diverse LGBTQIA+ tapestry, and each has their own unique mental health needs when searching for or considering a new provider.

I began my research by interviewing a diverse group of four people from across the spectrum of the LGBTQIA+ community about their experiences — positive and negative — while searching for knowledgeable and competent mental health providers. 

Prior to those interviews, I assumed the primary pain point for users while searching for a competent and experienced provider would be finding one at all but…

The actual problem I needed to solve was how to filter providers who weren’t a good fit for users' specific needs.


Identifying pain points

After speaking to users and performing a competitive analysis, I identified four main problems users might encounter:


Digging through provider listings and databases to find a relevant provider can often be time consuming and ultimately return no results

Outdated provider sites

Many provider databases and individual provider's websites are outdated or inaccurate, giving users false or misleading information


Many mental health services that cater to the LGBTQIA+ community specifically can be prohibitively expensive

Provider dishonesty

Some providers falsely claim to work with LGBTQIA+ clients or have experience with their unique issues, but quickly reveal in a session how little they know

Meet the users



Based on my research and the insights it provided, I created two personas. Jen, the first, represents a trans woman who's concerned about major family changes as a result of coming out. She's also worried about finding a therapist who understands her unique situation and who can help her.



Kade, a non-binary illustrator, on the other hand, is more concerned with cost. Because they don't have health insurance, they have to pay a provider out-of-pocket, which can get expensive quickly. Kade also doesn't have a lot of time to waste browsing for providers, so they'd like a way to cut through the noise.

Low-fidelity wireframes

Once I felt like I had a grip on who I was designing for and why, I started paper wireframes for the homepage. Those wireframe iterations eventually led me to a combination of three main categories for users to browse providers from the homepage: Featured Providers, Provider Specialty, and a Matching Questionnaire.

Because a majority of users I spoke to reported feeling like they wasted a lot of time while shopping for a provider, I wanted to make both the browsing and appointment request processes as quick and easy as possible.


First usability test insights

Though 100% of users successfully completed the main user flow, and they generally reported feeling that the app design was fast and easy to use, my first unmoderated usability studies conducted remotely via with five participants from across the LGBTQIA+ spectrum revealed a few key insights.

Users disliked the scheduling calendar

Though the calendar wasn’t yet built in the prototype, users reported they wished there were a way to see multiple appointment days and times simultaneously to avoid unnecessary taps.

Users preferred to browse by provider specialty

4 out of 5 users browsed providers by specialty. 2 of 5 used the Matching Questionnaire, 1 used the Featured Providers section, and 0 of 5 used the Provider Search.

Users want a way to compare providers

Users wanted a way to favorite or save providers for later so that they could compare them, their rates, and availability without having to navigate back and forth between profiles.

High-fidelity mockups

Using the insights from my usability study, I refined the design in high-fidelity mockups and created ways to address the problems users had with the low-fidelity prototype.

This included re-organizing the homepage, creating a scheduling calendar that allowed users to see more information at once, and giving users a way to save and compare providers later.

With a high-fidelity prototype in hand, I decided to use it to perform a second usability test to see if my solutions met users' needs and expectations.

Second usability test insights

Though users found the app’s design clean and thought it was easy to navigate the main user flow, my second unmoderated usability studies conducted remotely via with nine participants from across the LGBTQIA+ spectrum revealed two more critical insights into my design.

Users had trouble finding scheduled appointments

Multiple users expressed confusion when trying to navigate to their calendar to cancel an appointment.

Some designs had accessibility problems

Users reported problems reading the text on the calendar while trying to schedule an appointment, as well as the icons in the main navigation bar.

Usability test improvements

Reworked homepage layout

To make it easier for users to find providers based on their area(s) of expertise, and to make it more visually appealing, I made the interest tags larger and put them into a horizontal scroll pattern.

Accessibility considerations

To address accessibility concerns, I rethought the colors I’d used and checked to make sure that they all passed WCAG AAA contrast levels. I focused most on the calendar function, as it was unreadable for some users. 

I also added descriptive text beneath the navigation bar icons, in addition to darkening all icons and changing the calendar icon itself, to make it clearer to users what it was and easier to locate their scheduled appointments.


High-fidelity prototype

If you'd like to take Queerly for a test drive, I have a high-fidelity prototype of the main booking flow available.


What I've learned

Because this was my first-ever product design project, I learned a ton and I learned it fast! These are my biggest takeaways:

Don't assume, and listen to users

As a member of the LGBTQIA+ community who's sought mental health care in the past, I assumed the biggest problem for users would be finding a relevant provider at all, but their actual problem turned out to be much more nuanced. That threw my initial idea for the project for a loop (it was originally a matchmaking concept), but it ultimately made the product better.

Accessibility is key

In my previous work as a graphic designer, accessibility wasn't something that came up often, so I’m ashamed to admit I didn’t pay much attention to it in my original designs for this project. My work on Queerly has proven how impactful the smallest improvements to accessibility can be for everyone using a product, and it’s something I’m going to strive to be better at going forward.

Next steps

Further testing

I still have many questions about Queerly and its potential users. For instance, further testing should be done to determine if a Matching Questionnaire is as necessary as users initially indicated, and if so, what kinds of questions users would find most helpful or useful for getting matched to a provider. I also would like to explore the issue of cost in some way to help lower barriers to users when it comes to accessing mental health care.

Design & test provider version

Providers would need a provider-only version of the app to manage their profiles, correspond with clients, and manage their appointments. I would need to take their unique pain points into consideration to come up with a design and test it to see if it meets their needs.

Provider interviews

This app can’t work without an audience of competent and relevant mental health providers using the service too. I’d like to know what it would take to convince them to join an app like this, and if there are any unique problems or issues they might have like privacy or HIPPA-related concerns that I could design ways to address.