problem
Everyone has something going on. Whether it be a job and a family, an ongoing job hunt, a far away aspiration, an unexpected tragedy on top of a bad news cascade. Maintaining good mental health is not always easy. It’s not always easy to be okay. On top of that, reaching out for any sort of assistance can often be associated with a lot of stigma and unwillingness to try and understand what someone might be going through.
overview
*This was a personal design challenge that I tackled on my own with the guidance of a UX designer who was also my mentor. Due to time constraints, not all features of the application are fully fleshed out but more time was allocated for the ideas and processes - the backbone of the application itself.
before jumping headfirst into a solution,
Let’s take a second to step into someone else’s shoes. when it comes to mental health, empathy is incredibly important.
“This disease comes with a package. Shame. When any other part of your body gets sick, you get sympathy.”
"Not all wounds are so visible. Walk gently in the lives of others."
“Please don't judge people. You don't know what it took someone to get out of bed, look and feel presentable as possible and face the day. You never truly know the daily struggles of others.”
"Just because you don't understand it doesn't mean it isn't so."
How might we overcome this mental health barrier and create a welcoming space for people to come together and share their experiences?
solution
With Bloom, you can document your mental health journey with others who may be going through something similar. A digital application designed to foster a welcoming space for what can often be a sensitive topic, Bloom creates a nonjudgmental platform that is rooting for the betterment of everyone in a non-invasive and go-at-your-own-pace sort of way.
Outline
Research
Competitive Analysis (Secondary Research)
User Interviews
Follow-Up Research (as needed)
1
design / iterate
Sitemap
User & Task Flows
Low-Fidelity Wireframes
Responsive & Interactive Design
High-Fidelity Wireframes
2
evaluate
Usability Testing
Iterations
Closing Thoughts
3
research
Before even thinking about the creation of the application itself, a solid foundation needs to be built first. It is crucial that the idea does not fall apart in its later developmental stages. This includes being mindful of both limited time and resources.
First things first, I decided to formulate relevant research objectives to help align the research to the research goal. Starting here gives the project a clear direction.
We need to learn what kind of resources people who struggle with mental health would find beneficial to help them forward in the day-to-day.
We need to learn possible pain points that users already experience with previous mental health betterment and wellness applications, services and products.
We need to research similar services that are on the market and see what they did well and what they can improve on → this will aid in the development of our own provided service.
We need to understand what users prioritize in a web experience targeting their mental health and what is of lesser importance. We also need to understand that this is an incredibly sensitive topic and that what may work well for someone doesn’t necessarily work well for someone else.
objectives
After I compiled a list of relevant research objectives, I began to reshape those objectives into questions that I could ask to guide my research.
What are users looking for in a mental health application?
What already exists on the market on this topic and how did the companies go about tackling it?
What would make the UI easy and appealing for users?
What problems do users currently have when navigating similar user experiences?
questions
competitive analysis
To kickstart the secondary research phase, it’s important to know what exactly we’re looking for. Why care about mental health applications built by other companies when I’m trying to create one that doesn’t already exist? Well, it’s just that. Gathering insight. By analyzing competition, I can see what’s been done well and what can be done better. I can use that to build a user experience that will mitigate any potential issues and prioritize what matters.
Many of the paid services in mental health betterment offer low income options - however, this comes at the cost of underpaid therapists and subsequent poorer service to patients. Not a good trade off.
Services are often location-based and have age restrictions, leaving out a lot of people that may need help. Reviews on provided services tend to be very mixed.
Not every application has preference settings to better pair the patient with a therapist that would work well with them. Switching out therapists can be an inconvenience, especially if a change is needed more than once. Sessions can be short and can feel impersonal due to the limited time spent together.
Refunds are limited and often not available part way through the service, even if a patient is dissatisfied. This can lead to an overall negative experience and an unwillingness to try anything new in fear that it will bear the same outcome.
What I discovered:
interviews & infinity mapping
To understand what potential users of Bloom might like to see in a mental health betterment app, I conducted five participant interviews to gather some of their thoughts and insights. My discoveries were as follows:
Most participants had a busy day-to-day schedule, 2 of the participants mentioned that they’re generally very tired and drained which correlates negatively with mental health.
What participants said help them when they’re mentally struggling: food, going out with friends, music and movies/television, playing video games, talking with friends, driving, talking with people who are not in the loop (important to note that some of these are situational- for example on talking with others: some participants commented that in some cases they’d prefer to keep it to themselves and that they don’t always want to talk about certain problems they are having)
After conducting these user interviews, it became apparent that every user’s needs were quite different - mental health betterment is not a one-size-fits-all shoe. I reminded myself of how important it was to not overlook this fact as I moved forward into the next stage.
personas
In order to better visualize potential users of the application, I came up with the following personas to not only aid in the visualization of what ground the application needs to cover, but also to foster empathy for the diversity of individuals the application is striving to serve:
design
With all the research findings fresh in mind, I proceeded to draft out ideas for the application itself. I first thought up a very general outline of the application while also creating a feature hierarchy. UI elements of the design could be decided after the foundation is laid down, like icing on a cake - so at this point in the process it wasn’t necessary to think about them yet.
The features I knew I wanted to implement are as follows:
Log in / Sign up (point of entry)
Profile (on task bar)
Events (on task bar)
Calendar (on task bar)
Feed / User posts (home page -> on task bar)
Favorites (on task bar)
To explain a bit of my thought process here, I began to envision what the app would look like and how it would function (a lot of the features would exist in relativity to one another so I also had to take this into account (ex. the calendar page exists because the schedule an event page exists)).
I knew that a user would have to sign up for an account if they were a first time user in order to start posting anything or start using any of the personalized features. That is the key word here. Personalized. The point of the application is to feel personable, to make the user feel like their individual needs are heard and that they aren’t just someone swallowed in the crowd of other users (that’s why a ‘continue as guest’ option was not ideal in this case).
If a user can sign up for an account, then they would subsequently have created a user profile. The user profile would include things like his/her name, a descriptor, a description, interests, etc. User profile icons would be displayed all throughout the application and clickable so that people have the option to reach out and potentially make a connection if they so choose.
The next two features I wanted to include go hand-in-hand, and they are an events page and a calendar page. I wanted users to be able to look for local meet-up events where people could gather with like-minded individuals and engage in a mental betterment session. If a user wants to attend a certain event (ex. an outdoor meditation event), then they can schedule that event in their calendar. All of the details would be easily accessible to them if they need to check back on them at any time. The option to remove the event or browse events taking place on particular days is also an option through the calendar icon. The reason I wanted to implement this feature is because of the following that was mentioned by the majority of interviewees during the user research phase: that being outside and speaking with friends or people not in the loop were things that helped them when they were mentally unwell.
user flows / task flows
In order to visually explain how some of the features would work, I created the following user flows. One of them shows the relatively simple logging in and signing up user flow while the other one shows how scheduling and un-scheduling an event would work. The things that I had to be wary of here were dead ends in the flow and mitigating user pain points. I also wanted to ascertain that the user felt empowered and like they had control over their decisions, and that the application gave them the freedom to choose the options they wanted to choose. I didn’t want anything to feel forced because it goes against the environment that I wanted the application to cultivate (welcoming, warm, etc.)
ui / visual elements
In order to start drafting the visual elements of the Bloom application, I started off with thinking of some words that I felt would closely identify with the feel of the brand itself. Using these words as a jumping off point, I could refer to them when creating things like the color palette and shape design of buttons and other elements to make sure I was staying true to the brand and the image I wanted it to convey.
What words should come to mind when a user is interacting with the Bloom application interface?
With these words in mind, I first created a mood board for myself to give me a bit of a clearer direction. I then began drafting out color palettes, selecting suitable typefaces, designing a brand logo, and developing an icon library. I deviated from the first ideas I had for a color palette pictured below because as I was going through the design process I found combinations I felt fit better and were more cohesive overall. It’s important to trust the process and not be hung up over initial ideas because all of the elements are susceptible to change. In addition to this, there are often even greater alternatives to a good idea if you let yourself be open-minded to them.
low-fidelity wireframes
I started off with low-fidelity sketches. These are both low risk and time efficient, with very few creative constraints. I just let myself sketch out a handful of ideas that felt relevant to the potential design of the application.
high-fidelity wireframes
ONBOARDING
SCHEDULING FLOW
DE-SCHEDULING FLOW
user feedback
After creating my high-fidelity prototypes, I gathered some volunteer users to complete a few tasks and offer any feedback or suggestions they may have in improving the design. The tasks were as follows: sign up for a Bloom account, schedule an event to your calendar, and remove that same event from your calendar. Here is the feedback I gathered:
One user felt that it would be useful to have labels on user inputs to eliminate any potential confusion.
Another commented that the confirmation page where a user could input either a phone number or email address should be interactive so that the user isn’t being deceived into thinking they have the option and actually do.
Another issue pointed out an inconsistency with the scheduling - after removing the event from his calendar, the user noticed that the event was still in the calendar creating a problematically infinite loop.
Note: Other comments were mainly on the application’s overall development (more navigable screens, more features in general) - these comments were still helpful, and placed on a backburner for future designs that would be intended for a higher stage of fruition. Changes to the app’s design after two rounds of user feedback have already been implemented in the screens displayed above.
take-aways & conclusion
I started this project with way too many over the top ideas given the time constraints. However, I quickly realized that in order to create both a functional and useful application that I had to focus more on practicality opposed to needless visual clutter and features that weren’t really adding anything to the design. A pretty design means nothing if it isn’t usable and it isn’t useful.
Though having the best sides of both are ideal, the priorities of a UX designer and an illustrator are not the same and that’s something I was served stone cold while working on not only this project but a handful of others as well. I’m grateful to have come to this realization so I could think even more like a designer moving forward.
