Blood Bank Questionnaire UI – Part 2

In Part 1, I explored issues and possible improvements to the blood bank’s questionnaire interface for each question. In this part, I’ll look at the end screen of the process.

screen shot of the questionnaire's end screen that asks the user to review the answers to all questions
Questionnaire end screen UI

The glaring issue with this screen is that it requires the user to remember each question based on a short, obviously programmer-named description like “BLD TRANSFUSION”. I question the need to review a dump of all the questions and answers. The progressive nature of the questionnaire and the ability to jump back and forth between questions provides the user adequate opportunity to review and change answers.

Design Possibilities

  1. Determine how necessary this end screen really is. How often do people use it? How often do users go back and change answers at the end? If it’s very low, get rid of it.
  2. Rather than show all questions, maybe show only those questions users skipped and give them another chance to answer.

    end screen mock up that asks users if they would like to answer any questions skipped during the questionnaire
    Skipped questions UI
  3. Change the format of the questionnaire to show multiple questions at a time, and progress through only a few screens where questions are grouped together by type. For example, travel, sexual activity, and disease exposure.

    questionnaire screen with 4 questions in a Current Health section
    Questionnaire section UI

Blood Bank Questionnaire UI – Part 1

I’m a regular blood donor so I must have used this self-administered questionnaire UI dozens of times over the years. It’s old, clunky, and suffers from providing the bear minimum in functionality with little thought to usability.

Screen shot of the self questionnaire interface
Screen shot of the self questionnaire interface

Top issues

  1. Using check boxes for the answer responses when only one choice is allowed (yes, no, or skip). My best guess about why they used check boxes instead of radio buttons is to allow a user to remove any response to the question.
  2. Placing the “Continue” button at the bottom of the page, far away from the answer check boxes. This results in having to move the mouse up and down, over and over, for every question.
  3. No indication of how many questions there are or which question you’re on.
  4. No integration of the educational materials within the interface. If you want to know which European countries are on the travel list, you have to consult a paper print out.
  5. It’s ugly and does not provide a very friendly experience.

Design Recommendations

Here’s a mock up I did that attempts to address the top issues.

Screen shot of a new mock up of the questionnaire UI
My mock up of the questionnaire UI
  1. Use radio buttons for the answer responses (yes and no) and move the “skip” option to a link that does not give the “skip” option the same visual weight as “yes” or “no.”
  2. Change the “Continue” button to “Next” and place it next to the radio buttons to minimize the effort of answering the question and moving on to the next one.
  3. Add a status bar for a quick visual of how far along you are in the questions, and indicate which question you’re on, e.g. 15 of 28.
  4. Add links to the educational materials within the interface.
  5. Update the look and feel. Use the blood bank’s logo and color palette instead of the software maker’s.

And here is what the interface looks like once the user selects an answer.

Screen shot of the updated UI with the "no" radio button checked
UI updated with a checked response

The user no longer has the option to clear a response. Maybe clicking “skip question” would clear the radio button? But since a user must answer all questions eventually, either in the software or verbally to a tech, I don’t see the ability to clear a response in the UI as very important.

On Infinite Scroll

Infinite scroll can definitely be useful. This is what you see on sites like Twitter where more results load as you get to the bottom of the page content. This asynchronous behavior helps moderate page load times by requesting more data as needed.

What doesn’t always work with infinite scroll is a footer. I was on a site where I was trying to read its “about us” statement, linked in the footer, but could never click on it since the page had infinite scroll.

screen shot of a webpage with the message "loading next set of posts" above a footer
Infinite scroll with a footer

As hard as I tried, I could not click the “Read more…” link. Even getting the screen shot took some ninja tricks.

Design Recommendations

  1. Don’t have a footer. Is it really necessary? I eventually found a link to the “About” page in the global navigation menu.
  2. Have a “sticky” footer. This could work like sticky headers do, where if you’re scrolling down the page it gets smaller or even hidden, then if you scroll back up, it shows again.
  3. Instead of loading more posts automatically, provide the user with a link to manually load more instead.

What’s the right solution? That comes down to testing and finding out what the site’s typical visitors expect. I’d opt for no footer on this page.