ashlyn b. aske
Project SafeChat
An on-demand mental health support application
Project Information
Role
UX Designer
Collaborators
Katie Hancock (UX Designer)
​
Christian Ramos (UX Designer)
​
Shivam Hingorani (UX Designer)
Project Type
Term Project
(HCDE318 Introduction to User-Centered Design)
Skills
About the Project
Project SafeChat is an initiative to provide University of Washington students with access to on-demand mental health resources. Through a mobile app interface, trained student volunteers provide support to other students both on-demand and scheduled for the future. The app also has features to help users practice daily mental health wellness and mindfulness.
This project was created in an upper-level undergraduate class, HCDE 318: Introduction to User-Centered Design, during the Spring 2021 academic quarter. The project was completed primarily remotely, as the University of Washington operated with restrictions during the COVID-19 pandemic.
My team wanted to create this app to help support our peers through these challenging times. Students are struggling with their mental health more than ever, and current support options are expensive, hard to access, and generally not available on-demand. Our design aims to provide options that minimize these pain points.
Research Findings
​We conducted user interviews with four University of Washington students to gather information. Our users reported that two main issues with existing mental health resources are that they cost too much and there is no on-demand support available for people who simply seek casual help. To alleviate these issues, we made our app completely free and students can customize the app to fit their personal needs by seeking out on-demand support, scheduled appointments, or additional resources.
We originally planned to create a chatbot powered by artificial intelligence, but in our interviews our users expressed discomfort with the idea of discussing mental health with a computer. We realized that we couldn't develop a solution like this, but were not sure what to do instead at this point in the process.
User Personas
Our personas are fictional concepts of a potential user of our product. We created them to better understand our user and narrow our focus.
Before Personas
Our personas used the data from the previous artifact, our user experience research.
After Personas
After we had developed this understanding of our user, we created a user journey map to better understand their experiences.
User Journey Map
We formed a user journey map through the foundation gained from formulating personas for our user group. In doing so, we were able to map a specific persona and gain further understanding when it came to routine activity and the emotional responses within the current scenario corresponding to our topic of mental health. For our own project, we decided to map our persona that encompassed UW undergraduates with little to no mental health support experience in the past. With the help of the user journey map and scenario, we were made aware of any noticeable positive or negative takeaways, and used them when beginning to construct our design requirements.
Design Requirements
We created a list of design requirements that highlight the characteristics we wanted our project to encapsulate. This allowed us to establish a foundation for our project vision and to set realistic expectations for our final product. We ultimately decided that our design should:
-
assist users in matching with the correct mental health resource, enabling switching between resources if necessary for the best mental health outcomes.
-
allow users to share personal information, experiences, or issues, in a private, secure, and confidential venue.
-
be available to users 24/7 to provide on-demand support.
-
be portable so users can access it anywhere, in any context.
-
enable human connections rather than using AI to provide the support.
Information Architecture
When beginning the brainstorming process for designing our application, we took advantage of an information architecture due to its ability to concisely diagram the pages and modules needed to be included when considering prototyping and wireframing . We did so by creating a color coded hierarchy as follows:
-
Entry login and home screen (blue)
-
Key pathways (green)
-
Sub-pathways (yellow)
-
Interaction tools (red)
Low Fidelity Figma Prototype
Our lo-fi prototype is a very basic version of our app. We created this as the initial step towards creating a functional app.
​What we learned: Even creating a simple prototype takes a lot of foresight, planning, and attention to detail.
Before Lo-Fi prototype: We created the prototype based on the design decisions we made when creating our information architecture and wireframes.
​
After Lo-Fi prototype: We used the prototype to test and evaluate the user experience with our app.
Quick Evaluation Findings
Before moving ahead with our Lo-Fi Prototype, we felt it prudent to perform some usability tests with potential users. This study was intended to help us understand the strengths and weaknesses of our creation, and our findings would help us focus our attention as we worked to build a more realistic final product. We conducted four usability tests, and we asked each participant to complete three key tasks within the app, while we tracked key metric that would help us measure the effectiveness of our UX. Afterward, we offered each participant an opportunity to provide general feedback about the app and any specific features that stood out to them.
We collected results in three key areas: aesthetics; usability and efficiency; and redundancy, discoverability, and feedback. Based on the feedback we received from our participants, we were able to iterate on both small and large design elements throughout the system, and we designed a far more refined interface. The resulting design was one that required fewer taps, offered more intuitive user flows for each feature, and communicated more clearly with the user. This design would go on to serve as the basis of our Hi-Fi Prototype.
Annotated Wireframes
We used the frames that we built in our Low-Fidelity Prototype to create annotated wireframes of our full system through Figma. The goal was to provide concrete explanations of our design decisions and to demonstrate how everything on each screen should function. The pathways between pages highlight the process of how users would likely interact with our product.
High-Fidelity Mock Up
After ten weeks of designing, performing research, and iterating, we were pleased to arrive at our final product: the Hi-Fi Interactive Prototype. Built using Figma, this mock-up served as a nearly live demonstration of the app we had designed, and it was the culmination of everything we had learned throughout our design process. We started with the Lo-Fi Prototype we had built earlier, and we iterated on it with the findings we collected from our usability tests. We also focused our efforts heavily on the aesthetics of the app to make it feel more professional and life-like, and we considered details like the color palette and font family used across the interface. While this final product still lacked the logic and intelligence of a real smartphone application, it was a highly accurate representation of the app we planned to build, and it could be offered to a team of software developers to be converted into a fully-functioning app to be offered publicly.
Reflection
On Usability and Testing
Later in the design process, we had challenges during the prototyping phase – it was hard to create a look alike prototype without actually coding anything. There were many details to consider, and we couldn’t always anticipate exactly what we needed to do until we were physically creating the prototype. One such mistake was underestimating how much work creating the color scheme and finalizing the app’s aesthetics would be. In the future, we would front load more of the work to the Lo-Fi Prototype so that we could get user feedback on choices like our color scheme and how the aesthetics contributed to the usability of the app.
​
We eventually realized that it’s difficult to ensure usability with the little amount of testing we did, but by then we were already far along in our project. Perhaps in the future we probably would conduct more interviews and do more user testing with both the lo-fi and hi-fi prototypes. Although conducting one usability test per group member was adequate for the scope of this project, having a few more tests would have enabled us to tweak our final product and make adjustments as needed to ensure usability.
Rookie Thoughts
Many of the challenges we faced tied back to the fact that this was our first time doing an end-to-end UCD project; so we often encountered scenarios where we wished we had done more practice, or didn’t have the foresight to predict certain outcomes.
Early on in the project, some of us struggled with interviewing – in retrospect, we would have practiced more. It was also challenging to generalize our interviewees thoughts into personas, which is another issue that can be mitigated through more experience and practice.
​
After we learned that our users wouldn’t feel comfortable discussing personal topics with an instance of AI (our original design idea), it was hard to determine how to pivot to a different solution. Despite this challenge, however, we feel that how we handled this was a success - in the future, we hope to listen to our users’ concerns the same way we were able to in this project.
Despite our mistakes, we learned a lot through this experience, and we encountered a number of surprises, like learning how objective the UCD process actually is.
Accessibility & Inclusivity
We mentioned throughout the quarter in class how inclusivity is a large factor to constantly consider when it comes to design and function. Although it seemed as if we had largely different personas when comparing side-by-side, we cannot neglect the fact that our entire user group (UW undergraduates) can not be entirely represented through the four individuals who were interviewed during our user research step. Because of this, if given more time as detailed earlier, we would have been able to take advantage of the much needed perspectives to shape our design according to the community of students we aimed to reach.
Along with this, an important aspect of inclusivity that can be gained through thorough user research is accessibility. By slowing down the user research phase, we'd be well-equipped to establish an understanding about how mitigate any nuances within our design. Rather than settling for a universal design, paying mind to as many users within our community would serve as a strong foundation when attempting to provide individuals with great experiences and interactions.
On Teamwork
Each of us was fortunate to work as part of a team in which everyone shared a passion and sense of ownership over the final product. As such, each of us took responsibility for ensuring a high standard of quality across the work we produced. While delegating work equally was sometimes a challenge (due to personal reasons or assignment logistics), each team member experienced the desire to contribute equally to the project, and we were able to ensure that each of us did our part to ensure success for the team.
We started the term with a very clear set of "group norms," and we abided by them throughout the quarter. Frequent and regular check-ins enabled each of us to ask questions of the other groups members, share our thoughts, and offer each other feedback. We also documented the division of responsibilities for each assignment on a shared spreadsheet so that each of us could easily track our work.
Between our dedication to the project and an organized and respectful team culture, the four of us created what we felt was an ideal working relationship. The product we created was one which could not have been made by any of us individually, and our work serves as an example of the merits of working as a team.