How might we —

Empower patients to play a central role in determining what health research gets done


Before WellSpringboard, the only way patients could be involved with health research was by being research subjects. Scientists were the ones who decided what research should be done. However, this approach was no longer suitable for the health problems of today. We realized that we needed our scientists and our patients to work together in determining what research to be done and how it should be funded. WellSpringboard is a platform where this collaboration can take shape.

My Role

I led a team through the UX Design for Wellspringbord. Phases included User Research, Product Strategy and Product Design.


  • PCORI App Challenge Runner Up 2014
  • MICHR Big Idea Winner 2015
Patient engagement in health research is usually only limited to patient participation as research subjects. We want to change that and make patients the true center of the research process.

The Patient-Centered Outcomes Research Institute (PCORI) Matchmaking App. Challenge

The 2014 PCORI Matchmaking App Challenge provided an opportunity for designers and developers to create web-based or smartphone-based apps that would spur collaborations among patients, caregivers, clinicians, and other stakeholders interested in health research.

To respond to this challenge, we set about designing and prototyping a mobile application that would combine the power of crowd-sourcing and crowd-funding to identify research questions of greatest interest, and provide financial incentives to promote research on those questions.

Early WellSpringboard prototype

A working mobile app. MVP. This formed our application for the PCORI Matchmaking App. Challenge


To get to this point, we first started with paper sketches like the ones above. We used these to gather feedback from our patients.

Invision Prototype

We refined granularity as we moved forward. Above is an inVision prototype that we used for testing with various stakeholders.

We placed second!

We placed second in the challenge. As a result, we received some monetary support and national visibility. Here is the press release from PCORI announcing the winners.

Wellspringboard placed second in the national PCORI App Challenge and was one of the winners in the MICHR Big Idea Challenge.

MICHR Big Idea Challenge

The monetary support we received was not enough for us to launch Wellspringboard in the real world. We still needed to tie things and perfect the user experience. It was about that time when we realized that MICHR was putting up a challenge to support new and innovative ideas in health research.

We competed with close to 70 applications and were award the MICHR Bid Idea Award. This was a sizable pot of money. We identified two priorities we wanted to use this money for:

  1. Bring a successful experience of Wellspringboard to market (a.k.a Release the product publicly).
  2. Let the world know about it (a.k.a Outreach and growth marketing).

Designing a production ready application

Now that we had some resources, we had to actually design and build a production ready application. Not just something that could be demonstrated to a jury but something that could be used by real people in the real world to collaborate around health research.

So, we set about designing the production version of the application. This would be a responsive web app. that could be used by anybody anywhere.

We went through the same sketch->wireframe->prototype->test cycle to narrow uncertainty around what needed to be built and how the experience needed to be. Below are some of the mockups we developed to think and to test:

Wellspringboard landing page
We kept the interactions simple so that patients and caregivers with multiple needs and contexts could participate.
A big part of our focus was on using the micro-interactions on the site to keep the process transparent.
Ideas would be mapped with researchers and opened up for crowdfunding.
An administrator would be able to approve ideas and match them to researchers.

User Testing

You are possibly wondering why user testing as a topic has come up so late in the story. We actually continually did user research with patients through the process. However, up until this point the user research was more ad-hoc and “in the wild” so to speak. We spoke to patients at events, in clinic waiting rooms or on the street. The goal of this phase was to understand what to build.

Once we had a robust prototype to work with though, we switched to doing more formal user testing. This phase was focused on identifying usability gaps in the application.

Patient interviews

Our physical user testing setup. We had a moderator and an observer in the room while other team members observed remotely (via web-conferencing software).

We invited patients and caregivers representing various age groups, medical conditions and life contexts to come into our office space for a usability session. We split up our sessions into three parts:

  1. Understanding our patients as people — what are their values and motivations. (20 mins)
  2. Gauging their knowledge of health research — how comfortable they are with the idea already (10 mins)
  3. User Testing the Wellspringboard prototype (30 mins)

We organized the session so that we went from the broad to the narrow. We wanted to understand the person, their values, contexts and motivations first before diving deeper into user testing the application. We hoped that this would give us a richer understanding of why people were seeing things the way they were.

We recorded the screen and the facial expressions of our user as they used Wellspringboard. Matching what they were doing with what they were saying and their facial expressions provided us with more in-depth insights.

We got some great insights from these user testing sessions. We analyzed these insights using affinity maps, color coded theme analyzers and card sorting. The findings were then used to update Wellspringboard.

Physician interviews

Given the time constraints and the fact that we were surrounded by physicians, we chose to rely on our assumptions. We did not focus user research efforts on our physicians. We assumed that if we build it, they will use it.


Now that we had solid, tested designs, we set out to actually build Wellspringboard. We created user stories in Trello and and used those to track our progress. In this phase, I took upon the role of a project manager and a development liaison.

Our Trello board. We used it to track progress and knock-out user stories.


In June 2016 we opened Wellspringboard to the world. We received coverage internally at the University, and externally around the state:

Patients loved it

By August that year, we had over 70 ideas submitted by patients and caregivers.Patients told us that they were thankful to have a voice, and very hopeful that they would be able to make a difference.


While we received great ideas from patients, and while U-M has many researchers searching for cures and improving treatments, we simply were not been able to match all the ideas with researchers who had the time and resources to take on another project. While researchers were interested in the idea, the incentives available were just not enough to compete with those available from bigger funding agencies.

The success of our failure

So, after much deliberation, we concluded the WellSpringboard experiment and set out to build what we learnt from it into improving our community engaged-research efforts across the research spectrum. We accepted that we needed to rework our researcher participation model. Making patient ideas visible and priorities known was just one piece of the puzzle — we understood that we needed to, and are, building an entire structure around community-based research initiatives. The learnings from Wellspringboard form the foundation of our strategic vision for using technology to engage communities around health research.

Assumptions are an inevitable part of product development. This project taught me the importance of managing risk while making assumptions.


  • Buyers and sellers are partners. As such, the buyer experience is just as important as the seller experience. We focused all our user research efforts on our patients and assumed, based on the echo-chamber that we were in, that the researchers would come. This broad assumption left us with no way of understanding all the barriers that our researchers would face.
  • Assumptions are an inevitable part of product development but I now try to synthesize the teams I work with to manage risk while making assumptions.

Other Case Studies