Watson for Patient Safety IA
Although clinical trials aspire to capture the risks that a drug may pose to a patient, new discoveries of associated adverse events (AEs) don’t disappear once the drug is cleared to enter the market. Instead, they often spike, simply due to the vast increase in “sample size” provided by the general public. Pharmaceutical companies track all AEs for the drugs they develop, as reported to them directly by physicians, evaluated in scientific literature, and even ranted about across social media. Only through the careful tracking of this incoming information can scientists keep a close eye on the balance between the benefits that each drug provides and the risks it’s been reported to cause. In the trenches of this demanding data collection operation are the case processors, responsible for scrupulously translating the content from received sources into precise encodings that meet rigorously regulated data hygiene standards. Watson for Patient Safety aimed to augment aspects of this complex workflow, leaving users to focus on tasks that most benefit from human input. From a user experience perspective, this meant I’d need to carefully consider the branching dependencies inherent to case processing—wherein each step is determined by the data itself—and account for it fully in the design’s underlying structure before diving deeper into detailed features.
Project pretext: Professional
Objective: Plan the information architecture (IA) of the Watson for Patient Safety Product, reflected as an IA map
Timeframe: 2-3 weeks
Role: UX focal
Additional team members: None involved in this IA project
Target users: Case processors and receipt coordinators in the pharmacovigilance space
Breaking down the many possible paths a user might take to complete a case processing task would inform my design team and I in the creation of cohesive, high-level design patterns that worked together to guide our users. An artifact mapping these decision points could help us to develop a holistic awareness of the bigger picture that we’d need to accommodate.
In the same way, a visual architecture could act as a single point of reference for the design, development, and offering management teams. We’d all have one consistent source to consult which would aid in future, more nuanced decision making around specific features.
When I joined the Watson for Patient Safety team, design and development had already started several months prior. I explored ideas for a number of user scenarios by first mapping out possible flows. While this was important for the design task at hand, it left my solutions feeling isolated from the context of the overall product. A fundamental, structural underpinning seemed to be lacking, making the simple act of determining how a feature fit in with the rest unnecessarily laborious: for every chunk of functionality I attempted to provide designs for, I first had to investigate which other aspects of the overall user flow it affected or interacted with, which often revealed enormous oversights and gaps in the experience.
Starting instead with a holistic framework, encompassing all the microstructures I’d been mapping for each individual design problem, seemed to be an up-front investment that would pay out dividends in the form of more efficient design-decisions, less churn, and increased alignment across the team.
I read up on the practice of information architecture, which I came to define as the organization and presentation of information for efficient comprehension. I felt it would pay off to first focus on the organization end of the spectrum before beginning to refine towards the presentation part.
Establishing an information architecture for WPS proved particularly important, seeing as it was intended to support such a deep, task-based workflow wherein downstream actions were wholly reliant upon their upstream counterparts: without a way to reference these relationships, we ran the risk of missing important dependencies that could invalidate our original designs.
Since I needed to know how the designs I was working on would fit together into the user’s flow overall, I began by sketching out maps exploring their overlap.
Once I had the structure in a semi-stable state, I brought it into Axure (a tool made for building IA maps). The sum of all my existing, detailed micro-flows proved extensive and difficult to view on a computer screen, so I printed them out on long rolls of paper where I could easily edit them as I grew my understanding of the product as a whole and what had already been designed before I joined. I repeated this process of printing a physical copy, amending it with the help of several colorful writing utensils, and updating Axure at least three times.
With each printed iteration I built in more detail—and micro-interactions—intending for the map to act as a tool through which to communicate these nuances to our development team.
At last, I had one humungous, holistic map of WPS and the touch points between its underlying technology and our users. However, it was undeniably difficult to extract any insights from the extraordinarily convoluted routes making up my enormous map. Ironically, the artifact I’d created to communicate the information architecture suffered from a serious case of information overload.
I took a metaphorical step back (as well as a physical one—to have the whole map in view), and remembered the individual user flows I’d started with. They each explored a problem space specific enough to benefit from micro-interactions; in my comprehensive map, however, these details were mere clutter, and defeated the purpose of my original intent to identify relationships between the chunks of functionality themselves. A “master-map” that created connections between the major points along a user's journey through WPS would be much more practical and useful.
I distilled my initial information (overload) architecture map into a less granular overview that functioned more as a foundation for understanding Watson for Patient Safety from the user’s perspective. Then whenever a team member or collaborator needed more nuanced detail, they could drill down into one of several hyper-specific mini-maps.
The IA map layered several types of information: indications of which user roles interacted with which parts of the product, whether Watson or a human completed a particular activity, and if a step was mandatory or left to the user’s discretion, just to mention a few. I represented screen interactions as boxes, decision points as diamonds, and paths between them as lines, then assigned each information type a different “visual variable” such as color, line or border weight, or texture.
Both the act of creating the IA map, and the artifact itself served to help me better explain aspects of the user flow when I met with members of the development and offering management teams, other designers, and even clients.
When I met with a group of customers and case processors I relied heavily upon one mini-map and its surrounding context within the main IA map to help describe a specific design solution for dealing with follow-up reports. The first thing that must be done when an adverse event report arrives is to check whether it's a "follow-up" containing additional or edited information pertaining to a report received earlier. If the report is a follow-up—and whether it contains new or updated patient data, or both—all inform the route that the case will take. After I'd walked my audience through the sequential screens I'd designed, I presented the relevant mini-map to reference all the possible case trajectories, visualized as cascading design trees, and encoded areas of the workflow where Watson would step in to speed up the process. It helped to have one view mapping all outcomes so that the group could quickly perceive the impact WPS would have in helping them get through otherwise tedious tasks.
“Lia, you read my mind for duplicate search. I am so jazzed.”
—Pharmacovigilance Director of Operations at Roche
Once I’ve learned something new (especially if my lesson was acquired the hard way), I like to share my findings with others. I pulled together what I'd read about information architecture and coupled it with examples from my own process, then presented it all at a UX guild meeting for other Watson Health designers.
This led to an increased interest in IA across our product portfolio, and I went on to head up a group that established IA-related guidelines and best practices for all of Watson Health.