UM Health Research: UX Research & Design


Summary
  • Role User Experience Designer (Summer Internship)
  • Company UMHR - University of Michigan Health Research
  • Location North Campus Research Center, Ann Arbor
  • Skills Contextual Inquiry, Interviews, Iterative Prototying, Usability Testing, Frontend dev
  • Year Summer, 2017
  • Links Invision Clickthrough Prototype Click here

Introduction

UM Health Research has two primary user groups. First, the patients or health study volunteers who participate in studies using the web app umhealthresearch.org. Second, the research community who have an IRB (institutional review board) approved project for which they need to recruit patients. After a successful redesign of the patient side of UMHR by the team, this project's goal was to redesign the researcher side of UMHR. I contributed as a UX designer for a little over 3 months and worked in a team of two, me and my mentor.

The journey map below maps the steps health study volunteers typically go through on UM Health Research. (Click image to see it bigger)



The journey map below maps the steps health study researchers typically go through on UM Health Research.



Process

1

Background Research

Interviews and Annotations

Contextual Observation at 8 hospital spaces

Usability Tests (lab)

I mapped out the information architecture of the web application currently in use by the health researchers to recruit patients and volunteers. Click image to see bigger.

Next I mapped out the interactions in three core areas. This is a map of the steps researchers take to screen patients. Boxes and Arrows for every step helped me understand the nitty gritty of the complex set of interaction between the researchers, patients, regulatory bodies and my organisation - UMHR.

Map of how researchers interact with participants. This formed the core of the interaction design challenge.

Map of how researchers get approval from the IRB and then go on to create studies on UMhealthresearch.org.

We went in a team of two to the workspaces of researchers to interview them and also take a note of the context in which they work. Since its not possible to absorb all the information available in a 30 to 60 minutes interaction, I usually (with the permission of the interviewee) audio recorded our conversation and took photographs of their offices.

Applying the W shaped model for problem solving developed by Jiro Kawakita in an attempt to synthesize experiential and cognitive level of thought. We move from awareness of a problem to collection of data and subsequently identifying a problem and proposing a solution. More about it in this paper by Raymond Scupin.

After contextual inquiries we mapped out issues in our war room. (Affinity Maps)

The contextual inquiries and interviews helped us get a deep understanding of the problem that lay before us. But before we get into that, I must add that this process helped us understand our core user groups. We found three groups of users: (1) a professional recruiter hired by the research team; (2) A PhD student or a research fellow assigned by the principal investigators to be the study coordinator and reach out to patients; and finally (3) students like me who were spending the summer researching and were given the task of finding participants.

Instead of going with the persona - scenario based approach, we decided to go with the Jobs to be done framework proposed by the Intercom Group. (part of my competitive benchmarking involved studying Intercom's super user friendly products) This was mainly because we wanted to be specific about the front end work that lay before us and we didn't have a lot of time to develop accurate and representative personas, despite the fact that our user research clearly revealed to us three target groups as described above.

Oftentimes, we hear JTBD advocates referring to the famous Theodore Levitt quote, “People don't want to buy a quarter-inch drill, they want a quarter-inch hole.”

The core differentiator between JTBD and these traditional system-analysis techniques is that JTBD is much less prescriptive about what exactly the users’ task is, and how they will accomplish it. Task analysis and use cases aim to understand the best way in which the product can handle the typical activities that users need to do (and often end up being biased by existing solutions); the JTBD approach moves the focus on desired outcomes and questions whether those typical activities are the way of reaching the outcomes that users really seek. (n/n group)



There was poor signal (qualified patients and volunteers) to noise ratio and we needed to redesign the screening process.

The current solution was poorly designed to manage thousands of participants for the multiple studies a researcher might have going on concurrently.

Communicating to inform and schedule appointments with patients was another major nigtmare for the researchers. Fortunately, our users were willing to actively participate because there were serious problems hampering their productivity.

Issues that came up during interview interpretation were collected and put up on a wall using sticky notes. The first design were on paper and of very low fidelity.

Iteration Round 02 on Invision

Sketch Mockups were edited after interview rounds.

After multiple Iterations our war (of ideas) room looked something like this. Affinity wall notes were periodically presented to management and backend developers so they could plan the logistics of their effort.

To conduct Usability Tests we invited users to our office to test out out our new front end. Yes, lab cconditions have their drawbacks but there was very little time left in the internship to deploy a full working webapp and test it in the real world context.


Old vs New Design

Link to New Design, a Clickable Prototype: here.>

Old Dashboard

New Dashboard

The proposed design for dashboard shows what's most valued by users: new messages and new volunteers. Studies with low participation rate also value system's recommendations hence that was inlcuded in each study card.

Old Participants page

New Participants page

Each study has a separate participants page. In addition, researchers can screening questionnaire based filters to sort and put patients into folders (shown in color).

New Message Section

Earlier it was much harder to access messages in the crowded profile section shown next to the entire patient database. The proposed design offers a separate database for each study and a separate message thread for each patient. Messages can be seen within the same team.

New Profile Page

Earlier the profile page was crowded and there were no clear action buttons or notes section.


Major Findings

1. Too many disqualified patients and volunteers showed (poor signal to noise ratio).

  • A study requiring non diabetic patients could receive up to 70% responses from diabetics. Due to privacy issues related to health data, UMHR cannot use advanced survey tools like those provided by Qualtrics to reach out to patients so a screening form must be built inhouse. As it's often the case, technical feasibility was a big issue in implementing a dynamic answer dependent form for screening patients. Our design tried to minimise this by using simpler mechanisms like terminating the form based on patient's answer if the basic demographic profile was not disqualified.
  • My study clearly mentions that we need only diabetic patients but I get hundreds of patients without diabetes. Being able to filter out based on screening criteria is the best!

2. One researcher or study coordinator needs to manage many studies at one time.

  • The principal investigator would never manage recruiting and managaing patients and the subsequent screening and scheduling. These responsibilities would be taken care by the three main user groups i.e. Professional Study Coordinators, PhD or research fellows and other students. Of these atleast the first two groups often manage many studies at a time but the current system merged all patients in one database. Our design proposed a labelling system so that patients could be organised study wise. In fact we decided to go with one dashboard for each study that had information like 'New Messages' and 'Recent System Recommendations' (that users valued) clearly prioritised.
  • Every study has its own legal procedures and it's great that I can create templaates and attachments for consent and map directions and so on ...

3. Out of the three persona groups, two change composition every 3-5 years but one remains - UM salaried study coordinators

  • Eureka Moment: Only after several visits to our users did it dawn on me that the primary user group that doesn't graduate or change career paths often is the professional study coordinator. These were in most cases women, rarely aged less than 35 and not very tech savvy. They have had to see their whole profession change dramatically due to the rise of internet and social media. They have stopped visiting patient centers and make calls only after consent forms have been signed. For them we decided to keep the design very minimal and obvious with clear instructions. Their mental model is reflected in both the interaction and visual design.

Learnings

1. A UX designer has no room for subjective biases of either designers or managers or even the users (which is a bit tricky).

  • One of the really positive things about my internship was access to target users who had major issues with the existing solution. Recruiting users for the multiple rounds of testing was easier than it has been ever been for me. As a result, most design decisions we made had origins in the user research or user testing. I iterated & iterated & iterated with confidence. We tried to minimize our bias as far as we could and this gave me confidence about my UX research skills.

2. Communicating without speaking

  • In many areas, due to his experience my mentor could think more widely and deeply than me so I was attentive to his approach. I learned many things by just observing non-verbal cues when my mentor handled issues. I paid attention to his point of views and his workflow for technical work. One example is when we took interviews together: since my mentor had cultivated relationships over many years with target users who he met periodically, I let him lead the interview and acted as the note taker intervening only when I thought he may have missed something crucial.

3. Cultivate meaningful relationships and establish rapport with users.

  • The speed at which I worked over the past three months was exponential in nature partly because initially, I was new to the work place and the project domain apart from working in a new culture. I overcame my slightly introverted disposition to make my interviewees and users comfortable although I have a long way to go before I consider myself a good interviewer. I am deeply grateful to the vibrant research community at UMich that gave us so much of their time. Overall the whole experience was rewarding and I am very happy to have made the decision to work where I did.