Goal: Outline the major requirements and quickly iterate a prototype for an MVP screening tool for the CMS Accountable Health Communities grant, to be delivered 2 months later. Our team started with a Design Sprint following the outline by Jake Knapp in Sprint.
Role: My role in the sprint was to execute user research, create the clickable mockup, implement user testing, and analyze user feedback.
Time: 1 week (June 2018)
Navigators (social workers, case managers) often have a short period of time with a patient in the emergency room to understand their social needs like access to transportation, food, education, financial stability, safety, and behavioral health resources. Navigators currently collect patient information and questionnaire on paper.
Navigators need a digital tool to collect the screening data with patients, display resources available to the patient, and to fulfill report requirements to CMS.
•Engaging developers in the design process upfront is not traditional, but it was a great new team bonding experience and helped push the boundaries for user considerations while providing the technical limitations to ideas and helped us establish a realistic timeline for our designs.
•The solution had to be broad enough for adaptation at more than 20 clinical sites, yet still focus on the navigator's usage of the tool and human interaction with patient care. Balancing various
•We quickly realized that working with so many hospitals meant that we would deal with hundreds of varying opinions in user feedback. We created a stakeholders map to establish priority of feedback (interest by influence).
•I was lucky to have experience designing for care management teams in the emergency room prior to joining this team, so I already had an in-depth understanding of their workflows.
Deliverables: Sprinting to a Screening
After hours of expert interviews and white boarding, we created a journey map outlining the overall vision of the process for the CMS patient achieving its goal to receive social resources.
This journey map was our focus for the entire sprint -- the Screener administering or entering the screening with a patient. The journey had to take into consideration the experience of all actors in the larger system, not only those who might interact directly with our tool.
How Might We...?
The team identified opportunities for the screening tool and we voted on the most relevant ideas (below):
•HMW establish patient trust?
•HMW control access to the system?
•HMW allow screener/patient to navigate questionnaire to only answer what they want?
•HMW design a workflow that is broad enough to implement in various clinical settings?
Solutions through Rapid Ideation: Crazy Eights & Storyboarding
Most importantly, I focused the storyboard experience on two narratives: the Navigator/Screener and the Patient. In the healthcare setting, each of them would be interacting with the tool alongside each other. They also would interact with each other outside of the tool, especially in conversation to ensure that the patient was comfortable.
Confidential and personal information is shared during the screening, so I made sure that our screens would provide friendly, trustworthy content to the patient (in appropriate literacy levels and iconography) to help them understand how their data is used. In the storyboard and screens, we clearly have the Navigator and Patient review the consent process and wanted to provide customized screens for each person interacting with the tool.
At this time, we had to make some trade-offs to focus our design, such as security infrastructure or the specific data model. Developers didn't like refraining from focusing on the backend, but we knew it was essential to figure out the navigator's experience and content needed to make the data model.
Makin' a Mockup (and Prototype)
We made wireframes on paper sketches to translate into a low fidelity clickable/interactive prototype in Invision. Unfortunately, the prototype is no longer available to view online.
This view is for the Navigator/Screener. While my initial storyboard included a checklist for the Screener (3rd sticky note), we omitted it in the actual prototype and instead implemented a navigation bar of the sections in the screening for easier movement in the questionnaire.
Next, we interviewed multiple 5 end users across 4 hospitals to test the prototype. We combined our notes and created a report of the negative, neutral, and positive feedback from users (excerpt below).
Major User Feedback Takeaways
•All users interviewed agreed that the screening tool and resource directory would add value to their workflows.
•Necessary to establish trust with patients by explaining the purpose of the screening because they may not feel comfortable sharing their personal information with navigators.
•Need to explore impact of self-administering screening vs. screener administering with patient: 1) User experience potentially affected by loss of ‘human-touch’ (scripting); 2) How does this affect the functionalities of the tool for usability with people who are illiterate or vision impaired?
Post-Sprint Delivery: Translating Prototype to Action
We made some changes after user feedback and started translating the prototype into user stories to fill our backlog in JIRA (examples below). Due to product scope changes, we did not meet the 2 month deadline for our sprint. But, we did have more time to continue designing the screening tool, which you can see beyond the weeklong sprint, here.