Clinicly: A Responsive Medical Booking Website

Role
UX Designer
Researcher
Branding

Project Duration
8 weeks
(20 hrs/wk)
Per DesignLab Timeline

tools
Figma
Optimal Sort
Coolors

Overview

Background

The process of finding and booking appointments with healthcare providers can present particular challenges for users seeking an easy, convenient and simple process that centers the patient instead of the provider. Users can become overwhelmed by the multitude of substeps needed to navigate each of these processes respectively. This can be especially frustrating for users who are sick and/or in need of medical attention sooner rather than later.

The Problem

Users can particularly feel disconnected from their doctors when they leave appointments and navigating messy and exhausting websites booking appointments and/or figure out how to contact their provider can influence them to avoid seeing their providers altogether.

The Solution

Through a survey, competitive analysis, secondary research and user interviews, I uncovered a surprising insight about users who seek to connect with medical providers on booking websites. While I hypothesized that solving usability issues with regards to the flow of booking appointments would increase booking, I actually found the issue connectedness to providers to be a pervasive issue in a user’s experience of healthcare.

Thus I created Clinicly, a responsive website, aimed at allowing users to not only schedule appointments, but also connect users with providers and serve as a mode of communication as well between users and providers.

View Final Prototype

* * * * *

Discover

Survey

At the beginning of this project, I knew I wanted to focus on a problem related to healthcare, but I was not sure whether I wanted to focus on issues related to preventative care or issues related to users visiting healthcare professionals. I used the survey to learn more about the kinds of challenges users were facing with respect to these aspects of healthcare, ultimately so I could zoom in on a particular aspect. There was definitely overlap in the kinds of issues users faced with regard to both aspects but I found more of a range of issues under the topic of visiting healthcare professionals. Not only were users indicating issues with navigating booking sites, but they were also having issues finding providers, completing intake and communicating with providers among other things.

Users actually indicated by far more provider-facing issues and missing features rather than usability issues with sites used to book appointments, when asked to indicate issues they had experienced.

" The portal I use for my psychiatrist has limited functionality. I can’t cancel or reschedule appointments online, it can only be done by phone. This is frustrating because other sites do have this functionality and I feel that it helps patients stay on top of their appointments and provides more flexibility. "

" Normally my specialists won’t have the calendars available online, so I always have to call to make an appointment. "

Literature Review

In order to learn more about the context and scope of medical scheduling, I conducted a quick Google search. I learned that medical scheduling websites date back to the early 2000s and sought to connect users with information that would help them make informed decisions about medical providers. The predecessor of these services were a multitude of privately healthcare software systems, like Epic Systems (which hosts MyChart) that focused more on issues related to the provider-side of healthcare (e.g. patient registration, bill systems for insurers, etc.)

Competitive Analysis

I also wanted to learn about websites that were already providing these services. I examined the strengths, weaknesses, opportunities and threats that existed on the sites of 4 direct competitors for healthcare databases/marketplaces: Real Self, Healthgrades, Vitals and ZocDoc.

I gleaned 4 insights from examining these competitors:

View Competitive Analysis

User Interviews

I constructed a interview protocol that would allow me to learn more not just about their issues with booking medical appointment, but their motivations and goals as well. I picked 5 potential users to interview from those who indicated they were interested in participating on the survey. The users consisted of men and women, of various racial and ethnic backgrounds between the ages of 26 and 61 enabling me to have a wide range of perspectives. I recorded each interview on Zoom and took notes.

Summary of Discovery Stage

During the Discover stage, I put together and executed a research plan incorporating the following elements:

A literature review about the evolution of medical scheduling websites from earlier healthcare software systems
A survey that allowed me to narrow the scope of my problem toward the issues users faced as they visited healthcare providers
A competitive analysis enabled me to understand the key features the solution would need: search functionality, filter search results functionality, profile pages for each provider based on the websites of ZocDoc, Healthgrades, Vitals and RealSelf.
User interviews allowed me to dig deeper into how users were experiencing visiting healthcare professionals

* * * * *

Define

Affinity Map

Following the observational study, I created an affinity map with the data. I found 4 key themes:

I was really struck by the ways that users were deciding to directly contact via phone or not to contact their providers at all when they wanted or needed to be seen.

" Last time I didn’t even tell my primary care physician that I was experiencing pain... I just figured it out. Once you leave the office, you cannot call and speak to them directly. "

" It’s kind of a pain to call them especially when I’m sick. But sometimes its necessary because of the issues I’ve had with booking online. "

View Affinity Map

Problem Statement

Initially, I hypothesized that users would experience issues related to scheduling, limited functionality/poorly formatted platforms, inaccurate provider details, lack of ability to find providers based on specific needs. Taking into consideration that I couldn’t solve for some of the issues that were related to providers, I decided to explore ways to help users with longstanding relationships with healthcare providers to feel more connected to their providers because they feel disconnected once they leave the provider and feel like they to take their health into their own hands.

This prompted me to focus on how my responsive site could serve as a communication platform and allow users to communicate with providers directly as a way to positively affect the connectedness users feel with their providers. The problem of how we might increase the communication and transference of information between patients and providers tackled this.

Personas

Thus I generated 2 personas that diverged in terms of their motivation for communicating with their healthcare provider, their goals for seeing their healthcare provider and their pain points.

Summary of Define Stage

During the Define stage, I defined the problem I needed to solve for with the use of the following elements:

An affinity map with the key themes from the user interviews: convenience, connectedness, information access, structural limitations
I selected a HWM question focusing on increasing the communication and transference of information between patients and providers to positively affect the connectedness users feel with their providers
I also generated 2 personas that diverged in terms of their motivation for communicating with their healthcare provider, their goals for seeing their healthcare provider and their pain points

* * * * *

Design

Storyboard

In order to better understand how users would engage with the solution I developed, I created a storyboard, pictured below, to show how a user would use the CLINICLY website to meet their needs.

Feature Roadmap

In building the feature roadmap I focused on the features that would have the most impact on a user’s ability to connect with their provider virtually and in person through booking an appointment.

While coming up with ideas of potential features using the creative constraints and the analogous inspiration strategies, I consulted my competitive analysis. The following features that were present in all the websites I examined were prioritized as must-haves:

Thus, I deprioritized additional portal features such as allowing information to be shared across medical organization, a Telehealth portal for users to have Telehealth visits and a feature matching users with new providers based on their preferences.

View Feature Roadmap

Card Sort

I conducted a card sort using Optimal Sort in order to learn from users how they thought content should be organized. I reached out to the 5 users who I had conducted user interviews with and heard back from 3 of them. The card sort was closed with 30 cards and 6 categories for the different sections of the website: Patient Account Portal, Provider Account Portal, Provider Profiles, Informational Articles, Search for Provider and Provider Search Results

I’ve included the matrix of popular placements from the card sort.

Site Map

I created a site map in order to organize all the content on the website and eventually help me understand the user’s journey. The site map which I’ve included below incorporates the all of the must haves and one feature on the nice to have category. I also zoomed in on the particular flow I was designing screens for which would allow users to send a message to past providers.

User Flows and Task Flows

The user flow I focused on traces the the user’s journey from when they log in to when they send a message to their provider. This is included below. I chose this over a flow based around booking an appointment so that I could zoom in more on how users were communicating with their providers.

The related task flows involved users logging in, sending a message and viewing a sent message.

View User Flows and Task Flows

Designing the Patient Portal

The patient portal homepage was a key screen that I sketched and translated into mid fidelity and then high fidelity wire frames. With the personas in mind, I considered the context that users would typically be accessing this website either on their phone or computers so I prioritized those screens. For the patient portal in particular, I wanted this screen to be very learnable and memorable allowing users both to understand the overall information hierarchy easily and be able to do this without fail however frequently they logged. So I made the decision to focus on buttons for the major actions that users needed to complete in the context that they needed make decision or take action regarding their health. I eventually these buttons evolved into cards that contained helper text and icons. I thought that it would be simple to adjust these cards into the desktop screen since I was using a mobile-first approach.

Designing the Messaging Provider Experience

The other set of key screens were the screens that were apart of the the user flow for messaging a provider. Again, I wanted to consider what was learnable and memorable in terms of users learning how to navigate through the screens. But I also wanted to make sure users weren’t overwhelmed by this process and thus, I mimicked MyChart’s organization of this flow that gave each step a unique screen. I eventually incorporated a go back button for each screen as visualized below in order to give the user more control over their actions and allow them to recover from an potential errors. I also incorporated clearer helper text to guide user’s actions. mimicked MyChart’s flow for messaging a provider, also allowing users to indicate the type of message and specific provider they would like to contact.

Branding

I thought it was important to create a brand that put users at ease who might be sick and/or in distress when they are navigating the website. Thus I was drawn to a really light blue with a orange contrast color for highlights. I presented three different logos I had sketched to other designers and received feedback that one logo in particular looked seemed to fit the overall vibe in my style tile. The following words were used:

This was the exact vibe I was aiming for and so I decided to move forward. I continued to experiment with the thickness of the lines to make sure logo was actually readable as it scaled to different sizes. For consistency, I incorporated components that were equally as simple and clean typically using black against a light background for a level contrast and accessibility. I was able to check for contrast using the Coloors contrast checker online.

Component Design

For the button design, I made sure there was enough padding around the text. It was important to make sure the text size was large enough for readability and that the text was bold and all caps. I chose the blue for the button to create a sense of calm on the different screens. I also opted for a rectangular shape with a slight curve on on the corners for the primary button. It was important to prove enough padding around the buttons label. I put the label in the body font type and size, but all caps to make it stand out and still be readable. I used similar specs for all buttons and adjusted them for the mobile version as well in order to create overall consistency and similarity throughout the component design.

View UI Library

Usability Testing

Once I had finished creating a prototype for the sending a message flow, I began usability testing. I used the same 5 users who I had conducted user interviews with for the usability testing.

The goal was to determine if the flow was intuitive to the user given the task of messaging a provider.

Users testing the website needed to log in, sending a new message to their provider and view their sent message. As a designer, I was concerned with how intuitive and simple the flow was and whether it was what users expected to experience. My quantitative success metrics were the task completion rate and the user rating of difficulty (1 to 5, with 5 being the most challenging). My qualitative success metrics were user’s feedback on their experience with the website.

Feedback Prioritization

All users were able to successfully send a message to their provider. Users also rated the task as relatively easy to complete.

After sorting the user feedback, I rated it by severity to the user’s journey considering what might impact the user’s ability to message their provider.

I found that issues related to making portal home screen and the message center screen to be most severe as users indicated that it was not very intuitive what actions they could take on these screens.

" It’s definitely my instinct to click on the menu. In fact, I would prefer to click on menu to see all my options rather than having to scroll through this page or explore the website. "

" If I am sick, I would want to be able to get into contact with my provider as quickly as possible once logged in. "

View Afinity Map

Priority Revisions

I focused my iterations on the portal home screen and the message center screen and how I could make the user actions more intuitive.

I reworked the portal page view to emphasize the hamburger menu which holds all user actions rather than the cards on the portal page. The approach of centralizing the hamburger menu allows for progressive disclosure, rather than overwhelming users with a number of various actions. I also incorporated a dashboard and provided actions tied to each provider for the user.

I moved the buttons closer to the top of the screen so that users could make decisions about what they wanted to do on this screen without having to scroll. By moving the actions to the top of the screen, I created a better information hierarchy for users clicking on this screen.

Summary of the Design Stage

During the Design stage, I designed and tested the website making important considerations about the following elements as I increased the fidelity of my designs:

I created a storyboard in order to put the user and the website within the context that users would be using the website particularly when they are sick and need quick access to providers
I created a feature roadmap that prioritized patient-facing features (portal, directory and messaging) while deprioritizing other features
I conducted a card sort to help me make important decisions about the content hierarchy on the site such as allowing users multiple routes to the same destination
I designed a site map divided into the portal, the provider directory and the search page
I designed user flows focused primarily on users messaging providers
I designed a portal screen and screen for messaging providers focusing on learnability and memorability for users as I increased fidelity
I designed a brand system that would put users at ease and created components that were consistent
I tested a prototype to see how easy it was for users to message their providers
I prioritized feedback that improved the information hierarchy through the use of the hamburger menu and moved buttons to the top of the screen

* * * * *

Deliver

Final Design

My design for the final prototype, included below, incorporated redesigned screens for the portal home and the message center.

Next Steps

Based on the feedback, I could iterate next on the log in screen and the individual message page. The feedback I received for these screens included providing an alternative way for user to log in so they don't have to remember password (e.g. one time code), adding labels for the log in screen, and adding message status for sent messages. The one time code reduces potential user errors when typing in their email and password while the message view screen provides user feedback about their action. I’ve included screens for what these iterations could look like.

After these quick wins, I would return and start to build out the remaining key features that I deprioritized such as additional portal features, features that live outside the patient portal and eventually a provider facing portal with provider-facing features.

Summary of Delivery Stage

During the Deliver stage, I wrapped up the design process with the following elements:

A final prototype with redesigned screens for the message home and the portal home
Proposed screens for quick win iterations focused on limiting user errors and providing users with feedback as well as considerations of prioritizing later features

* * * * *

Conclusion

This project showed me the power of user research to drive your definition of the problem you are trying to solve for. It was important for me to reflect on my initial hypothesis and be able to move in whatever direction the research indicated. This required me to be nimble, but I was also able to learn so much about users’ experience of healthcare today. This project definitely inspired me to think big about designing solutions that transform the healthcare industry in ways that positively impact patients. A major limitation for the project was that I only had access to patient users. That said, I would need to conduct more research in order to define the problems and solutions that are provider-facing.