Proving the concept
Summary
I assisted multiple teams in wireframing feature concepts, writing concept text, and user testing to create recommendations to an insurance and healthcare-hybrid client to help improve their digital front-door experience.
Context
This client brought our team on to imagine, design and build the future of their digital experience, but needed some help with their current web-based product.
Much of their portal was insurance-focused, and their healthcare capabilities (finding care) were comprised of vendor integrations that felt disjointed to navigate.
This work is from a few tight-timeline requests to satisfy existing contracts, as well to immerse ourselves early in our client's current experience. 
Approach
Feature 1: Claims Summary Page
Role: Design, Research

One team I worked with started the engagement in a cornerstone feature that would be essential to update our client's existing product, as well as explore for our future vision of their digital experience: the claims page.

Our client's design exploration up to this point


We looked at role model experiences in and out of the category primarily for different ways to present large amounts of complex data, especially ones that worked well as mobile-responsive.
Between tables, lists and cards patterns, we decided to explore card patterns as our client was already over-indexing on research for table and list patterns.

One early example was looking at Twitch.tv's card treatment

I collaborated with our designer and together, we created and evolved a wireframe based on some loose requirements and a wealth of information in the insurance space provided by our client to create our concept wireframes for user testing.

An early iteration of a Claims Summary page

An individual Claim Detail page, with 1 service

and multiple services

Early card exploration and notes on language issues.

Language exploration, and creating mental models around our Claim Categories

A brief deviation into Table exploration

From left to right: evolving our cards and categories, creating depth in our card and clarifying information in the cards, solidifying distinct areas of the cards, arriving at a standard set of information with more labels and fewer categories

Meanwhile our Detail pages took on a lot more information and needed additional structure to remain clear, without repeating too much of the high-level information from the summary page.

We did a lot of exploration, and got a little silly and meta in the process

Coming to a final card design, category layout and page intro, as

well as detail page

Finally we added color and other "high-fidelity" elements from get ready for testing

our client's design system to 

We then designed tests to run in UsabilityHub to understand how our Summary and Detail pages worked compared to our baseline, learning along the way how our new pattern was holding up, and at the same time, testing language around insurance claims.
Language-wise, we specifically tested:
1) people's understanding of a "claim" to help us identify if further explanation on our page was needed
2) claim status labels related to a claim being "covered" (how our client categorizes claims) and "Insurance Paid" (how a user understands the effect of insurance on a bill)
Feature 2: Homepage
Role: Design Leadership, Research

Meanwhile, another team handled a request from our client for recommendations on how to update their existing product with several new feature requirements related to virtual healthcare.

Our new requirements to integrate into an existing product

This team started similarly by creating concept wireframes for user testing. This time, however, we weren't trying to completely reimagine the experience, and had to incorporate new requirements while making sure existing features didn't get pushed aside in the process.

The existing product's current homepage

Because this was a larger feature, we also had to fit our work into their existing IA.
We had 3 designers and myself collaborate on different directions that ultimately had to be aligned to test against their baseline experience.
While I helped manage microcopy in the concepts, I took on a larger role of guiding our designers to design toward the new requirements and our learning agenda.
Our 3 designers' concepts, plus microcopy and annotations to line up the similar pieces in each

Our final concept

Once we had our concept ready, I partnered with a UX Researcher to build our learning agenda and tests.
We ended up testing these concepts in Maze with a similar A/B test for our baseline experience against our new concept, and term testing to help improve usability of our existing navigation.
See Maze (Research synthesis pending as of April 10, 2022
Result
Both sets of wireframes were excellent learning experiences for our team and helped us point our client away from technical language that helped satisfy requirements toward language that the average healthcare or insurance user could comprehend.
Successes
In the first feature exercise, I was very gratified to get to dive into wireframing exercises that I'm not typically asked for.
In the second exercise, I helped prove a case to my company and our client for UX Writing's utility to the UX Research process, and subsequently developed a few lunch-and-learn sessions on the topic to show the benefits to other teams at my job.
In both projects, I pushed hard for term testing and making sure that our user testing efforts covered and took specific emphasis on our language in addition to general usability metrics.
Opportunities
The main thing both of these projects could have benefitted from was more UX Writing support.
On the Claims project, I had much less input on the testing process, and followed a template created by the lead on that team.
In contrast, the Homepage project had UX Writing resources heavily involved in the testing side of the work, but less so in wireframing, and our presentation with our client suffered from a lack of strong storytelling about our process.
Another opportunity overall would have been to take a rapid-prototyping approach to both features to test the validity of the new ideas because we knew our designs would still have to iterate over time.
Also, obvious note, but something we talked about a lot on these projects: always test the baseline when iterating.
Back to Top