Allergan TrueTear Companion Software

TrueTear is a handheld stimulator with daily disposable tips that is inserted into the nasal cavity to induce the production of tears.

Under my direction, the design team architected, tested and delivered a companion mobile application that patients could use to manage their care.

Early in the Definition phase, I worked with client leadership to assemble a hot list of concepts. These concepts became the basis of scope for initial user research. Under my direction, the user researcher and I worked to flesh out and verify features that would most benefit the patient’s experience with the TrueTear device based on in-person, interactive user testing.

 

User Research

We began the research effort with the design of a comprehensive custom User Research Plan that included recruiting and testing protocols and spanned 14 weeks. Testing was done on 40 participants over that period. Recruiting was conducted by Schlesinger, the client’s chosen market research vendor, based on protocols we drafted. User testing—also conducted at their facilities—included interviews and behavioral monitoring.

The research was targeted to gather enough data to analyze the vector between each feature’s usefulness to the patient versus their value to the business. The results were then used to focus development on features that would yield the best mutual outcomes, thus optimizing the effort.

Iterative Architecture and Design

The system required synchronization between the patient’s mobile and treatment devices (via Bluetooth) and Allergan cloud (via web connection) for archival backups and anonymized system performance monitoring.

The system required synchronization between the patient’s mobile and treatment devices (via Bluetooth) and Allergan cloud (via web connection) for archival backups and anonymized system performance monitoring.

As development iterations moved forward, the design team and I participated in the Scrum process alongside development to ensure continuity and facilitate a more efficient transfer of knowledge. I operated as the product manager and chief architect throughout this period, overseeing scope, providing architectural inputs and managing the budget. Inputs included participating in the enumeration of user stories and development of their details. This also enabled any design changes needed—due, for example, to acceptance criteria or technical requirements—could be made seamlessly without slowing down development iterations.

Design team participation was critically important to ensure the user’s perspective was well represented during the evolving development effort. The usability researcher, designers and I were able to provide background on design decisions based on subject matter expertise and in-field experience with the user base to the client and development team. This made it possible to advocate for the preservation of certain details with an experiential impact that, on their surface, may not have otherwise been apparent when viewed solely through the lens of technical requirements.

Wireframes exploring patient trend reporting.

Wireframes exploring patient trend reporting.

Exploring forecasting feature to help patients manage their treatment that evolved into the Eye Dryness forecaster—a weather report for the eye.

Exploring forecasting feature to help patients manage their treatment that evolved into the Eye Dryness forecaster—a weather report for the eye.

Further iteration on what became the home screen that included integration of the Eye Dryness forecaster.

Further iteration on what became the home screen that included integration of the Eye Dryness forecaster.

 
 

Lifecycle Strategy

As this device system is also a Class II, FDA-regulated medical device, supportability is critically important. Therefore, throughout the joint design-development effort I collaborated as the product manager and architect on the inputs into the quality management system to ensure regulatory compliance throughout the user-facing functional evolutions that occurred throughout development. In particular, this meant co-management of the Software Requirements Specification, Software Design Specification and Verification and Validation documentation.

In addition, a number of features were deprecated for the initial release, but remained in the research and architecture archives for future consideration. Based on the level of accumulated detail on the structure and simulated performance of these features, some can be considered and more easily implemented in future releases.

Home screen with an updated design for the Eye Dryness Indicator that was devised for the Beta release

Home screen with an updated design for the Eye Dryness Indicator that was devised for the Beta release

1.jpeg

What does this mean for TrueTear? I think it’s a net positive outcome. TrueTear continued to be effective, producing an increased output of a complete, three-component tear.