Multiple Procedures

Problem

---

How might we facilitate management of multiple procedures for individual patients?

Summary

Accommodating multiple procedures, particularly different types of procedures, challenged the existing information architecture.

1. Expanded functionality
2. IA update
3. 6-month timeline

Background

---

LAAC for Life

Most patients that undergo left atrial appendage closure (LAAC) have one and only procedure for flie. The MVP version of Hawkeye understandably accommodated this scenario.

Patient 2

Occasionally, some patients undergo a second procedure of the same type, whether the first procedure was canceled, aborted or unsuccessful. This scenario required patient duplication given the original version of the product.

Accommodating TAVR

Another class of patients undergo procedures of different types—concomitant (e.g., ablation and LAAC) or unique (e.g., transcatheter aortic valve replacement, or, TAVR).

The Customer Experience

Customers understandably want to manage these scenarios without having to duplicate the patient. At the same time, the business wants to accommodate the same for retention and advocacy purposes.

High-fidelity wireframes of multiple procedures, in this view Ablation and LAAC collapsed. This model permits stacking of procedures with means to open any or all, within the existing product IA.

Strategy

---

Summary

1. Clarify requirements
2. Low-fidelity prototypes
3. User testing
4. High-fidelity wireframes
5. User testing

What procedures? How many?

Hawkeye was originally created to support a specific AFib procedure, namely LAAC, and a specific device, namely Boston Scientific’s WATCHMAN.

There are other procedure types, as well as, devices but in accommodating any, what is best for growing the WATCHMAN business?

We learned through research that essential to customer retention was management of two additional procedure types and multiple instances of each type, which we subsequently codified in a "MVP" iteration of multiple procedures feature.

Workshop

To generate ideas, I conducted an abridged version of the Google's design sprint consisting most notably of crazy eights and refinement of any preferred concept.

Workshop participants, sketches and discussion.

Information Architecture

As part of the initiative, inclusion of one previously released and well received module (Procedure Summary) along with an additional module (Notes) pushed the existing information IA further.

Low-fidelity wireframe to assess information architecture, particularly placement of the procedure summary and notes modules.

Challenges

---

Procedure or Therapy?

A proverbial challenge for any team is adopt external language in its product’s UI and avoid internal nomenclature.

LAAC consists of a device implant as reflected in Hawkeye’s UI and the patient’s journey with referenece to pre-implant and post-implant milestones.

But not all therapies consist of an implanted device, such as ablation.

Through user interview, we confirmed that procedure is the best word in reference to the many types of cardiovascular therapies.

Information Architecture

Accommodating management of multiple procedures—types and instances of—proved to be a challenging design update.

• First, as opposed to a redesign, design updates generally stipulate preservation of existing content and functionality
• Second, there is only so much real estate for any and all content
• Third, too much information risks cognitive overload

Our solution addresses the above and provides a premise for an eventual redesign in anticipation of demand for multiple procedures expansion.

Solution

---

This initiative is currently in development. Research to-date confirms both the desirability and functionality of multiple procedures. Testing confirms usability.

High-fidelity wireframe of multiple procedures (Ablation and LAAC) in the Patient profile with LAAC task selected.

Work

---