In an era of mobile fitness tracking, there is no lacking of mobile devices that help you keep track of different health indicators. In this scenario, Boots Pharmacy saw the opportunity to enter the health/fitness tracking sector, so that it can redirect old and new customers alike to the wide array of services they provide as a pharmacy. Our team of four junior UX designers were challenged to create a mobile app for boots to achieve these objectives.
Before I discuss the process in depth, I would like to present a challenge we faced after the initial research phase. In the first instance, following the project brief as described above, our group did competitive analysis, screener surveys, user interviews and affinity mapping. We even crafted a persona and while we were defining our problem statement, something did not feel right.
User Needs vs Business Needs
Our user research reflected that users would very much like a fitness one-stop-shop app that is similar to Apple’s Health app. However, our competitive research also indicated that the market is saturated with similar kind of fitness trackers. Our users indicated that they could not justify reasons to switch to Boots unless the app offers additional services or functionality to incentivise that change. So our group decided that in order to create a user-centric solution, we needed to communicate with our stakeholders, and managed to convince them with our research data that we needed to take the project in another direction. That means we had to start from square one, and to reassess opportunities that Boots could explore based on our findings.
After repositioning our app within (see Challenge), we went back to start from the beginning of the UX process.
Before conducting user research, we first turned to comparative research for inspiration and data. This would help us understand what we were facing in the market, and would help align our understanding of the products before we turn to user research. This came in the form of competitive analysis where we identified new competitors according to the new brief. We identified five key direct competitors that were either medicine tracker apps or pharmacy appointment service apps. Our competitive analysis covered a lot of grounds, but the main insight from this exercise was to find out the following: Common features across competitor apps that we should consider adopting, as well as niche features that might be seen as opportunities for our Boots Pharmacy app.
In our initial user research, we devised two set of questions that went into a screener survey and an in-depth user interview respectively. The screener survey consisted of questions revolving the respondent’s current fitness tracking habits and their past experiences with the GP, appointment booking and Boots. The survey helped us find the potential users of our app for a follow up interview. Out of 24 survey responses, we contacted 18 of the respondents and conducted user interviews to learn more about our potential users’ fitness practices. In our second round of research after repositioning, we revisited our interviewees and asked them additional questions regarding their medicine taking habits and methods they used to keep track of such activities. We believed that this information would inform the direction of our design solution, and shed light on how we could utilise what Boots Pharmacy currently offers to add value to the product.
From the raw data collected from interviews, we used affinity mapping to find any emerging patterns and common features, then we distilled our insights and findings into a single persona. This will serve as a culmination of our user research and an alignment to keep referring back to throughout the whole design process.
Following on the affinity mapping exercise, I took the initiative to study the data in a more analytical way. I wanted to be able to quantify the insights and to make sense of the massive spread of data with figures, so I looked into and measured key trends through metrics. I did this so that we could justify the design and functionality of our product through quantifiable user needs. The logic I used was to group trends of insights under the two main business objectives: increase awareness of Boots’ services, and medicine tracking.
After having quantifiable data to validate our new business needs in the brief were indeed matching up with what users really needed, I moved further to justify the features we ideated using the same set of data, this would affect what features to have in our design solution.
Now the direction of the product is clear, and research phase coming to a conclusion. We summarised all our research (user interviews, surveys, competitive analysis) to craft a persona. It is the representation of all our findings, and what the product’s average user should be.
With our persona Maggie as an anchor to the rest of the UX processes that followed, we essentially created a reference point to go back to when we were in doubt throughout the design process. Here is the problem statement we defined:
Maggie needs a way to remember to take her medication at specific intervals during the day because she keeps forgetting/using inefficient methods.
And our proposed hypothesis solution:
We believe that by creating a health tracking app with a medicine reminder notification system, Maggie will not miss a dose again.
From the problem statement and hypothesis solution, we further devised a current experience map for Maggie in this scenario, and proposed a user flow of Maggie’s journey when using the design solution:
Research was very important in the UX process, but especially so in our concept project with Boots. That is because we needed to gauge users’ understanding and knowledge of Boots in order for us to be able to propose the right solution to increase awareness of Boots’ services (business needs). The market is also saturated with apps that can do all variety of functions so we needed to create something that Boots could immediate utilise as their competitive advantage. Hence we created a medicine tracking mobile app.
The app’s key functions were decided when we were analysing user findings (see Process), but we also ideated many more functions that might interest our users. These might be inspired by competitor apps or what we saw as an opportunity because of a lacking from the market. However, there were too many ideas and we decided to do a feature prioritisation exercise to focus on what were essential and low-cost.
From this exercise, we created an initial site map for the app, it would help us categorise and prioritise what users see and interact with in the design solution. As well as help us decide how we should approach the next phase of design — prototyping. From our research, it was clear that users wanted a medicine tracker where they could track what kinds of medicine they needed to take in the day, and when. Our approach on relating this to Boots Pharmacy’s current services was the pharmacy service where the user could utilise the app to not only remind them about taking medicine, but also when they needed to refill their prescriptions.
Prototyping is another big chunk of the UX design process. It is a quick way to create wireframes and mock ups that allows usability testing to kick in as early as possible, so that designers can iterate feedback and make the product viable for the actual users before investing in the development of it.
The four of us each created some low-fidelity paper wireframes, and tested with 3 users each individually. Then we grouped our ideas and user feedback, i.e. the most well received feature / design, to create one combined prototype that we would bring into mid-fidelity for further testing.
From these wireframes, we have created two flows of the product: medicine tracker and reminder, and book an appointment with Boots Pharmacy. In the scope of this project, we decided to stick with the first flow and focus on medicine tracker and reminder as that was reflected in research to be prioritised by our users.
From the mid-fidelity wireframes, we conducted some more usability tests to gauge users’ feedback on how users interacted with the functions now that there was a more overall feel of what the design and flow of the product would be like. Users were asked to perform 3 tasks on the prototype:
The test were conducted with 8 new users so they would not have a sense of familiarity or any bias. The findings were very constructive, as most users found the app not as intuitive as we would’ve expected. Also, task 3 asked the users to change the dosage and 5 out of 8 users expressed concerns about the ability of changing the dosage.
After two rounds of usability testing with about 20 users throughout low to mid-fidelity wireframes. We took into account their feedback, and moved into creating a high-fidelity prototype focused on medication tracker and reminder. This was mainly achieved by one teammate, while another teammate created alongside the main prototype an onboarding tutorial. While I focused on putting all our findings together and created by myself the whole presentation flow, and how to demonstrate everything that stakeholders would need to know in this 2-week sprint.
The following shows the main iterations we adopted to the final high-fidelity mock up:
Moreover, as 5 users commented on their concerns about medicine dosage. One teammate researched more about medication in order to improve the design of the tracker and reminder function. The research showed that our current product should focus on set interval dose medication (e.g. Antibiotics), so that through initial barcode scanning process, the Boots Pharmacy app would be able to obtain the correct dosage from the database, which would forbid users to change dosage by themselves.
What the users could alter though, are the time / day / date depending on how often the scanned medication should be taken, and when they would start their reminder so that the app could work out what time to send a reminder. Users could also opt in or out of a notification reminder. The below slide illustrated the screens user would see in the three scenarios: medicine to be taken per day, per week and per month. We decided for this scope of the project, we would leave PRN medication (taken as needed) for the next steps because that would complicate the problem and the need was not immediately reflected from our user research.
We finally developed a high-fidelity mock up which is a clickable prototype, with all the feedback and improvement iterated as illustrated above. We were happy to find that out of 4 usability tests, users’ feedback were mostly positive. Final round of usability tests showed that users could navigate the app without problem, and that it was intuitive to use. Their main concerns though, was that the prototype’s figures were unrealistic (10 tablets once per week), and in general they would like more details on the set reminder. However, as you might recall, it was a decision from our mid-fidelity tests that we should reduce the amount of information presented. I believe that we needed to test the prototype with more users in order to get a larger sample to get the balance right.
For now, we kept it to a small amount of information because one particular user who was also a long-term medication user actually raised concerns about anonymity when using the app in public. This comment was taken into consideration when we designed the app to deliver just the essential information on screen.
In the scope of this 2-week sprint, our group agreed that we achieved a lot more than we expected. As a conclusion, we went into the user research, and found out a mismatch between business needs and user needs. Based on that, we challenged the project brief, negotiated and convinced stakeholders to the let us approach the brief in another direction. One that was supported by user research. Although that took away our resources to complete the second flow: Appointment booking, we felt that this is an important lesson in UX design as it is a user-centric process. So the next step would definitely be to complete the second flow of the app, while testing the product with many more users. As mentioned, we would also like to start developing medicine tracking for PRN medication (taken as needed), so that the product can accommodate a wider range of users.
Thank you for reading!
Please get in touch if you have any feedback or if you’d like to chat.