Work Overview

During my time at Omnicell, I was responsible for owning all design and research work for the Benchmarking section of Omnicell’s Inventory Optimization Service. This was a position that encompassed multiple features that were quite broad and ambiguous in scope. Despite the scope, ambiguity, and complexity, I enjoyed my time on this project as it allowed me to work on data visualization, as well as build cross functional relationships early on. Along with my Benchmarking work, I was expected to assist with additional design work such as contributing components to our growing design system, research into accessibility requirements, and hosting design critiques.

Along with my design work, I undertook additional non-design work that helped me grow into the senior designer role. I took on more of a mentor role by having bi-weekly meetings with 2 direct reports, and doing paired design with another junior designer. I also sought to have more influence over product roadmaps by holding workshops with subject matter experts to identify what features they felt were needed in our software, using affinity mapping to sort those features into different categories, and then collaborating with product owners to identify what features out of those buckets we wanted to work on.

Introduction to Benchmarking

When I first joined Omnicell, I was assigned to work on Benchmarking. The Benchmarking feature is a collection of statistics that can be used by pharmacy administrators and directors of pharmacy to understand key statistics such as overrides and stockouts within their enterprises sites and stock areas. Upon being assigned Benchmarking, the first thing I did was a quick heuristic analysis using heuristics laid out by Jakob Nielsen and Abby Covert. Some heuristic violations that I noted included:

• Findability: In order to navigate past the first level of information, the user had to click on a chart. There was no indication on this page that charts were clickable except for a change in the mouse indicator.
• Clarity: While individual data points on the screen made sense to users, the page was full of information that was competing for the users attention.
• Help & documentation: Certain charts compared customers enterprises to competitor enterprises. However, there was no way for users to tell what statistics were being used for the comparison, nor was there a way to identify what sites were part of the comparison group.
• Consistency: Charts (especially bar charts) would have multiple colors in them, however clickable elements of the chart were not made to stand out from non-clickable elements.

While I was working on my list of heuristic issues, I met with the PM to find out what features I needed help with. The major feature that they were working on required the addition of more charts to an already crowded page. While I was skeptical of the need to add additional charts, I went along with it for the time being while I waited to talk to subject matter experts to get their opinion about what needed to be shown on the page.

Setbacks, & Charting A Path Forward

While I was working on the initial ask from the Benchmarking PM, I was able to meet with our subject matter experts (strategists) to get theri feedback about the existing Benchmarking application and where they wanted to see it go in the future. The more I listened to them talk about what they wanted, the more I realized that the existing product didn’t have a solid foundation to include all of the features that they wanted to bring in, and that a redesign from the ground up may be necessary.

In order to identify what was needed, I initially set up workshops where the strategists and I could walk through the existing user flows. During the first workshop we were able to chart out the existing user emotional journey for Benchmarking users. However, during the second workshop when we started in on the existing actionable journey, I hit a major setback. About 20 minutes into the workshop, one strategist said (in a politically correct way) that this workshop was pointless and he viewed it as a waste of time.

This was a shock, but I quickly recovered and asked why it was a waste of time. He responded by saying that “we’ve had multiple workshops where we’ve given advice as to how to potentially redesign, but our advice has gone unanswered”. For the rest of the workshop time, we ended up talking about prior efforts, and how we could proceed going forward. While this started off as a major setback, it turned out to be a spark for change going forward.

Gathering Buy-In

After the meeting with the strategists, I took 2 parallel courses of action. The first course of action was to continue working on the features that had been scheduled, and the second course of action was to get clarity from leadership as to what we were driving towards with the updates to Benchmarking. Clarity from leadership wasn’t very forthcoming, so the next thing I did was draft a vision statement to act as our North Star.

After drafting the statement, I scheduled meetings with the same strategists that were in the failed workshop meeting to tell them of my idea and get buy in. They were receptive, and we worked together to identify features for a few wireframes that could provide a visual for the direction we wanted Benchmarking to go in. I then made a presentation for our quarterly in person meeting where I presented before product and engineering in order to get buy-in from key stakeholders. The presentation was a success, and as a result we ended up changing the direction that Benchmarking was taking to better align with my vision statement.

Final Results

After the successful in person meeting, I began working with the subject matter experts much more closely. I would have multiple meetings weekly with 3 core SMEs, and created a Slack channel where I could ask them for feedback on proposed wireframes. I also took advantage of our bi-weekly meetings with the larger strategist group to gather feedback as well. During this time I contributed multiple components to the design system as I had design needs that weren’t met by existing components. After the screens had been finalized, I then worked closely with the developers during the handoff stage. During this time I met with them every day during standup, and made sure to prioritize their questions.

What Was Next?

After working with the developers to ensure that the actual product adhered as close to the mockups as possible, I then turned my attention to the future Benchmarking roadmap. I hosted a workshop with the rest of my UX team in order to identify features that they felt should be included in future versions of IOS, and afterwards I hosted a second workshop with the PO and PM of Benchmarking in order to narrow down the results from the first workshop so that only features relevant to Benchmarking remained.

Non-Benchmarking Work

While Benchmarking was my main focus, I had multiple responsibilities outside of it as well. I was responsible for other design related tasks such as taking features that existed in legacy software, and ensuring that as they were brought into the cloud they met our design system standards. I also began mentoring more junior designers. This usually took the form of 1:1 meetings and making time for them to reach out to me in order to get feedback on their designs. Occasionally, I would hold paired design sessions in order to demonstrate to a less experienced designer how I would design a feature. I also contributed to the design system by designing components and writing up requirements. Lastly, I would occasionally present design centered decks to the larger Omnicell community as a whole.