This is a story about a clash between user needs and business goals. As I finished conducting my first round of interviews, my main takeaway was that none of the users had faith in a web tool to help them do their jobs. I didn’t learn this until I was about 3 months into the project, but there had been a previous attempt to build this tool (without a designer) that had utterly failed with users. Thus, the business spun up a new effort, Project Phoenix, to build a web app reborn from the ashes of the last one.
The interviews
This was my first project at Optum in 2021. The business
I conducted one-hour interviews with seven users – I wanted to talk to them about what they did and things that were important to them. After about the third or fourth interview, I started to grasp what they were doing with rebate calculations, but also learned that none of them were excited about using a web-based tool to do their jobs. These were power-Excel users and they loved their spreadsheets. I watched and re-watched the interviews to try and absorb the workflows and use-cases they explained to me.
Interview findings
I put all my interview data into a Miro board and mapped out patterns and common themes. Even just a few years ago, transcription from video interviews was pretty messy and I had to clean up a lot of the text. Today, I would drop the text from the interviews (much cleaner and more accurate now) into Copilot or something similar and ask it to analyze for themes. I’d definitely check it though – often there are strange hallucinations happening in AI-returned data. It’s helpful to kick-start the process, though.
Presenting findings to stakeholders
When I was done with the interviews, I was convinced we should not be building this tool. One of the users, a lead on the team, told me point blank he would not use this new tool. He even went so far as to say he would leave the team and maybe the company if forced to use a web application in place of his Excel spreadsheets.
He was being realistic. A lot of the calculations this team performed were beyond complex, comprising of many layers of pharmaceutical company relationships, Part D regulations, formulary rules – the users needed accurate data, and they could clearly see when things weren’t coming out correctly in their spreadsheets. They were moving millions of dollars around by adjusting rebate percentages. The former web tool the business team had built was unusable because there was no transparency to see how the calculations were made – and they were often wrong.
I was teaching an online UX/UI bootcamp in the evenings at this time, too, and I had followed the same research methods I taught to the students. I was actually very happy with the results of my research. I felt like the process had done its job perfectly and we knew what our users preferred. I’m not sure what I was thinking, but I was actually excited to present my research findings to the business team. They didn’t have to spend the money after all to build the web app because no one wanted it. Well, the business was very committed to building the tool and wasn’t swayed by the fact that no one wanted it. They had been instructed by their leadership to get this done because the leaders found Excel archaic and felt the team needed to be on a more modern platform. I consulted with my manager at the time and he gave me some good advice. As our design group operated as a type of agency and not as a tech partner, we can point out the risks and try and tell them (three times he said) what we found out in research. Then, if they want to go ahead and build the tool, we’ve done what we can.
Meeting with the Product Owner
Until this point, I still didn’t know who the Product Owner was. Gordon was the missing piece and he became a really good partner in planning out the design for the application. I made a diagram to plot my emotional journey through this project and the high point was definitely meeting Gordon.
Gordon had a lot of insight into the previous tool – he had actually built it with another team and he was very familiar with the pharmacy rebate workflow. He was a combined subject matter expert and Product Owner – which was the case for many of the Product Owners I worked with at Optum. So many of the processes within the healthcare system are remarkably complex and a product team needs an product lead that has deep domain knowledge.
Brainstorming with the development team and choosing a design system
The dev team was great to work with. I started talking through flows with them using pencil sketches because we had so much to figure out we needed to start simple. There was a design system (UI Toolkit, a very good one and vetted for accessibility) that I thought we could use, but it turned out it didn’t have the complex components we would need to give the users all the robust table functionality they needed, so we decided on a mix of Material UI components combined with Kendo tables (the Kendo tables have really terrific functionality already built in). In 2021, we were still using Axure as our primary prototyping tool, so I built a prototype for us to work with. I used the research to develop personas so we could check our priorities against the priorities of our primary users.
Conclusion: the phoenix reborn?
The design budget for this web app included a round of user research and design system implementation with a prototype containing basic functionality for the app. That took us through 6 months and then I moved onto another project. Last I heard, the project was paused due to some technical challenges and shifting priorities which is very common in that organization. Ultimately, though, I think the users felt heard throughout the process, which was my goal. Sometimes the design thinking process does it’s work in mysterious ways. It’s very teachable. It can take a little while for the process to land in a meaningful way with other members of the team, but it will. Over time, product and development teams see the value it brings.