At its core, MyTherapy is a medication reminder application. People use the MyTherapy application to set various reminders for themselves throughout the day.
In addition to medication reminders, MyTherapy can be used to track intakes (progress reports) and send reminders when your inventory is low. The intake tracking and progress feature is really important to users who would like to update their doctors on how everything is going. However, the inventory tracking feature is set up inside the scheduler. All of these other features that affected the scheduler feature, needed to be considered at all points.
The scheduler feature inside MyTherapy is used to create reminders for when to take certain medications. The complexity sounds relatively simple, almost too easy. However, the real complexity came in through the different types of medications that are available around the world, and the possible variations that users might have to take for these medications.
Examples of these medication schedules could include:
Our users had become accustomed to using an older scheduler that had never been updated since its first launch. This did not mean that it was easy to use the system, and it did not mean it was intuitive either.
To choose the frequency that the user wanted, they needed to go onto a specific screen and understand what each option inside there could do. There is no explanation, no way of showing the user what each can do. The app also is relying on the user to ensure that what they select is correct and in order.
Currently, the scheduling hinged heavily on the users understanding of a complex set of inputs and pickers, to make their unique reminder sequence for each medication. We identified some clear pain points when starting this project:
The scheduler is the most important feature of MyTherapy. Without being able to schedule medication, the application is null and void. Due to this, I decided to work on a customer journey map for the feature, to lay out the end goal for the feature and make sure that every addition to the feature has a specific goal and works towards the end goal.
The idea was to break this task down into separate phases. The initial entry into the scheduler, selecting the frequency, then displaying the scheduler post setup. The entire process is critical to the feature, and ensuring that all these parts work well and work well together was the main idea behind the customer user journey.
See below for a link to the customer user journey, you can view it in full screen, zoom in and around and read some of my comments and thinking.
There was no way we would be able to get this done inside one single sprint, nor would it be possible inside one release cycle. So the team and I decided to work on singular features at a time, get those into release, and ensure that each feature inside the main epic, would work and still allow for a usable section of the entire scheduler feature.
We broke it down by using stats from the previous scheduler, the frequencies that were getting the most used would be the ones that would be started with first, going down the list until we had added them all into the main scheduling feature.
Below is an example of how we did this. The below screen is the frequency selector screen, with each addition, each new frequency was added and the screen made its way to its finished state.
The scheduler screen would be broken down into 2 main areas, 1. selecting your frequency and 2. editing that frequency to the desired level of reminder. Each area needed to be easily understandable, they needed to work efficiently, and they needed to look great as well.
With the application being used on both Android and iOS, as well as being used by millions of users across the world and in different languages, there needed to be lots of consideration around these factors. Would the designs work with each platform, and would they work in multiple languages, both in right to left and left-to-right text?