Blue Shield of California wanted to offer users an alternative to traditional in-office doctor visits.
I successfully led a team that integrated a telehealth option into the Blue Shield "Find a Doctor" tool resulting in increased user adoption.
My role was as a UX Design Lead managing the work of a UX Designer, a Visual Designer and a UX Researcher.
Additionally, we partnered with a UX Researcher and several Product Owners encompassing a timeframe of just over two months.
Challenge
Blue Shield of California was seeking a way to increase member engagement and offer users an alternative to traditional in-office doctor visits.
As part of an initiative to enhance the Member experience, Blue Shield launched a program to offer virtual doctor visits to its membership, specifically in the area of telehealth solutions. This enhancement was driven by both cost savings (as a result of reduced visits to physical offices and clinics) as well as benefiting members by providing an option that offered more immediate access to care.
A Plan to Get There
The project consisted of integrating the Teladoc option via the Find a Doctor (FAD) tool. Users typically use the FAD tool to search for a doctor to schedule an in‑person office visit. It was determined this was an ideal moment to inform and educate them that a telehealth benefit was now available as an alternative.
Our Work is Already Done?
It was interesting to note (but not entirely surprising) Product Managers had spent considerable time crafting a solution for this initiative. Because of this approach, the project—and subsequent solution—were presented to us in a very prescriptive manner.
As a result of this preliminary work, they eagerly shared with us rough mock‑ups and annotated screens depicting how they felt the solution should be implemented. This action presented a challenge to the team, but eventually came to be accepted in the spirit in which it was intended. We conversed with Product Managers to understand more of their thinking and how they arrived at this prescriptive solution.
As the conversations unfolded, we continued to listen more deeply and further collaborated with Product Managers. We offered to conduct more in-depth research and discovery to ensure the business objectives were met, and users' needs were addressed.
Leadership Highlight
Some team members were dissatisfied Product Managers had provided a prescriptive solution before the UX work had begun. I urged the team to explore the intent behind the action and encouraged them to use this as an opportunity to partner. I later sponsored meetings with Product Managers that allowed us to work collaboratively toward a better solution.
Research
Discover
Given the prescriptive nature of the solution presented to us, we knew immediately we wanted to perform research — we were not trying to insinuate the Product Owners were wrong in their approach — we simply wanted more information and insight to help guide us.
We knew research held the key to unlocking these insights. Working with our UX researcher, we created a plan for how we would research and investigate beyond the options shown on the annotated screens and mockups provided to us at the outset.
The Obvious Place to Start
As part of the initial discovery phase we began to explore the efficacy and feasibility of the solutions presented. It was at this time we began to realize our initial foray into discovery led us to believe the user needs and business objectives would likely not be met with this initial prescriptive solution.
Several quick rounds of Guerrilla testing revealed our suspicion was correct. The prescriptive solution was met with confusion and ranked poorly with our test subjects. It was at this time we realized the user needs and business objectives would almost certainly not be achieved with this solution.
The prescriptive solution showing the various options for Teladoc messaging on the FAD tool.
Refocusing Our Efforts
It was at this point we sought to better understand business objectives and user needs and how we might achieve balance between them. We remained mindful of the following considerations:
User considerations
To be able to understand there is an alternative to a traditional doctor visit
To be able to easily procure timely access to a certified caregiver
To be able to securely access the telehealth option – Teladoc
Business considerations
To remain within mandated compliance
To be able to satisfy product performance objectives
To be able to meet scheduling objectives
To fall within budgetary constraints
Technical considerations
To remain within the bounds of technical feasibility
To avoid violating security protocols – specifically with the vendor engagements
Design–Test–Build
Define
In conjunction with user research, we summarized user feedback and synthesized it along with user data and analytics. As a Telehealth option (Teladoc) had only recently been deployed, we had some limited baseline data to reference.
We were now more aware of several aspects of user behavior. While members who used the Teladoc option rated the experience highly, it was also revealed many members were not using the service because they did not know it was an available option. Because of this revelation, user awareness (specifically discoverability and findability) took on more importance as we looked at revisions to the initial design.
Establishing an Alternative
With a dual focus on education and access to the Teladoc option, we embarked on an exercise to offer alternative design solutions we felt would better achieve the stated objectives. It was this approach that informed our next steps in the process.
Researching alternative approaches for Teladoc messaging on the FAD tool.
Design–Test–Build
Design
After completing the Research phase of the process, we embarked on the next phase. It was at this time design solutions were explored iteratively. Once completed, more detailed user feedback was sought via user testing.
Alternative layouts were created, refined and presented to people to begin selecting the most promising approach. This provided an opportunity to validate the new design concepts.
When and where to inform the users
It was predetermined from the project scope, the entry point for the Teladoc option was to be via the FAD tool. We quickly documented the relevant user flows to better determine where and when to present the Teladoc information to users.
User flows to determine where to present the Teladoc information to users.
Mock‑Ups – Iteration 01
We initially decided on design concepts that would intercept users at the very beginning of the FAD flow. The objective was to create a decision fork screen at the outset of the Find a Doctor process steps. Users would be presented with a choice to pursue either a telehealth option (Teladoc) or a more traditional in-person doctor visit, and then proceed down the chosen path to complete the remaining steps.
Exploring initial design concepts that show options for intercepting users at the very beginning of the FAD flow.
User Testing – Iteration 01
Several in-person testing sessions were performed. A questionnaire was completed as well as capturing extemporaneous feedback and impressions of the various layouts. While users did express a preference for a particular layout, none of the layouts we presented tested well for awareness, thus limiting the effectiveness of the CTA. Many felt confused by the two options available to them. CTA buttons were well received, but users were unclear about what next steps to take on the page. Some users commented there was too much copy on the page, while others felt the amount of copy was appropriate and found it useful.
User testing set up and session notes for the FAD decision fork screen.
Unknown to us at the time, this seemingly insignificant feedback—regarding the amount of copy on the page—would serve to unlock a critical insight in our pursuit of a better solution and would ultimately trigger a new way of thinking.
Specify
Deliver
Information gained from initial rounds of design and testing allowed us to continue to move the solution forward.
We refined the designs and created a second round of iterations as we prepared for another session of user testing.
Mock‑Ups – Iteration 02
As increased awareness of Teladoc was a critical business objective, we focused on addressing feedback in this area. We began to reconsider our approach of introducing the decision fork at the beginning of the FAD process flow.
User flow diagram depicting placement of the decision fork screen deeper in the FAD flow.
As we investigated other options, we pivoted and decided to place the decision fork screen deeper into the FAD process flow. Users could begin the process of a FAD search and then resolve the decision fork when it made more contextual sense to do so. As a result of this new approach, we modified the design layouts for a second round of user testing.
Revised high–fidelity mock–ups for the FAD decision fork screen.
User Testing – Iteration 02
To test the modified layouts, more in-person testing sessions were performed. User comments were captured, analyzed and compared against previous results. Overall, the modified layouts tested favorably as a clearer design direction began to emerge. Feedback indicated awareness had increased, and the CTA was determined to be more actionable. No consensus was established regarding positioning of the CTA button in the layout. Questions still persisted around amount of copy with some users declaring there was too much copy and others indicating the amount of copy was acceptable.
User testing summary results for the FAD decision fork screen.
Leadership Highlight
After many design iterations, the team still lacked confidence in recommending a solution. We had clarity on the direction of the layout, but felt the overall design was still lacking. I challenged the team to redouble their efforts and not give up. I proposed they explore, in depth, the issues they felt limited confidence. It was through this focused effort that a breakthrough was realized.
The Framework
A Solution for All Users?
Up to this point, using our process, we had been able to answer many questions regarding the proposed designs. Yet, there were still issues we had not fully resolved. We found ourselves at a bit of an impasse. While we had favorable feedback related to user awareness, we still lacked consensus on the correct amount of copy and CTA button placement in the layout.
Despite previous rounds of user testing, we still lacked confidence recommending a solution. We had more clarity on the direction of the layout, but felt the overall design was still insufficient. We decided to obtain more data to help establish an even more confidence-inspiring design solution. It was then that we posited the idea...
Is it possible to create a solution that would resonate favorably with ALL users?
Revised high–fidelity mock–ups showing layout variations for the FAD decision fork screen.
To answer this question, we turned our attention to a relatively minor bit of feedback that kept coming back. It was the feedback regarding the amount of copy in the layout. We could not seem to create a satisfactory solution to resolve this issue which led us to rethink our approach and look to the D.I.S.C. Behavioral Model for inspiration!
The four elements of the D.I.S.C. Behavioral Model and their corresponding attributes.
The D.I.S.C. Behavioral model is a theory that relies primarily on an assessment model to determine to what degree a person expresses the four different personality traits:
[D] Dominance, [I] Interactiveness, [S] Supportiveness, [C] Conscientiousness.
Understanding these four distinct behavior characteristics can help inform product design by facilitating the creation of features and workflows that satisfy all four personality traits – allowing designers to achieve the objective of crafting great experiences for ALL users.
A Helpful Exercise
With this framework in mind, we embarked on a mapping exercise to determine if we could map elements in the preferred layout to the corresponding quadrants in the D.I.S.C. model.
The FAD decision fork screen with highlighted D.I.S.C. mappings.
As it turns out, we were somewhat more intuitive with our design than we realized. Mapping the elements aligned in a favorable manner with the four individual quadrants in the behavior model. How the design elements aligned with the D.I.S.C. model was a very exciting development. We were keenly interested to know how this approach would resonate with users. Inspired, we pressed on, determined to see if we could establish a design that would rate favorably with all users.
The design elements mapped to the corresponding D.I.S.C. categories.
User Testing – Iteration 03
With the D.I.S.C. mapping in place, we created another set of design revisions with this framework in mind and conducted an additional round of user testing. We were seeking to understand the preferred order of the mapped elements, as well as determining where best to place the CTA button.
Exploring layout options for ordering of the mapped D.I.S.C. elements on the FAD decision fork screen.
After testing several design layouts with users, we eventually arrived at what, in hindsight, seemed obvious from the outset – the hierarchy of the mapped elements would (vertically) follow the natural ordering of the D.I.S.C. model. While it was logical to speculate this would be the case, we wanted data to support this assertion.
Preferred ordering of the mapped D.I.S.C. elements on the FAD decision fork screen.
We realized the hierarchy of the mapped elements allowed us to resolve the issue surrounding the amount of copy content in the layout. We discovered users were not so much against having more copy, it was WHERE in the layout the copy appeared.
Typically, detailed and voluminous copy will map to the "C - Conscientious" behavioral quadrant, and in this case tested well toward the bottom portion of our layout. This is desirable for users who do not wish to read long sections of copy before discovering the CTA. Conversely, detailed information is available to those who choose to read it prior to engaging with the CTA.
Placing the detailed information at the bottom portion of the layout resolved a usability issue.
With the hierarchical layout now established, we still wanted more insight regarding the placement of the CTA buttons. We added behavioral questions to the test screener to determine which behavior profile test subjects would most predominantly identify, the D, I, S, or C.
Exploring layout options for placement of the CTA button on the FAD decision fork screen.
This aided us in understanding how users from each D.I.S.C. behavior quadrant would traverse the site, consume the information and engage with the CTA buttons. After analyzing the results from the user testing sessions, we arrived at a final solution for the design layout.
Preferred placement of the CTA button on the FAD decision fork screen.
Getting the Details Right
This design layout (with its hierarchal ordering of the elements and CTA placement) tested well with subjects representing ALL four of the D.I.S.C. behavioral quadrants. This was a revealing milestone. Lastly, we turned our focus to more detailed fine-tuning by testing variations of specific content within each element: headlines, icons, sub-headline, and bulleted copy.
Preferred placement of the mapped D.I.S.C. elements and the CTA button on the FAD decision fork screen.
Additional Insights
In extended conversations with test subjects, we were able to gain more insight as to how users (from each behavior profile) indicated they would most likely traverse the page and consume information. This mapped closely with previously seen DISC behavior patterns, where typically we see the following characteristics:
Users in the "D" behavior quadrant are looking for information quickly in a simple and concise format - direct and to‑the‑point for the "D". This often means content optimized for this profile appears at the top (or beginning) of a page layout. Once the "D" has the information it needs, it seeks out the CTA.
Users in the "I" behavior quadrant are seeking fun, engaging and somewhat playful imagery. Large size/hero treatment generates visual interest for the enthusiastic "I". Content optimized for this profile appears more prominently and conspicuously in the page layout. Once the "I" has the information it needs, it seeks out the CTA.
Users in the "S" behavior quadrant are interested in reassuring, safe and inclusive language that makes an "S" feel more at ease and confident. Content optimized for this profile typically appears hierarchically lower than content optimized for the "D" and "I" profiles in the page layout. Once the "S" has the information it needs, it seeks out the CTA.
Users in the "C" behavior quadrant are diligently looking for accurate information presented in a logical and organized manner which delights the detail-oriented "C". Content optimized for this profile typically appears hierarchically last compared to content optimized for the "D" and "I" and "S" profiles in the page layout. Once the "C" has the information it needs, it seeks out the CTA.
Final Design
At the conclusion of user testing rounds, we synthesized the user feedback along with the data and arrived at the final design layout. We were confident with knowledge of the following:
Where to place the decision fork screen within the FAD user flow
What layout users preferred
What placement order to use for the design elements
Where to place the CTA button
What visual design to use (fonts, colors, buttons)
Visual design for this project was relatively straight-forward as an established design system was utilized to ensure site-wide consistency.
This is the final design and layout for the FAD decision fork screen.
The final responsive design and layout for the FAD decision fork screen.
Specifications
Once final the design had been established, the next step was the creation of detailed specification documents for use by the Development team.
We were able to leverage design software to assist in the creation of the annotated mock-ups that would be used by our IT partners for development and coding purposes.
Sample design specification for the FAD decision fork screen.
Impact
A positive outcome
With the launch of this design, we were successful in satisfying user needs and business objectives. Moreover, we were ecstatic that we were able to not only deliver a functional design that achieved the stated project goals but did so in a manner that was pleasing to ALL users.
We were now confident in recommending a solution that better informed members they have the Teladoc benefit, why it's beneficial to use it (more cost effective and convenient), and makes it easy for members to engage (CTA).
Total claims savings $14.5m YTD as a result of increased awareness and engagement
Annualized Teladoc utilization trend increased 3.4% via 28,731 encounters YTD
Peak claims savings $507 (per episode)
The FAD search page entry point saw an 11% increase in successful conversions to the Teladoc option
Learning
What we learned about getting there
Despite starting out this effort in a very prescriptive manner, we persisted, sought collaboration and were able to eventually evolve the design. This allowed for insights to be revealed that ultimately took us in a direction that was unforeseen, yet beneficial.
Stakeholders voiced strong opinions about a solution that proved challenging to address. I didn't have immediate answers. After much consultation with the working team, we agreed we would seek to use data to guide our direction and rely less on opinion.
Initially we found ourselves in a very reactionary mode as a result of the prescriptive nature of the engagement and I realized that a design process would serve as the antidote to prescriptive guidance and allow us to regain a measure of influence. Additionally, we observed that we had to spend time repeatedly citing our research and user testing results to justify our design decisions with numerous stakeholders, if we could have collectively shared our findings more frequently, this issue could have been avoided.
With little time left in the schedule it was a big risk for me to make the decision to leverage the D.I.S.C. behavioral model, but I felt strongly that it could improve the design; fortunately the risk paid off as it yielded results well beyond our expectations by allowing us to tailor a solution optimized for all users.
