NaviNet Configuration Framework Contextual Field Study

As our productized NaviNet Open portal was finally being realized, we recognized a need for a streamlined configuration interface. In the past, all configurations were manual, requiring direct manipulation of XML, JSON, and other files. Most of the time, developers had to get involved, even to make the smallest changes, such as updating a logo or changing which fields are required on a search form. Utilization reports had to be extracted manually. Content publishing tools built for our Marketing department and payer customers were also challenging to use, and they were not consistently standardized across plan environments. Essentially, there was very little that customers, end users, or even non-technical internal NaviNet staff could do from a self-service standpoint.

With these product gaps in mind, we launched a broad field study to better understand user requirements, across the spectrum of all folks who interact with and need to configure the NaviNet portal. This initial study was primarily focused on internal folks at NaviNet, but we planned to follow it up with subsequent external research efforts, where we could also talk directly to payer and provider office users. In the interim, we leveraged some of our external research findings from past field studies to help flesh out the persona narratives and patterns that we constructed within this study.

Client: NaviNet

Industries: Healthcare, Insurance

Demonstrated Capabilities: Contextual Field Study, Journey Mapping, Persona Development, Process Improvement, Product Definition, Standardization

Tags: configuration / consulting / content publishing / customer support / customers / data cleansing / deployment / developers / documentation / end users / marketing / monitoring / NaviNet Open / operations / payers / portal / provider data / setup / utilization

The Project Story

Overview and Goals of Study

Now that our productized NaviNet Open portal was becoming a reality, our goal for this field study was to comprehensively understand all of the various internal and external needs for configuring the portal. Our previous custom solutions required a lot of manual adjustments, and developers almost always had to be involved because there was no user interface. We wanted to understand how we could best build a Plan Management application that allowed non-technical users on the health plan and provider sides to quickly setup their NaviNet environments on their own. We also wanted to make it easier for internal staff to help customers make changes.

Participants

We interviewed 27 participants from 11 different departments within NaviNet. This provided us with a broad understanding from many different perspectives.

Personas

Because the scope of the configuration framework was quite broad, we ended up producing 16 different personas. We then divided these personas into five major categories: 1. payer operations, 2. deployment (setting up office data), 3. support/operations (monitoring production), 4. content publishing, and 5. end user configuration. In each persona, we laid out sub-roles and themes. We listed main tasks, goals, paint points, and desires. We kept the presentation format for these personas streamlined, but we also constructed extensive scenarios (narratives) for each persona that included lots more context, workflow nuances, and other details that we derived from our collected research.

We later reformatted each persona that we produced in this study into large posters so that we could put them up on our User Experience Wall and better socialize them across the entire organization.

Workflow Across Persona Roles

We constructed a high-level diagram to illustrate how each persona is connected, and the various workflows that exist between these personas. This helped stakeholders see, at a glance, the many different roles that are involved in configuring the NaviNet Open portal.

Summary of User Requirements and Recommended Priorities for Product Roadmap

We summed up NaviNet’s configuration framework user requirements, suggesting a prioritized functionality roadmap based closely on our research findings. Our goal was to help the product manager and executives determine which features would have the greatest impact, right out of the gate.