Transforming a PDF into interactive, online test results.
SUMMARY
SmartGut is a clinical microbiome test that identifies microbes in the gut that are associated with a range of health conditions, from irritable bowel syndrome to diabetes and heart disease. When I was brought into this project, results existed only as a downloadable PDF for patients and their doctors. I was tasked with transforming this static PDF into an immersive, mobile-friendly, online experience.
MY ROLES
Design Lead
Information Architecture
UX Writer
THE STARTING POINT (PDF print out): There’s a lot going on with symbols, color and language here. So much so, that customer service was consistenly swamped with calls from confused patients. The most common complains were, “What does ‘Inversely Associated mean?’ and “All the red is very worrisome. Does this mean I’m really sick?’”
Project kickoff.
+ THE WHY
A believer of early input, I immediately organized a brainstorming and white-boarding session with the CEOs/founders and stakeholders. The first question I wrote on the whiteboard was, “Why more than a PDF?” Because I was new to the company, I wanted to understand what wasn’t working for patients, doctors and the company itself. We generated a long list, and narrowed it down to what we thought were the main pain points (internal and external). We then came up with a simple set of goals for the project, by which to measure our success.
+ DISCUSSING LIMITATIONS
Next, my team met with various department heads to get a holistic view of what was and wasn’t doable in the time we had. Given that we were in series C fundraising mode, most employees were spread thin, wearing many hats, and could not be entirely focused on this one project. Understanding bandwidth and limitations was key, as was constant communication because things were moving and changing rapidly.
+ SETTING UP COMMUNICATION
We committed ourselves to weekly presentations to stakeholders and UX design reviews twice a week with department heads. In each of these meetings, I made a point of revisiting our goals, and we did not introduce visual design (color, iconography, styles) until the very end.
I met separately with engineers to understand how they would be building the new page. We agreed that reusable components were key, and we agreed on a design hand-off process. Throughout the project, design and engineering spoke daily.
+ DEFINING THE PROBLEM
The PDF was not intuitive for patients or their doctors. It was difficult to navigate. The language was geared toward doctors, not patients. The symbols and colors used in the document were confusing and caused anxiety. Patients did not have a clear understanding of what was “wrong,” or of what the next steps should be.
From a business perspective, because the science of the microbiome is in its early stages, we needed a structure that was flexible and easy to update with the latest findings. I learned that the PDF was tedious for engineers to update, and that the website code was outdated. We needed a speedier, more modern way to stay updated.
And, finally, an opportunity: No one else was presenting online clinical microbiome results. We wanted to be the first.
+ Happy mistakes
Early on in the process, during one of our communication calls with department heads, I realized I had mistakenly invited a customer service representative. She was one of the most vocal people in the room, and offered up a goldmine of information about what was and wasn’t working for patients. Until now, customer service had been consistently overlooked in the product development and design process. Here were folks who were listening to actual customers all. day. long. I learned a big lesson here, and am so thankful it came at the beginning of the project.
+ Measuring success
Our measures of success included NPS feedback and scores, customer service complaints, email to website traffic, and number of patients ordering two or more tests.
The process.
+ USER RESEARCH INSIGHTS
First, we performed a competitor analysis. Our lead engineer happened to be a biohacker and had been granted company money to create accounts and receive test results from over a dozen microbiome companies. With his permission, we accessed his various test results, allowing us to garner an understanding of how different companies in the space were explaining and visualizing results to patients.
Next, we gathered as much customer information and feedback as possible (through social media, online sruveys, NPS comments, and database information about our customers). We made two big discoveries:
First, we had assumed that most of our traffic was desktop, since PDFs are typically downloaded and printed out. Not so. We had an unexpectedly high percentage of mobile traffic (over 45%). A lot of people were attempting to view their PDFs on their phones, which was welcome news to us! This reassured us that designing for mobile was as important as ever.
Second, we discovered a new type of user persona. In addition to patients with health conditions, our kits were also being requested by people who were generally curiose about their microbiome. In other words, typically healthy people who wanted to monitor the changes in their gut microbiome, especially around probiotic use. Because we considered this product to be clinica, and because it involved insurance ceoverage, this was an interesting persona to design for. Did we want to accomodate this type of user? Or did we want to somehow push these users to our consumer product, Explorer?
We did a deep analysis of over 12 potential competitors, looking closely at how they explained (linguistically and visually) results to users. Our user research included customer service feedback, NPS and social media comments, email surveys and web stats. This led to a surprise discovery of a new type of persona.
+ Sketching
Armed with our user research, competitor analysis, and understanding around restraints, the team went through an intense series of brainstorms and white-boarding sessions.
We removed ourselves from the office, and rented a workspace nearby with an extremely large table and whiteboard for two half-days.
I printed out a PDF of my test results, cut it into components, and together we played around with different ways of grouping information. We then sketched and cut our our own components for a mobile experience.
LEFT: Cutting up the PDF report to play with different ways of grouping information. RIGHT: Creating our own components to test mobile layout. It’s good to take tactile breaks from the screen.
+ WIREFRAMING & GUT-CHECK TESTING
After several sketching sessions, the next step was to take our ideas and concepts and convert them to tangible use cases.
I use Sketch to wireframe - I find it’s easier to do quick and dirty Invision prototypes this way, and easier to transform Sketch-created wireframesinto visual designs.
We initially chose five different directions, three screens each, to quickly test out in usertesting.com. The results we received reinforced our own hunches and aided us in choosing a single direction to map out. We made clickable and tappable prototypes to show in a stakeholder meeting the following week.
Each stakeholder was sent the Invision mobile prototype directly to their phones, ahead of the meeting. Coming from the agency world, I know there's a big risk in letting decision-makers see too much without a walk-through. But it in this case, I was prepared to handle any fallout, and was pleasantly surprised by how much the mobile prototypes helped to move the conversation forward. The overwhelming response from stakeholders was, "Tapping around on my own phone, I can feel how much more of a reality this is. It's very exciting!"
+ USABILITY TESTING
Once we had sign off from stakeholders, we spiffed up our wireframes, incorporated various feedback, and then set up one-on-one usability tests with eight SmartGut patients. I spent two days visiting various coffee shops to meet with our customers (I prefer a casual atmosphere that is comfortable for the user).
We had barely any budget for usability testing, so we offered free coffee and a $50 Amazon gift card for 30 to 40 minutes of their time. It was surprising how eager customers were to meet with us and give feedback.
Our goal: engage and observe participants in one-on-one sessions, and ask them probing questions as they attempted to navigate the interface to accomplish a series of tasks.
Crucial takeaways: We understood after these sessions how incredibly personal - and scary - test results can be, and how impersonal a computer screen can feel.
Our mantra became: "Empathy-first, then design."
Personalization was deeply important. Once they logged in, we needed to figure out ways to welcome and reassure our customers. Having a first name at the top of the landing page helped users feel more at ease. And filtering and bookmarking were going to be key in giving users more control and personalization over their results.
Providing clear next steps were also key. A common complaint from customers we met with was, "I try to understand what is wrong in the PDF, and then I don't know what to do. Do I call my doctor? My doctor doesn't know anything about the microbiome. I don't think they will believe this science."
And we saw where users got stuck. Language was a big one - we immediately understood we needed to lighten up our science-laden language. We also agreed to hide more information, allowing users to read more if they so choose, but not overwhelming them as soon as they landed on a page. We called this our "digging deeper" tactic. During usability testing, about half of our subjects wanted to read every single thing they could on the page. And the other half wanted to see a simple result, and move on to what to do next.
+ DEFINING THE MVP
...otherwise known as letting go.
Alas, there often comes a moment when the timeline is revisited and it's clear that not all features will make it into the first release.
We had to reduce complexity. Filtering and favoriting - two features that were near and dear to our hearts - would not be included in the MVP.
+ Color palette and visual elements
Because of our pre-existing kits, our color palette was already defined. But since we were moving results online, I chose to enhance the blue color palette with more brightness, to use it as our main CTA color, and to base our designs on dark blue for text and light grays for everything else. Red, yellow and green were used for result indicators, so we needed a very basic palette to support those bright colors, and to make it easy for users to identify results and CTAs immediately.
Specific design challenges.
+ COLOR & DATA VISUALIZATIONS
Problem: Color evokes emotion.
With our new mantra ("Empathy first, then design") we took a close look at how we wanted to use a color, like red, for test results.
Through usability testing (and, frankly, from my own anxiety that arose when I viewed my own test results), we found that red caused much more anxiety than it should. The microbiome and its connection to disease still has a long way to go in scientific studies - it was in appropriate for us to rely heavily on the color red to tell patients that something was out of range.
Ideas we had: We played around with different color palettes. We thought about blue as our CTA color not only for learning more (education) and buying more (marketing), but also for any results that were out of range (blue = what to do next). We tried removing red but keeping yellow and green. We tried using blue (good) and red (bad).
Solution: Our CEO had a strong opinion about how color should be used, so in the end it was a negotiation on both of our ends. I believed red should not be used - at least not for the MVP. I wanted more feedback from customers before going that route.
The final designs used red, but sparingly. On the overview page, I stripped most color from the page, allowing the user to be able to quickly scan for red, green and yellow. On inside pages, where a user may be exploring more information about a single result, I was heavier-handed with our blues.
+ TRACKING OVER TIME
Problem: One of the initial asks for this project was to make sure we showed results over time. The CEO wanted the overview page to feel "unfinished" - like it needed more to be filled in.
Unlike 23andMe DNA smaples, gut microbiome samples change constantly. Depending on lifestyle (working out, eating, traveling), your results from one week can change to the next.
It was a chicken vs. egg problem. Most of our customers had only sampled once. So if we designed for the majority (over 95%) of our users, we would be focused on the one-test experience.
But in order to survive as a company, we needed more regular testing.
Ideas we had: We started off showing a mini graph for each result on the homepage. We worked with engineers to come up with a nice loading animation, watching your results build as the page loaded. But ultimately, from usability results, having so many graphs on the landing page completely overwhelmed the user. it prevented patients from honing in on (a) their latest results and (b) what needed the most attenion.
The solution:
One of the designers on my team came up with the idea of adding a "Trends" section. It was genius. Up until now, we had divided our ux into two main sections:
- Overview (which led to Details Pages for each result)
- Take Action
We adjusted our mocks to now contain a third, top level page: Trends.
Now, when a user landed on results, they could see their most recent results on the overview page, and by scanning the top nav bar, they could see that Trends and Action were just as important.
Within the Trends section, we played with how it would look for a customer with zero, one and multiple results. Depending on how often they tested, we surfaced different CTAs. It was also an opportunity to educate users about how the microbiome changes over time, and thus how important it is to test regularly to create a baseline.
+ REDEFINING THE CUSTOMER BASE
Problem: When we discovered another persona - The Biohacker (someone interested in tracking their results for pleasure, not because of a condition or illness) - we had to make a decision to design for this type of user, or to push this user over to our consumer product, Explorer.
Solution Unfortunately, this was one of those problems that continued to divide leaders within the company. We ended up adding a Probiotics section to SmartGut, in order to provide a way for power users to track how their microbiome was responding to different types of probiotic supplements and foods. We also created a new pipeline in the product, allowing users to "transfer" their clinical results over to Explorer, our consumer product.
I don't believe we came up with the right solution. I would have used this opportunity to explore more marketing messaging - before and DURING the purchase process. In fact, I believe there was an opportunity here to create a brand new product, based solely on probiotics and the gut microbiome.
+ Credibility
Problem: Our science writer was becoming increasingly concerned with the lack of science to back up our claims. Some of the studies we cited were based on rats, not humans. There was even one we found that referenced plants and soil, and we were using this information to make recommendations to our users (who were humans)!
Solution The writer and I brainstormed ways to bring more credibility into our results. The obvious solution was to not include recommendations based on non-human studies. But there was a lot of pushback from data science around this. After all, we made it clear that these results were based on the science of a new and upcoming field.
Our final solution was to attribute a rating system to the recommendations. Our writer worked with data science to determine the number of ratings we should have, and the definitions for each.
We mocked up two designs: One that would be more hidden, within the text of the recommendation. And one that would be surfaced at top level. In usability testing, the hidden version won - it was clear to users what the rating system was for, and how to use it and filter for it.
Next steps.
With this product, we were constantly iterating on our designs. We wanted to grow the product with our users, and with the science.
Our next steps included revisiting filtering and adding in favoriting/bookmarking, both to give users as much control as possible over what they did and did not want to see.
We also started work on a new design for the home page of the platform. For MVP release, as soon as the user logged in they were met with a screen displaying their kit purchase history. In order to find their latest results, they had to use top navigation to get to the “results” section of the site. Our new landing page pulled in data from the results overview. We mocked up a few variations based on customer paths, with plans to do a round of usability testing.
Finally, we started working on a plan to incorporate mini surveys into results. Our MVP had a “Surveys” section in the top nav bar, but traffic to that page was spars. Our surveys were long, with anywhere from 12 to 30 questions each. We wanted to pull specific and relevant questions out of the page, and embed them into results.
Some reflections.
I was incredibly proud of my team for a solid MVP delivery. Although it was painful to let go of features as we defined the MVP, we had gathered enough data and designs to begin building a solid roadmap five months out.
Our component library and style guide successfully incorporated the designs for two more clinical products following this one. We were able to work with engineers to refine and push designs with each release and each product. Starting with simplicity for this project really paid off in the long run.
We did not having the time or money to do proper usability testing. We made too many assumptions in our designs, and at times it seemed we were designing more for the uBiome scientists and C-Suite, than for the patients actually using our product.
Doing data visualization design without understanding data can be particularly rewarding (although I wouldn’t blindly recommend it). In my case, I used design to understand the data visualizations. I worked closely with scientists, interpreting what they said into my own “pictures.” It became a language between us. I would stop them and say, “Is this what you mean?” - showing them a sketch I had just drawn up. I became more confident in my designs through this process, because I knew I was ultimately designing for people just like me. I needed to simplify the data, and to present it in small, digestible pieces.
Too much time was spent designing to show why an idea would not work. This changed later on in the project, as I gained more trust among stakeholders. It can be tough to be a solo designer surrounded by scientists!
About two-thirds of the way through the project we remembered to revisit the PDF. Our product was remarkably better than the PDF results, yet we still needed to find a way for doctors to use the PDF to follow along. The result? We headed back to the drawing board for the PDF, and this time the SmartGut platform was informing the PDF redesign!