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.
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.
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.
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
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.