Blood test app concept

Filed under: apps, interaction design, user experience / product design, visual / UI design

As a design exercise to exemplify my product design background, I’ve outlined a typical work flow for creating a product from scratch. A design brief may look something like this:

Let’s say you just took a blood test as part of a routine check-up. The lab actually has a mobile app for you to visualize the results. How would you design that app? What type of information would you show? How would it be organized?

This post outlines my usual workflow from conception up until the first design review, essentially building up to a minimum viable product that suitable enough for testing & feedback.

Initial concepts on the whiteboard

Before starting any visuals, the first ideas are written through words on the whiteboard.

Initial whiteboard session

I usually break down my thoughts & explorations into three sections:

Goals

Reviewing the project requirements, I parse out the goals for the exercise in clear bullet points. The goal of the exercise is achieved if I can attain everything on this list. Other goals are added that would help make the product a more pleasant experience:

  • Design an app to show blood test results for routine check-ups
  • Prevent anxiety associated with medical tests
  • Carte blanche on features & platform

Considerations

A big bulk of my brain dump is compiled in this list. This is my list of don’t-forgets & wouldn’t-it-be-nice-if type suggestions. The idea here is trying not to list solutions, but merely list problems so I don’t pigeonhole myself into a solution.

  • Organization is paramount with a small screen
  • Patients are apprehensive when it comes to medical test results; need to be sensitive with messaging
  • Educate users by explaining different parts of the test
  • I’m designing the experience after the blood has been given & submitted to the lab
  • Create a way to show the progress of the blood processing by the lab; provide a way to communicate with the lab in case of delays
  • Data visualization to show patient’s numbers within healthy range
  • History can show progression of health
  • Provide suggestions for follow-up actions
  • Patients will use the app, so avoid technical jargon
  • Can be used to track prescription info
  • Tests will differ between men & women, age
  • The word positive doesn’t necessarily mean good; avoid the word & show it visually
  • False-positive test results may require retesting for a more accurate result
  • Need to list name of lab in case user wants to have a retest done elsewhere
  • General blood test results:
    • Total Cholesterol Category
    • LDL (bad) Cholesterol Category; less is better
    • HDL (good) Cholesterol Category (heart disease); higher is better
    • Blood Glucose (diabetes)
    • Complete Blood Count (normal levels per gender)
    • blood type
  • Can opt for further testing if the patient needs more detail:
    • genetic testing
    • thyroid
    • ELISA test
    • Chromosome testing (genetic abnormalities)
    • Liver function
    • Ichor is the ethereal golden fluid that is the blood of the gods and/or immortals

Questions

I took the liberty of making assumptions here so I’ve provided answers to these open questions. However, I generally will reach out to the stakeholders get these questions clarified as it would affect my final solution.

  • Is the app only for blood test results, or will it be expandable to other types of medical tests?
  • Will this also be a platform for payment information for lab fees?
  • Do we have any analytics that show if there are a majority of Android users vs iOS?
  • Is there an existing user persona I should build around?

Product design template

A habit I picked up when creating a new product. In a few cases—such as this one—are some of the steps non-essential, but it helps me go through the motions of making sure I don’t miss anything. In this case, it reminded me to look up any other competitors to see if they’re suffering from any pain points.

The five questions to answer in designing any new product.

Product design template

User persona

I made assumptions & created a believable persona for a person who would be using this app. As mentioned above, I would clarify with the stakeholders to see if a persona has already been built, or if existing data exists that can support the creation of one. This will help me place myself in the mindset of a typical user.

An outline of a typical user:

  • male, early 30s
  • reminded by his wife to go for an annual physical which includes a blood test
  • exercises a few times a week
  • enjoys eating at restaurants
  • is a techie; has a smartphone & tablet
  • nervous about medical tests because he’s at the age where health risks increase

Use case dialogs

In conjunction with the user persona, an exercise that helps me catch edge cases is to write out a dialog between the user (patient) & the app. The user (patient) would ask a question, then the app would reply as a customer service agent. This helps me be more empathetic to the user as I’m using human language to converse. I would use these scripts as a guide to what screens I would need to create.

Patient: I would like to see my blood test results from my routine check-up a few days ago. (Test results are available.)
App: Here are your test results. The test is pretty technical, but we’ve simplified the results for you & clearly laid out some actions to follow.
Some of these results sounds scary. How can I improve my numbers?
We can suggest some further actions to help you improve. We can also check in with you to see if you’re following up.


I took a blood test a few days ago & am anxious to see the results. (Results not yet ready.)
We’re sorry, but your results are not yet ready. we can show you where we are in the process.
It looks like the results are stalled. Is there a way where I can prompt the lab for more feedback?
We can inquire about your lab results & can reply back with their response.


I would like to revisit my blood test results from past routine check-ups.
Sure. We provide historical data so you can see any trends in your numbers. We can also highlight any improving trends, or show a part of your numbers that can be improved.
Some of these numbers look outdated.
Let’s schedule you for a return check-up. It’s been about a year since your last visit. We have a few available times for you to choose.


I would like to learn about my blood test results from my routine check-up a few days ago.
Sure. Let us know which part of your test you would like to learn about and we can pull up more information.
This one says that i may be at risk of anemia, which can either mean internal bleeding or a poor diet.
Thanks for pointing this out. We’ll reach out to your doctor & get back to you to let you know anymore details regarding this. We’ll keep you in the loop with our progress.

Information architecture

With the above information, I can create a list of essential screens. I cross-checked my notes & use case dialogs & listed out all the screens & consolidated some if needed.

The information architecture of the essential screens.

 

IA diagram

Click prototype

At this point, I usually begin sketching some screens for storyboards, but with the time restraint, I omitted this step & created a very rough click prototype with my notebook sketches. With InVision, I was able to create a nine screen prototype that outlines some top-level user journeys.

Initial sketches in my notebook.

notebook sketched wireframes

Taking an extra hour, I converted these sketches & made a higher fidelity version through Illustrator, which makes the UI elements clearer to understand.

The click prototype uses these screens instead.

Click prototype on InVision

A working click prototype can be found here or by clicking the image above.

With the above prototype, we can fulfill some common user flows that were outlined in the above use case dialogs, example here:

  1. User gets a push notification that the results are in.
  2. They will see the overview screen.
  3. Tap on the main section to see more details about the test results.

Or if the user wants to change labs because they want a second opinion:

  1. The user enters the details screen, but doesn’t like what they see.
  2. At the bottom of the screen is a link to view lab info.
  3. They’re brought to the Processing view, Lab tab.
  4. From there, they can browse & choose a new lab.

Visual design

I managed to leave some time at the end to create at least one screen in high-fidelity to show the app’s mood & visual hierarchy. I went into Photoshop & created custom assets in these mockups.

The app’s icon

Ichor app icon

 

High-fidelity mockup

 

Main menu

Details screen

 

 

What’s left

Trying to keep within strict time restraints, I’ve created everything up to the point to where a design critique is held with the stakeholders for feedback. The steps leading up to final approval where my design gets handed off to engineering for development are as follows:

  1. Design critique (making sure stakeholders & teammates only provide feedback from the persona’s point of view)
  2. Create functional specs through a PDF document, quick redline document, or team wiki
  3. Hand off to development
  4. Engineering comes back to me for feedback; either return feedback verbally or through redline document if engineering is remote

Time breakdown

Initial whiteboard concepting: 2 hours
Building out use case dialogs: 0.5 hours
Creating information architecture diagram: 0.5 hours
Sketching, building click prototype: 2 hours
Visual design, high-fidelity mockup: 0.5 hours
Writing this blogpost: 0.5 hours
Total time: 6 hours