Laboratory Specimen Manager User Research & Prototype

The online program to manage patient samples in the hospital laboratory is unnecessarily complex. Although it deals with large amounts of protected information, a quicker, streamlined system is needed so hospital laboratory technicians can instead spend their valuable time on testing samples and treating patients.

To solve this problem I followed the five steps of design thinking to make the changes necessary to develop a user-focused online program to manage laboratory specimens.

I conducted the user research and defined the initial research findings, as well as created the sketches, wireframes, and final prototype. I directed every step of the design process myself for the program to be ready for development.

The Problem

Design Process Overview

I conducted five individual 20-30 minute interviews who were all lab employees. These were either done in person or virtually.

Once I completed these interviews, I organized the findings through affinity mapping to help me group together similar thoughts and feedback, and learn the most repeated and pressing problems. Unsurprisingly, my findings were all related to speed and managing patient samples in a more timely manner.

The three main takeaways I learned from my user research were:

• Scanning barcodes is vital for speed and accuracy. 

• Visual verification makes the entire process easier and is highly desired.

• Locating samples in the program needs to be easy to do.

User Research & Findings

With previous experience in the hospital laboratory, I had first hand experience with the slow storage process. Upon observation, some employees were spending up to ten minutes scanning around one hundred samples into the computer program, something that should only take a maximum of three to five minutes. This is precious time that should be spent testing and reporting patient results.

From my user research and affinity maps I created two distinct personas to guide me with the design moving forward. In the lab these two users work side by side and are regularly communicating; however, they each use the specimen management pretty differently.

Creating User Personas

I used a few different methodologies to know what needed to be designed for a minimum viable project (MVP):

• “How Might We” questions were used to narrow my goal down to: “How might we shorten and simplify the process to store patient samples?” 

• User Story Mapping (shown in the image) to determine which stories were vital for my MVP, and which user stories could be saved for later updates. From this methodology I was able to create the user flows.

• “Jobs to be Done” methodology to focus my goals and to create user stories

User Stories

Design Decisions

Knowing these key user stories, I created user flows so it would help me know what screens needed to be created in my sketches and wireframes. I soon learned that there were many more steps that needed to be included than I previously thought.

User Flows

I hand drew sketches based primarily on the user flows I previously defined. I also made sure to incorporate design decisions in my sketches from the principal insights I learned from my user research. This included creating a virtual rack that users could watch to verify specimen location on their physical rack, as well as including major buttons or links to the three main red routes on the homepage.

Sketches

Taking the sketches, I conducted guerilla usability testing on five different people. Each interview lasted about 15-20 minutes. I gave each person four different tasks to complete and used my sketches as computer screens. 

This testing was very eye opening for me. Up to this point I was very confident in my designs and felt like they would be perfect to use in a hospital lab. But, I quickly learned I had some major problems that needed fixing. These findings include: 

• Symbols in the virtual rack were confusing. 

• Users were unsure what to do on the storage page.

• The user often didn’t know where to start on a page or where to enter information.

Guerilla Usability Testing

I took these findings and made the necessary changes while creating the wireframes for my program. Below are examples of some of those changes I made. Ultimately, creating these wireframes really made all the insights and ideas that I had gathered from my research all come to life.

Wireframes

A key was added to give more information. Added a title to each page and created a clearer visual hierarchy. 

“Search” needed to be changed to “Find” so its purpose would be more clear for users.

Now that I had the skeleton of the program I created the brand, which I ultimately gave the name Labnex. This initial moodboard was the first step in developing the overall feel and personality I wanted my program to have. This changed mildly as the program was developed (ie. I originally spelled it “Labnnex” as seen in my moodboard). My final logo is seen below.

Branding & Moodboard

The moodboard was key in creating the style guide for Labnex. The style guide helped me unify the whole program and keep things simple. The clean rounded font and icons with the primarily blue color help achieve the brand goals of security and simplicity.

Style Guide

At last, the final result of my research and planning could begin to be seen. Combining the style guide with the wireframes helped make the process of creating high fidelity mockups smooth and easy. Using these mockups I created my prototype in Figma to be tested with users. It was exciting to finally see it all come together!

High Fidelity Mockups & Prototype

Testing the Prototype

I recruited another five hospital laboratory employees to test my completed prototype and receive feedback. These tests lasted from 20-30 minutes and were done in person or virtually. I learned each user's initial thoughts upon seeing Labnex, and then gave them four tasks to complete.

I quickly learned what did and did not work with my prototype as a couple users struggled to successfully complete some tasks with the prototype. I then made the necessary changes to make my prototype functional to conduct a second usability test to verify my changes. These problems and the necessary changes I made can be seen below.

First Round of Usability Testing

The “Edit Samples & Racks” secondary button on the homepage was too vague. The settings icon was also unrecognizable.

When locating a stored sample, it was unclear what the time, date and user meant. Users unsure if they needed to select samples to be discarded.

Again, I recruited five more users to test the second version of my prototypes. The format of these usability tests were identical to the first round. In this round of testing each of the users were able to complete all four tasks successfully. By conducting the second round of usability testing, I gained confidence that my prototype was ready.

Second Round of Usability Testing

Click here to view final prototype

My primary goal in creating this prototype was to shorten and simplify the process to store patient samples in the hospital lab. I feel confident knowing that I designed a new program that is focused on not only completing this goal, but equally as focused on the users. 

This prototype is a complete MVP. It allows the user to complete the key processes in managing the thousands of samples  hospital labs get each day. There are some minor changes or updates that could be made in the future, such as adding a feature that alerts users when specimens have expired. This would be helpful, but again, isn’t necessary.

The process to ultimately create a completely functioning and effective prototype was time extensive. Even though I have been a user of a similar type of program in the past, I learned more than I expected regarding what the users actually need in a storage program. Through testing my designs I was able to develop a professional, simple prototype that successfully completed the end goal. Labnex is clear to use and I believe it is ready to be developed into a fully functioning program.

End Results