Curbside Consult with Dr. Jayne 10/8/18

Although the majority of my work is in the CMIO space, I occasionally do some work for vendors. Depending on the vendor and the situation, it could be anything from participating in a focus group to helping design and execute on usability studies.

I’ve worked with vendors who truly get it and are just looking for supplemental input or outside validation for their strategies, but occasionally I work with a vendor that has some significant gaps. This week included successful interactions and one that left me perplexed, so I’ve decided to put together some thoughts for vendors on what to do (or not do) when seeking input from physicians.

First, vendors need to know what they hope to accomplish by interacting with physicians. Do you want an actual practicing physician, and if so, in what specialty or what setting of practice? If not, do you just want someone who “thinks like a physician” and can take you through typical diagnostic or management options? Do you want to work with physicians who understand both the clinical and informatics spheres, so they can provide input on the end user experience but also strategies for solving the problems they may help you identify? Do you want someone who can help with clinical guidelines only and needs no understanding of software and technology?

Working with physicians can be costly since many expect compensation for their time equal to what they would have earned seeing patients during the time they spent with you. It’s important to not only make sure you have the right type of physician, but also that you are prepared to spend your time with him or her wisely.

I worked with a company early in the week that knew exactly what they wanted. They provided a brief synopsis of the project and the assumptions they wanted to test with a physician. They provided that information with enough lead time that I could review it thoughtfully prior to our call. They made sure to let me know that they wanted to interact over video, which let me know that I shouldn’t be in my pajamas or look like I just came off the treadmill, which is occasionally my habit depending on how many calls and meetings I have in a given day.

When I joined the call, it was clear that all internal resources had joined with enough time to be set up and oriented and they were ready to introduce themselves and describe their roles on the project. They also asked me to say a few words about myself and my background, which allowed for adequate level-setting all the way around.

We worked through a product prototype first at a high level, with me giving initial impressions and the team documenting any questions I raised or elements that I didn’t understand. That allowed us to get through the entire workflow without being derailed by details or issues with the mock-ups. Then, we took a second pass through the prototype and addressed the areas where I had questions or didn’t understand where the workflow was going.

I think it was helpful to them that I understood that we were working with some enhanced wireframe designs and not actually software on some of the screens, so that I could phrase my questions around whether what I was seeing was just an artifact of the mock-up or whether it was actually a design element. We then took a third pass through the workflow, with the team allowing me to identify areas where I thought the flow could be enhanced or where functionality could be added to better meet the original design intent.

It was clear that the team was experienced in respecting the time of their audience and also that they had prepped for the call, knowing approximately how much time to allot for the different phases of review. It didn’t feel rushed, we didn’t end with a lot of time left over, and there weren’t too many items that needed additional follow up. They clearly took good notes during the call because they were able to come back to different comments I had given and read them back to me almost verbatim, asking for clarification or expansion on what I was thinking. The whole experience was challenging and fun, and I hope they’ll be interested in my feedback as the project progresses.

The vendor I worked with later in the week provided a polar opposite experience. It was a bit of a different situation to begin with, since the vendor is trying to introduce a new spin on existing workflow and technology rather than moving forward with an innovative product. In my opinion, that makes it challenging since anyone looking at their offering is judging it against their current technology whether consciously or not.

They were asking me to evaluate a new way to do work that I’ve been doing electronically for nearly two decades across half a dozen platforms with numerous upgrades on each. Although one could take the strategy that it would be good to have an experienced clinician who can provide feedback on what other vendors are offering or have tried in the past, the developer kept interrupting the conversation and going on and on about not allowing “the experience” to be hampered by “the technology of today.”

I didn’t realize there were going to be developers on the call. That’s always a tricky one since sometimes when you provide feedback, they can take it personally, and especially since they weren’t introduced when the call began. Having silent parties on a feedback call that suddenly jump in and start a conflict with your research subject usually isn’t an effective strategy.

The product owner tried to calm him down, but it wasn’t working. I tried to explain that unfortunately the workflow they’re trying to address is hampered by a litany of external requirements that they hadn’t addressed, such as governmental and payer regulations. It doesn’t matter what your UI looks like if it is going to force the end user to behave in a way that is going to cause trouble in the case of an audit.

Part of the exercise was for me to work through an alpha version without direction or training to evaluate how intuitive the workflow was. At one point, someone who probably thought he was on mute but wasn’t actually said, “She’s doing it wrong. Why is she clicking there?” When I replied, “I clicked there because every other screen has the ‘save and close’ button in the bottom right corner and that’s where my hand naturally flowed,” there was just a stunned silence. At that point, another member of the team took over the call and we moved forward in the workflow, but I had a hard time thinking of the product vs. whether someone was getting schooled out in the hallway.

The session ended about 30 minutes early. I wasn’t sure whether they were out of material or whether they were just flummoxed. Frankly I was glad for it to be over, because it was stressing me out and my treadmill was calling. I’m happy to help, but there’s a level of dread that they might ask me to work with them again. We’ll have to see how the next sprint cycle unfolds for them. I hope if they’re working with other physicians (they had better be, because when you’ve heard one physician’s opinion, you’ve heard one physician’s opinion) that it’s a more successful experience.

Do you have any advice for software vendors who are seeking physician input? Leave a comment or email me.

Email Dr. Jayne.