A baked-in teamwide assumption for a new feature could have resulted in dangerous error states, potentially causing patient deaths. I championed awareness of our user’s context and holistic experience outside our software to change that assumption. The result was a smooth, simple solution that would have a much lower error risk.
Research, user flows, error maps, risk maps, stakeholder management, UI
Figma, FigJam, ProtoPie
Lead and only Designer
I was asked to build a feature that held a pervasive teamwide assumption that, if unchallenged, could have jeopardized patient safety. Utilizing journey mapping and risk mapping, I uncovered potential risks due to a multitude of error states a pharmacist could unwittingly enter into.
I rebuilt the current experience to hold the users hand, preventing the potentially fatal error states. At the same time, I streamlined the UI's information architecture, defined new patterns, and built components for our company-wide design system.
I had started reworking the flows and interaction patterns for better alignment with our long-term vision and enhanced usability, but unfortunately that is when the layoffs hit and I was unable to see it through to the next iteration.
Omnicell is a pharmaceutical robotics company. Their main product is a cabinet that stores medicines securely across a hospital. The medicines are dispersed when an employee badge is scanned, issuing the correct medication and dosage for the right patient, reducing human error and saving lives.
Pharmacists have an extreme need for precision. When they approve something to be done, their name is signed to it. This created a need for extreme transparency, power, and flexibility in all of their tools the leverage.
Pharmacists are considered a cost center by hospitals, and must therefore continually look towards savings they provide the hospital in order to justify their positions.
In hospitals, medicines are stored in Omnicell's smart cabinets. Sometimes, the medications can be in multiple drawers, or bins, at the same cabinet. Pharmacists routinely modify which medications should be there and how many of them should be stocked in each cabinet. Previously, when setting the total amount of meds in a cabinet, the software would evenly disperse them across all bins, potentially overloading smaller drawers.
Recognizing the need for a more nuanced solution, the product team decided to make each bin configurable.
Given the pre-defined solution, I immediately worked with Product to define what the success criteria should be for the project.
Given that we had no baseline metrics for these, it was determined that engineering would build out the analytics needed in Pendo, and we would establish the post-launch numbers as future baselines. In the meantime, success would be determined qualitatively by our users.
Armed with success criteria, I felt the solution being proposed by the product owner would not accomplish our goals. I was particularly concerned about patient safety, something that we didn't discuss when establishing the success criteria.
I placed the experience we were hoping to improve within the greater context of the medication dispensing journey I had previously built as a team resource. It quickly became apparent why patient safety would be a major concern.
There was a critical danger point when the nursing staff went to retrieve the medicine for the patient. If there were even just one dose fewer than expected, that could cost staff valuable time and composure that could cause delays of treatment, medical errors, or even death.
I developed several visual artifacts detailing the risk, gathered feedback from our internal Subject Matter Experts, brought my thoughts to the design team at large, and presented my findings to the product team.
I showed the many ways for unintentional error states to creep in to the pharmacist's inventory. I showed how critical the risk was at various points of the entire medication flow.
I showed how this was not aligned with our goals as a company and how it could negatively impact patient's lives.
The team, after seeing the risk, agreed to instead move forward with a new interaction pattern I suggested.
In order to make things smoother and better, we would need to tear the old world down. At least a little bit. A little bit of tearing.
I reworked the organization of a very limited space displaying a high density of data to accommodate our new flow. It took more than 15 iterations before the team felt comfortable with where we landed. This was all completed within a few short weeks alongside other projects simultaneously.
I created new patterns which needed to be built as components in Figma, documented in our design system, and handed off to engineering to be made available across the platform.
Our new flow ended up having an extra step for users to fill out. On the surface, it was a slower experience. In reality, the extra step ended up being faster with less cognitive load. Because I did the work to understand how pharmacists were managing their inventory, I was able to create a design that matched how they thought of it.
Additionally, the new flow allowed us to hold their hand while they were making these changes. Because we added this extra step, we could validate their numbers much more accurately, effectively eliminating the odds that a fatal inventory error would be introduced into the system.
Not sure! I was affected by layoffs shortly after having finished the project. I hope to hear how the design lands in the wild, but until I do, here are the outcomes we were hoping to achieve: