Giving members direct access to providers throughout their health journey.
Aetna teams up with a network of telemedicine nurses and providers to provide digital services to high-risk members. This project was to bring this feature to life within the native apps.
ROLE & DURATION
As a Senior Product Designer and Team Lead, I lead a team of UX/UI designers to work across a host of features across the product, including: health and wellness coaching, health records, device integration, messaging, personalization, recommendation engines, rewards and incentives.
This case study will cover the nurse messaging feature!
TOOLS & METHODS
- Strategy and Concept Design
- Generative and Evaluative User Interviews
- Product strategy and requirements definition
- UX design (wireframes, user flows, prototypes)
- Tools: Sketch, Omnigraffle
"How can we provide members with direct access to providers, while also managing their expectations regarding reply time?"
Messaging is not a new feature and there are many standard interaction patterns that users have come to understand and know. The challenge with Aetna is that the company employing these telemedicine nurses and providers did not have a quick reply time that is often associated with messaging or chat features.
My job was to try to make messaging a nurse as intuitive as possible, while also setting the expectation with users that this was not always the appropriate substitute for care in certain situations (i.e. high urgency emergencies)
Several of the following factors influenced many of our initial parameters and requirements:
1. limited to only high-risk members enrolled in specific programs
The company employing telemedicine nurses and providers had limited capacity, so the only users who would have access to this feature would be those who:
(a) had this as a feature in their company plan
(b) had some sort of chronic condition that Aetna deemed as "high risk"
(c) were enrolled in a specific program to manage said chronic condition
2. slow reply time
Due to the company's limited resources, nurses would reply to member messages within 4 hours, but only during business hours (would correspond to the member's local time zone). This made managing expectations extremely important for members and notifying them that if this was an emergency, members should not rely on this feature.
3. 'blue sky' versus mvp
Due to many API limitations, there were many features that had to be de-scoped for future iterations. It was very important for our team to fight for the features that we thought were mission-critical to the success of the MVP, while also laying the groundwork for future iteration work.
I took a look at how messaging was handled in other applications, ranging from chat bots to email. After much research, we decided that designing something that looked like chat or text message would not be an appropriate way to set expectations in regards to reply time. Once we decided on that strategy, our research honed in much more on email type frameworks, such as Gmail and Apple Mail.
technical requirements and constraints
Since Aetna was partnering with an external company to deliver this service, it was important to understand all of the backend and API limitations in deploying the service.
After conducting the initial research, setting the strategic vision, understanding the technical requirements and constraints, I set out to map out the initial user flows for our multiple user groups.
initial wireframes + prototyping
After the user flows were finished, I created low- and medium-fidelity wireframes to illustrate the main user flows. I then put together a prototype to test with users in a moderated usability test. I helped our UX Researchers to create the moderator's guide, but I myself did not conduct the interviews.
After we received the results from our testing, I worked with product to define requirements and acceptance criteria for UI designers and engineers to pick up in their sprints. Working with the UI designers, we translated my medium-fidelity wireframes into high-fidelity screens and specs for both Android and iOS engineers.
final specs for engineering
As the team lead, I facilitated the kickoff meetings between product, design, and engineering for the handoff to start development.
the solution overview
A new way to message your providers, for both resources and questions.
Example user flow
This user flow outlines what happens instances of success and failure, questions for product, actions taken inside and outside the app, actions that the third party company takes, as well as blue sky features for future iterations.
Low Fidelity Prototypes
- iOS: InVision Prototype Link - clickable prototype for (1) High Risk users identified and given a phone call and (2) has been assigned 2+ nurses and (3) has not sent a message in the app yet.
- iOS: InVision Prototype Link - non-clickable prototype for (1) Low risk users NOT given a phone call but still eligible for program and (2) has NOT been assigned a nurse
- RWD: InVision Prototype Link - non-clickable prototype for (1) Low risk users NOT given a phone call but still eligible for program and (2) has NOT been assigned a nurse
High Fidelity Screen Examples
Android and iOS
Current project status:
- The feature is slated to be built by engineers by the end of Q3 of 2018