AUTHENTIC
Imagining mental health access for the LGBTQIA community through Ruby
My first project at Flatiron was using the code language of Ruby. Our assignment was to create an application that implements a has_many :through association. This meant by applying three tables: Patient, Session, and Therapist, where the user has the ability to access therapists through the scheduling of sessions.
Patient -< Session >- Therapist
But what does this all mean?
At this point in the process, it was time to add the database fields to each table. Through researching websites offering mental health services, it was noted that the way searches could be narrowed was inhibiting to LGBTQIA patients looking for identity affirming professionals. This is where it was decided that developing an application to connect LGBTQIA patients with affirming and safe services was crucial. So we dug into how to create a basic Ruby application with LGBTQIA identities in mind.
Patient
Therapist
chosen name
age
location
email
phone number
chosen name
location
email
phone number
availability
insurance
As we implemented these fields into our database, we started to realize that there were so many more identities and parameters than we had initially thought of.
Adding additional fields such as gender identity, sexual identity, race, education, and various professional licenses, left us unable to use an API as a source of our data. We understood that these fields were important to our app development, so we jumped in and manually seeded our data.
Some of my favorite usernames were Fannypack and Gertygert. Clearly there was some fun creating this app!
When it came to professional licenses, it made sense to use a separate boolean field for each type of license. We contemplated using a text field for the license input, but decided that it could lead to search issues due to spelling errors or punctuation.
Now for the real MVP
Moving through the process of coding, we come to our MVP, or Minimum Viable Product. Looking for the basic functionality of user login, viewing therapists, booking sessions, and deleting appointment, our MVP was primarily met on the patient end. As we worked our way through solving how to search for a therapist, it became clear that we were not going to meet our initial MVP with the time constraint of one week. This is when we decided to re-evaluate our MVP and organized tasks in order of importance.
Through re-evaluation, we found that some of our stretch goals were met with ease. They felt more natural and the flow of our search parameters became more intuitive.
By focusing on the patient stories, we were capable of providing the same functionality to a therapist user. Doing this however left us with only one route of functionality. Allowing for variance in the user capabilities would've required a complete rewrite and structure of our application. An overhaul of the CLI or Command Line Interface was out of the picture in the allotted project timeline, but our MVP was still on target.
Placing the options of Patient or Therapist within the sign_in method made categorizing their table fields a bit harder to comprehend.
Below are two basic outlines of how the CLI functions. The first being how the code is currently written, the second, a possible solution for a CLI re-write. I believe that both are functional, however the order in which methods are written would be in contrast.
A continuation
Looking forward on the prospects of this project, I can't help to wonder how it could be translated into a React.JS app, using React as the frontend and Ruby on Rails as the backend. I think there would be careful consideration of how to organize such complex identities. Further research, surveys, ideation, and reflection would be integral for the Authentic app to be all encompassing. But for now, I'll share with you my continuation of the vision for this app.
I find that visually representing the routes and structure of an app help to conceptualize flow.

Creating a detailed ERB allowed me the opportunity to see the app as a system, similar to an electrical switch, where routing would change the current depending on the objective of the user. It just happens that as I was creating this ERB diagram, it started to resemble an old filament lightbulb!
wireframes
Using Figma to create basic outlines of the Authentic web application, starting out small with basic functionality was key. Adding element like nav bar, containers, div blocks, and images helped to understand hierarchy and global elements.
The importance of Identity Affirmation
As we make our way through this world, the need for representation is apparent in all walks of our lives. We require a mirror of experiences to unite and provide community. It is imperative that within the field of tech there is representation of all identities at all career levels. This project is a small glimpse at the importance of wording and language used within code. Understanding our implicit biases and mistakes allows us to grow, progress, and learn.
42% of LGBTQ youth seriously considered attempting suicide in the past year, including more than half of transgender and nonbinary youth.
With 48% of LGBTQIA youth seeking mental health care but were unable to obtain services, it becomes clear systemic changes within the U.S. healthcare system are vital. I do not believe tech apps are the answer to the national mental health care crisis, but in turn can become a helping hand through open source data, understanding cultural semantics, and the reflection of values within written code.
In conclusion
The process of creating the Authentic app through Ruby, and the ideation of the app continued through React.JS, opens doors of possibilities. Through Authentic, I hope to help create a network of identity affirming mental health professionals who will also be a mirror of the community and provide a safe environment to LGBTQIA youth.
