While 95% of Americans support organ donation, only 58% are registered. This gap exists in the face of an expanding transplant waiting list. This project focused on creating a website to increase the number of registered donors.

Our team initially comprised of three members from our UX boot camp cohort. One member left the program two weeks in, leaving only two of us to forge ahead on The Organ Trail. Gretchen Walker (check out her work too!) and I had blast working together. You often get lucky with your teammates.

Research

What did we do? We created a short 5 question survey in Google forms, and shared it via Facebook and Reddit. Our goal was 50 responses. We each conducted three face-to-face interviews including a member of Utah’s organ donation operation. We developed open ended questions to go more indepth.

Why did we do it? Our assumptions for this problem (miseducation, morbidity of the topic, etc) needed to be grounded in evidence. The survey questions allowed us to understand why people do or do not register as organ donors. The interviews, as opposed to our survey data, would provide qualitative data that a simple form could not convey.

What were our results? Within 36 hours we received over 100 responses, and miseducation seemed to be there primary cause.

The interviews further validated the survey data and our assumptions. These included miseducation, mistrust of the healthcare system, and religious reasons. The expert interview offered insider insights, with the following quote as they key takeaway:

What did we learn? Before research, we assumed the main reason for non-registers was lack of education. The surveys and interviews confirmed this. Even the registered donors cited a lack of education. The interview responses provided a better sense of how the average person interacts with organ donation. Our solution would be built upon educating with an emotional impact.

Design learning lesson? It would have helpful to conduct the face-to-face interviews prior to generating a survey. We would have developed better questions on the mass survey, and thus better data.

The Persona

What: Our persona was an attempt to blend all the voices from the surveys and interviews. The persona’s goals and frustrations were derived respectively from the survey questions as to why people do or do not register.

Why: Through the lens of this persona, we catered our design to their goals. It would help remove ourselves from an outsiders point of view. The persona was an anchoring point throughout the design process

Learn: Blending the wide range of responses into a cohesive voice was tricky. At first it might seem strange, but the value of having this persona proved itself further down on the road. In the design process, we often slipped into the assumption that the website would be geared towards non-registered donors. By having the persona in the background, it helped course correct us at certain points.

Design learning lesson? It was easy to forget the persona as we delved into the weeds. Something as simple as keeping a printed persona on the wall could serve as a frequent reminder.

The user story map

What: A simple matrix of the user story map was the guiding structure (see the matrix below). We transferred the narratives, goals and tasks of the user from the research results.

Why: This would create a hierarchy of priorities in our design. Also, the design would be more scientific rather than going off our own intuition.

Learn: During the process we oftened returned to the story map to guide our decisions. It reoriented us as we hit obstacles. This was critical on the homepage layout. We wanted to speak to the overarching narratives, but also provide accessible paths to tasks. For example, how to find inspiring organ donor stories, but also getting a non-registered user to sign-up.

Design learning lesson? In hindsight, I would have tried to make the story map simpler. We overshot on the number of tasks without trimming off the fat. This often led us down unwarranted paths.

Card sorts

What: We eventually identified 11 tasks, and it was time to organize them. We performed three open card sorts to see how users would group them. This step revealed the theme of each category as education, registration, and inspiration. Then a closed card sort with three new users revealed how to organize the 11 tasks amongst the categories.

Why: The card sort exercise demonstrated how users would intuitively group tasks.

Learn: The variation in the card sorts proved that not every user assumed a task would be in the same place. We went with the most common placement of a task and decided it would only change if usability outcomes dictated.

Design learning lesson? It would have been interesting to have done A/B testing here. For each test, create a second set of cards of the same tasks just with different wording. I worried that the way we worded the tasks might be leading to the card sorter.

Wireframing

What: The solution started to become tangible. In Sketch, we created a page for each task and organized by the card sorting categories. These pages were centered around the homepage.

Why: By wireframing, we could start building our skeleton without wasting time on finer details. This would also allow us to start visualizing user flow.

Learn: The wireframing process showed us how the website would begin to feel. It also showed how a variety of iterations were possible. Although it was tempting to start filling in content, it would have been distracting and likely a waste of time.

Design Learning Lesson? I would have used Sketch more. We mostly used pen and paper on this step until transferring to Sketch. Although I would still start with some basic pen and paper drawings, having cleaner iterations in digital formats would have helped.

Low-Fidelity Model

What: Now it was time to put some meat on the bones. With the basic framework in place, we were faced with the decisions on fonts, colors, images, and copy. Although we did not yet need the final product, we got a feel of how time consuming decisions on the finer details could be.

Why: We needed something that felt like an actual product to start testing usability. We didn’t want to start going down the high-fidelity path as not to waste time.

Learn: It was hard not to venture into high-fidelity territory, but instead focus on a working product. The persona and story map were critical anchor points to keep the focus on organ donor education and emotional impact. The lo-fi version proved to be “nagging” with too much emphasis on pushing the user to the registration process.

Design Learning Lesson? I would have focused on making a more readable lo-fi model. A simple monochrome color scale would have made the first viewing for people easier. This would have allowed them to offer better feedback instead of squinting at the site.

Redesign

What: Now was the time for the first design review — our work up to this point was put on full display for critique.

Why: Before sinking hours into the high fidelity model, we wanted feedback. Fresh eyes would point us in a better direction.

Learn: This turned out to be one of the highlights of the process. Putting something on display in front of a large group was somewhat nerve racking. It was also extremely helpful to confirm design decisions we were hesitant to make. The feedback guided us on necessary revisions.

Design learning lesson? Keeping better notes on feedback! I should have audio recorded the feedback offered from all the voices in the room.

High-Fidelity Model

What: At this point, Gretchen and I split off to complete our own high-fidelity models.

Why: This would allow each of us to develop our own vision and have something to call our own. By this point we each had enough foundation to provide direction.

Learn: Working alone had its pro’s and con’s. I missed having a teammate that was familiar with the project to bounce ideas off of. Also, having to make style and design decisions often sent me down rabbit holes. The initial design review provided a long list of improvements.

Design learning lesson? Centralized project documentation! There were so many times we had to bother each other to retrieve some piece of the project. Hours would have been saved if we had documented the process with more thought.

Usability Testing

What: With a functional and somewhat finalized product in place, it was time to test it. I created a template for my usability testing with four of the most common tasks and set out for five tests. I repeated this three times, implementing corrections along the way.

Why: By this point I was too deep in the design and needed to see it through fresh eyes. Watching people stumble through tasks would help refine it one step further.

Many hours spent on details and extra features were thrown out the window. It was not all wasted though, it ultimately led to a product.

(Preview videos approximately 30 seconds each)

Learn: This could be a never ending process — finding a stopping point was difficult. The one-on-one user feedback was vital. The more feedback I got and implemented, the better I felt about the product. The evolution from version 1 to version 3 made sense and showed improvement.

Design learning lesson? Again, better documentation. Having a standardized template for each user test would have made the process cleaner and leaner.

Conclusion

The average experience with the organ donation process is brief and infrequent. We arrived to a final product with this in mind. With minimal friction, a user could feel an emotional impact while leaving the site more informed about the topic.

The final product was shown to a real donor registration organization. They were impressed enough to ask about potential freelance work in 2020. I will consider this a success.