Mission: Cure is a non-profit organization focused on pancreatitis. It aims to drive new research, accelerate drug discovery and development and help create hope in the community. As part of the initiative, they want to create a mobile app that serves as a resource for patients and caregivers and builds the capacity for them to advocate for better care practice. So my team was tasked to design and deploy a mobile app from the ground up, which engages patients and caregivers with curated information that is easy to navigate, understand and reference.
This project was successfully designed and developed during the first two project cycles which I designed for. We achieved a significant milestone by completing the key features of article-reading, note-taking, global search, onboarding, and use profile, and produced detailed documentation for future project work.
In the start of this project, we received a product requirements document (PRD) that outlined at a very high level the purpose of the app, what it should do, and who it is for, etc., along with some content for the app in the form of a Wix website.
From a design standpoint, we had to understand the product vision and requirements and thus translate the abstract concept of the app into concrete features.
The overall vision of the app is for it to be a user-friendly and interactive platform for patients and caregivers to
This means that users should be able to read curated educational content provided by the app, take notes on the content, and keep a running list of questions for their doctors.
The client originally gave us two separate personas, which were
Both personas were at age 12 and above in order to properly engage with the content.
After analyzing the needs of these personas, we, the design team, decided to merge them together as we thought having one persona was appropriate. That was because patients and caregivers have very similar needs in the scope of what our app offers. They both need to receive accurately curated content based on their conditions and interests and to easily understand, navigate and use the app features.
Therefore, our persona was determined to be patients and caregivers of patients with pancreatitis and recurrent acute pancreatitis, who are at age 12+.
In order to figure out the app features and our design scope, I initiated a user story mapping session among designers. This helped us visualize what our app offers from the user’s perspective and establish a common understanding in the team as well as with the client. Then the map evolved throughout the project cycle as we iterated on our designs and adjusted our scope slightly because of everyone’s fluctuating availability in this volunteer project as well as client feedback.
Since we had a much better idea of what this app would look like, each designer including myself started sketching.
I began with sketching the home screen and nav bar first because I wanted to start by gaining a bigger picture and visualizing how users might navigate between app features. Then, I moved on to sketch out these features.
After that, we compared our sketches, gave each other feedback, and presented them to the client so that we’re all aligned with the general direction we’re going in.
We also discussed which parts of the app we each wanted to focus on going forward. The parts that I took ownership of were
The note-taking feature allows users to engage with the app content, mostly articles, by adding notes and highlights as well as referencing them.
One of the main decision points was around whether to have two separate modes: read and edit, of which the latter allows uses to annotate the article.
My first lo-fi version didn’t have the two modes, which had several limitations.
For example, users couldn’t add multiple notes to one article. They also couldn’t reference a specific piece of content of the article in their notes.
To resolve these, I added the ability for users to attach sticky notes to anywhere in the article. However, I realized that stickies and highlights could accumulate to a point where they might interfere with the reading experience. This led me to create a separate read mode.
I tested this version and many of my participants didn't understand the separation of two modes or the expansion of the tool bar. Further, our client at this point confirmed that the articles to be placed in the app in the future would stay relatively short, which means that it’d be rare for users to add too many annotations that would make it difficult to read.
Therefore, I decided to remove the modes in the next high fidelity version to avoid confusion for users and unnecessary complexity for the development team.
After some additional changes, I felt ready to test this prototype with actual users.
The client helped us recruit some users with whom we conducted usability testing. In these sessions, the task that I gave to participants for this note-taking flow was “to find the article ’Potential therapies’ and take some notes on the first paragraph.” We followed a think-aloud protocol and watched the participants complete the tasks.
Overall, participants understood the expansion of the tool bar very well but some were confused about the icon used for the note/stickie tool.
Based on the findings above, my next step was to make the toolbar easier to understand, by finding better icons that would still match the icon pack we had been using for the entire app as well as adding text labels for the tools.
As I was exploring different possibilities, our development team told me that they could not make the toolbar expand horizontally to the left and it had to be vertical. This would make the toolbar block too many lines of text when users read, but I had to respond to the technical constraint. As a result, I decided to hide all inactive tools when one tool is active.
The current design and development prototypes are shown below. These are NOT final and I'm personally making iterations on the design.
In this project, we have weekly meetings with all team members so developers were always engaged in our design process. This allows us designers to get timely feedback to make sure our designs are technically feasible within the project time frame.
Going forward, I want to make sure that my team continues to communicate our designs to the engineers, show them prototypes to help them understand the flow as much as possible, and listen to their feedback.
For the note-taking feature specifically, I would like to focus on breaking down the dense text so it’s easier for users to digest content and adding an option to change type size for accessibility purposes. Then I’ll test the prototype and make changes accordingly.
At the moment, we have some reusable components, grids, and color and text styles, based on client supplies, design system guidelines and best practices. However, we have not been able to be completely consistent among designers yet. So I would like to make this task one of the must-dos in the current cycle.
Based on designers' experiences and expertise in the last cycle, we started from designing for iOS and wished to move to Android later.
As a next step, I would like to study in depth the differences between material design and human interface guidelines so that we could implement them in our designs.
