Design Process
Empathize & Define
Drew upon the general need for a patient's medicinal drug administration compliance for physicians and pharmacists through the use of:
- A Request for Proposal
- Stakeholder Interviews
- Mock User Interviews
IDEATE
Set our sights on a mobile product that utilized a pre-existing governmental framework as a foundation for the product then gearing overall product functionality to user needs.
prototype
test
Held a user testing session, iterating upon medium fidelity wireframes, then presented our final solution to a panel of stakeholders who awarded the project a passing grade.
Pre-Design Phase
A Semester long group project
Simulating the real world endeavor of a procuring a proposal for stakeholders, this project hit the ground running in an attempt to introduce a solution that assists in combatting the opioid epidemic. Based on the presented data from the request for proposal, the overarching pain point that resonated with all team members was opioid abuse and how each user group we defined - prescribers (doctors, physicians), dispensers (pharmacists), and patients - play's their part in an uninformed communications mess.
My Goal
I had one overarching ambition in approaching this project and it was to fulfill the role of a designer throughout the full design process of the product as well as learning as much as humanly possible in applying a user centered design methodology.
Design Phase
challenge ONE
As this was the first big group design project for many on my team (6 members total), including myself, the initial wave of approach was a bit haphazard and chaotic. Thankfully, after much compromise during the initial ideation stage, my team settled on an approach that came to be structurally sound and effective.
Initial ideation & user research method: stakeholder interviews
In the first phases of our project, each member proposed their own ideas for plans of attack. At first, we were gravitating towards developing an entire system from the ground up that integrated prescribers, dispensers, and patients as users. After interviewing stakeholders, whom of which were pharmaceutical academics at the University of Pittsburgh, that option proved to be a last resort due to its sole reliability on voluntary participation of all 3 user parties involved. There were also discussions about coordinating the use of medicine bottle cap smart technology. That idea was put on the back burner due to the financial strain of interfacing with third party technology that the patient user group would ultimately have to pay for. After roughly four meetings of brainstorming, stakeholder interviews, and personal research, we agreed to converge on utilizing the PDMP. Why? Efficiency and priority.
Solution
What my team aimed to deliver was a mobile application that paired with a preexisting federal system, known as the Prescription Drug Monitoring Program (PDMP), ultimately bridging together our 3 user groups of prescribers, dispensers, and patients to manage prescriptions as well as track drug administration compliance. The PDMP in itself purely accommodates the tracking of prescriptions for two of the three critical parties involved with the prescription process: prescribers and dispensers. Concord Health Management (CHM) incorporates the final party, the patients. Hence, through our application's API, prescribers and dispensers would have access to the administration compliance of patients allowing for mitigating against abuse while the patients would benefit from tracking personal health records and taking advantage of features designed to better their drug administration experience.
incentive
With every product comes the challenge of driving its existence into target markets and getting people to use it. Being that our product is a technical solution in the form of a mobile application, two major points were to be taken into consideration for incentivizing users:
- How do we initiate with users to install our product?
- How do we drive consistent use of the product?
In total, our team had three brainstorming sessions focused upon how to answer those questions. At first, we heavily set our sights upon using drug administration compliance (i.e. patients taking their prescriptions correctly) scores to reward discounts on health insurance - gamification. But, we quickly realized how easy that form of a reward could be taken advantage of. Plus, we had no concrete way of financing a discount - who would pay for it? We then moved onto the topic of a more merchandise oriented rewards system. Daily utilization of the application and submitting inputs verifying that the user has administered their drug timely would incur points to be put towards products in an in-app store (hoodies, mugs, etc...). It was only for a quick moment that we discussed this form of incentivization and I was one of the few members that didn't fully support it mainly because it seemed to be in the same ballpark as the discount incentive. Therefore, we compromised and agreed to get user feedback on this feature during the research sessions with the prototype.
What we agreed to go with in terms of initiating the user experience was an automated text message sent to a patient after they had been prescribed a medicine. Within the text message would be a brief description of the app and a link to install. As for driving consistent usage, I researched how positive reinforcement is a golden pillar pf keeping users involved. We reinforced users by displaying their compliance scores in the form of an emoticon. The higher the score: the more joyous the expression. Down the line, more features could be added to the emoticon like feeding it, exercising it, etc...
Deliverables
- Sign Up to Install Text Messages
- Prescription Pick Up Confirmations
- Refill Notifications
- Medicinal History Log
- Home Page Dash Board
- Drug to Food/Beverage Interactions
- Administration Schedule & Notifications
- 30 Day Compliance Reports
prototyping Tools & Process
My UI design process followed plain but effective procedure for this project: discover every member's perception of the app's look, sketch low fidelity wireframes on a whiteboard in front of the team, discuss and prioritize elements, mock up medium fidelity wireframes (below) with Axure RP, introduce these to the team and reiterate the discussion process taking the new feedback into designing the high fidelity wireframe (interactive prototype at the top of the page) using Adobe XD. I also made use of Google in locating a copy left picture to then edit in Adobe Photoshop for the background of the application.
Medium Fidelity Wireframes
Over the course of researching competitive products on the market, a fellow team member and I discovered a sense of general palettes and information architecture for more detailed wireframing. We settled in prioritizing displayed information in a few pages: registration page, a dashboard, medicine log, and calendar.
challenge two
In an attempt for proper feedback on a prototype based on the wireframes, I pieced together an invitation that was sent out via a mass email to roughly 150 health science students for a feedback session. These sessions were to be proctored by myself and a designated team member with the use of a brief presentation and product testing. Unfortunately, not a single tester showed up for the given time slot so, due to the time constraint, we decided to fulfill the testing roles ourselves.
Testing for feedback
Plan B for testing for feedback resulted in my partner and I formulating 3-5 personas each and role playing them as the other noted all thoughts, actions, and expressions. It turned out to be insightful and not to mention - fun! It opened up conversations specifically concerning users with a limited technical aptitude. With that, we added a future feature that outlined a tour of the product as users logged in for the first time.
DURATION
In totality, this project took approximately 14 weeks from the first brainstorming session to our final presentation in front of a panel of stakeholders.
post Design Phase
In Retrospect
Over the course of this project, there were a handful of hurdles that I reflected on aiming to better attack in future design applications.
Incorporate Users for Testing. With the limitation of time for this project, relying on my partner to simulate being a user was a last ditch effort but I definitely aim to prioritize proper testing of the product with users in the future.
Calculate for Valuable Wins and Mitigate Detrimental Losses for the User. This was, in totality, the largest project I have been fully a part of from beginning to end. When working in a team with 5+ members, I've learned that compromise is key especially concerning internal rapport. But I am a part of the project for one reason and that's championing the user's best interest. As I go on to work with other teams and team members with different levels of experience/points of view, I know I won't be able to win every debate for what is right for the user but being weary of that over the course of the product's design, I believe, will help me grow as a designer.
