Problem Statement

Stryker needed to create an accessbile experience for medical professionals who interact with their Altrix machine to manage patient therapy. This meant creating better access to real-time data and post-therapy data so action can be taken quickly and confidently.

Hypothesis

By understanding how medical professionals currently interact with the device we could begin defining the boundaries of the ecosystem and explore how the data flows and is presented between the various mediums. By utilizing their in-house “Health Cloud” Stryker could enable health professionals to provide the best possible care quickly, and with confidence.

Biggest Challenge

Our biggest challenge surfaced as an information architecture problem stemming from 2 primary sources.

A shortened timeline provided limited time/resources to adequately dive deep into the objects, relationships, and information available and also what’s desired by the people using the system.

This was compounded by a lack of engagement from SMEs, which became clear as the project progressed.

The first step was meeting with medical professionals to understand how they currently interact with the machine, what ‘jobs’ need to be done, and identify opportunities for improvement.

After gaining a better understanding of the human interaction side of the equation we worked on connecting it to the back-end to understand what was currently possible and where there were gaps in the data.

Using an object-oriented approach to defining the objects involved in the experience and their relationships and actions offered to end users.

Creating priority guides for each portion of the experience to set expectations for functionality and features designed to deliver value.

As part of our course correction in the face of low engagement we split the work across the team and ran a lean process starting with high fidelity wireframes.

We did this to quickly ideate through ideas and force recognition of alignment or gaps in communication.

When we received confirmation that the experience meet the necessary business requirements (often limitations) we moved on to creating the UI.

We had to constantly be aware of current state UIs and potential hospital protocols that may restrict how we designed certain things.

We needed to maintain consistency where possible to limit cognitive overload for end users as well as avoid any potential risks overlapping with critical hospital UI patterns/procedures.

Defining the Value of a Native App

The second phase of the project focused on defining and creating a Native App specific experience designed to deliver a specific set of value features.

This meant understanding what technology could be leveraged to create Native App specific features that would benefit the business or meet user needs.

A Deeper Dive into Data Visualization and Storytelling

The second phase of the project focused on defining and creating a Native App specific experience designed to deliver a specific set of value features.

This meant understanding what technology could be leveraged to create Native App specific features that would benefit the business or meet user needs.