Multiple Procedures

Problem

---

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

Summary

Accommodating multiple procedures, particularly different types of procedures, challenges existing product architecture—system and information.

Background

---

One procedure

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

Patient duplication

Some patients undergo a second LAAC procedure whether the first procedure was canceled, aborted or unsuccessful. This rare scenario required patient duplication given the original setup of the product.

Other procedures

Some patients undergo procedures of different types—ablation or transcatheter aortic valve replacement (TAVR)—or concomitant procedures.

Retention and advocacy

Customers understandably want to manage these scenarios without having to duplicate patients and the business wants to accommodate customers for retention and advocacy.

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 an LAAC task selected.

Work

---