Overview:
This was a personal project that I took on as COVID-19 hit as a way to utilize my UX/Product Design skills around something I’m really passionate about—accessible mental health resources. What started out as a Google Doc became a website for accessible, inclusive crowd-sourced mental health resources for coping through COVID-19. I collaborated with a developer and led the project from inception to launch.
Challenge & Opportunity:
As COVID-19 hit the world at large and the world around me, I saw the collective overwhelm, stress, and fear take over. Amid the chaos though, I was inspired when I saw people step up to help each other whether through Facebook (creating the concept of “caremongering”) or as companies and businesses offered their products/services for free/heavily discounted in a time of great need. On the flip side, I also saw more people asking for free/low-cost access to mental health resources. So I saw the need and asked, how might we connect those who are in need of accessible mental health resources (especially in marginalized populations who are hit hardest by COVID), with those who offer it?
This project initially started out as a shareable Google Doc where I compiled low-cost/free mental health resources.
It needed to fulfill these needs:
- focus on resources that are free/low-cost
- shareable so more people can access what they need
- editable so others can easily contribute
- easy-to-update/up-to-date
- organized in a way that makes it easier to consume/look for what is needed
The document was very simple, and broken down into different categories to help organize the information (e.g., Fitness, Meditation, etc). It was for everyone to contribute, consume and share. For each resource, there was a name, very short description and a link.
As its reach quickly increased across a lot of networks, it particularly found its way around in education and therapists. The number of resources also quickly grew. It ultimately became a proof-of-concept that was taking off.
However, as its popularity grew, another set of needs were identified:
- unruly to manage and organize when the doc was open to editing by anyone at anytime
- hard and annoying to share a long google link/generic shortened link
- hard to search for the document/also within it
- not particular special to look at
- couldn’t provide very much info per resource because it was just pages of a document
- resources tended to be very Toronto-centric, even though I had been contacted from people in other cities that they wanted to do something similar
This offered an opportunity to evolve this project to a new platform that would offer more flexibility: a website.
The project:
My role for the website included: product design, visual identity, information architecture, wireframing, prototyping, UI design, and usability testing. I collaborated with my friend, Susie Kim, a developer who led the technical aspects from setting up the database to coding.
I started by analyzing what worked well with the Google Doc, as well as what its shortcomings/room for improvements were and came up with some key needs:
- Lean MVP because getting it out as soon as possible was imperative
- Mobile-responsive, and accessible
- A structured and consistent set of attributes for all resources to make inputting and consuming a lot easier
- Ability to search for relevant things easier (e.g., location, audience, type, cost, format, etc.)
- Ability for people to suggestion any resources they come across
- An easy for me (Admin) to input/publish resources to the website
- A place to share our story/learn about the project
- A way to contact us
The process:
From there, I wrote user stories and translated those into various features that we prioritized in a backlog for the MVP.
Once we had a set of features for the MVP, I started wireframing the screens, which then evolved to lo-fi screens/prototypes made in Figma to give the developer a test run of the design and if it makes sense.
As she reviewed and started to set things up, I looked at setting up information architecture of the resource categories and tags that would end up in the database and the navigation/filtering in the UI.
From the more simplified Google Doc version, I already had a really good sense of how to organize the content for the website based on the resources I’d come across. This includes identifying the categories we would have which were simply built off of the different headings that we initially had plus some new ones (e.g., Informational, Creative, Exercise, etc.). New to the website was adding tags to offer more ways to categorize and therefore the ability to search for more relevant resources for the user. These were broken down into different attributes that each resource has like:
- cost
- format
- topic
- audience
These were all organized in a spreadsheet for cataloging:
I also designed the visual identity, oh and we came up with a name—takecare19! After playing around with colours, fonts and, shapes, I came up with this:
- I wanted something more modern, casual, and fun than other typical mental health resources that look more sterile and clinical
- I chose blues and accents of yellow to represent core feelings of melancholy and joy!
Results:
With the visual identity in place, I moved onto the hi-fidelity prototypes for mobile and desktop:
Between the hi-fi mockups and what was launched, minor tweaks were made based on a few usability tests, and some major revisions in our prioritization were needed, mostly related to the key that this project is more time-sensitive due to its nature:
- Didn’t end up having the location filter due to technical limitations of the database set up and it wasn’t worth the effort at that point
- Suggestions form ended up being a Google Form because it wasn’t worth the development effort to build it
- While, shortly after launch, we added in filters for the tags, we also realized technical limitations with the database that limited in how robust it worked
Learnings
Overall, it was a really rewarding project, I learned a lot, and am proud of how it turned out even with things not always being smooth. Some key learnings:
- Given the time sensitivity, in hindsight perhaps it would have been faster and easier to use an existing CMS, but it also provided us with a big learning opportunity to challenge our skills by building it from scratch
- Experienced how hard it is to prioritize features/needs. Staying more agile allowed us to quickly drop or swap features that made more sense when weighing function vs effort
- Having a proof-of-concept/early research saved time figuring things out later
- But it’s also a balance, because staying open and allowing it to be shaped organically helped me gain clarity in the need to focus on marginalized communities which I didn’t specifically have in mind at the very beginning