In October 2019 I had just started as a product manager at accuRx. I’d read lots of books and taken several online courses, but my knowledge of product management was limited to a theoretical understanding of what I was supposed to do. From this limited research, I recognised that one of the things I wanted to up skill myself on was how to make user-centric decisions so that I could understand how our users wanted to interact with our software. I had experience working with healthcare providers in the past, but I’d never spoken to a GPs with the intent of understanding their relationship with technology. As well as learning how to understand the mindset of users, I knew I would also need to develop an acute awareness of the challenges current health-tech faced as a whole, and to then use this awareness to work towards better, more innovative solutions.
Atul Gawande’s article “Why doctors hate their computers’’ offers great insight here.
At accuRx, our users are busy healthcare providers who don’t want to spend too much time with software — they just want to use it enough that it helps them spend more time caring for their patients. This means that for everything we build, we strive for it to be simple, satisfying, robust, and inclusive. Given these goals, coupled with the fact that our users are typically a little less tech-savvy, we skip the keyboard shortcuts and custom settings. Instead, we go for smart defaults and clear processes.
In my first six months at accuRx, I did everything I could to spend time getting to know our users. I spent countless hours on the phone with users asking them questions about how they wanted to interact with their computers. I travelled back and forth across London to visit GP practices in order to shadow staff as they worked with their current technology. Our team brought in users for live demos and conducted interview sessions with patients in the office. On average, I would interact with at least 10 unique users every week so that I could get a wide range of perspectives on what our users were thinking. Not only did this time with users give me confidence in the decisions we were making, but it started making it possible for me to more credibly stand up for our users in internal meetings with my team or with leadership.
When the COVID-19 pandemic hit the UK in March 2019, this in depth user knowledge meant we were able to mobilise quickly to build out helpful solutions. In a matter of weeks we had built an easy video consultation solution on top of our existing SMS service, provided a structured questionnaire to assess a patient’s COVID-19 risk and exposure, supported a workflow for GPs to request patient photos to assess physical ailments, and supported these same GPs to send fit notes to patients via SMS. These remote-first care options were adopted by GPs across the country because they were simple, available, and accessible, which was necessary for them to continue a high level of care for their patients in this new remote world. accuRx was able to play a key part in changing the way GPs in the UK used technology to communicate with their patients in only a few months. I know I could not have played my part in these rapid and helpful decisions as effectively as I did if I hadn’t spent the previous 6 months dedicated to understanding our users.
Read about accuRx’s role in the COVID-19 response in the UK here.
User research avoids wasted time, money and effort
Spending time doing user research is one of the most time and cost effective investments a product team can make. This may feel counterintuitive at times, but it’s about going slow now in order to go faster later on. Once things get committed to code, adapting quickly to new learnings or challenges becomes considerably more difficult (and expensive).
Having a dedicated user researcher is great; but they shouldn’t be siloed off from the rest of the team. As a product manager, I try to be involved in at least one user research session per week (now mostly conducted over Zoom or similar). Our team is also encouraged to get involved, and most product engineers appreciate getting first-hand insight into how users are thinking about our software.
Using online solutions, we now have a relatively low-barrier way to learn and test with our users which means more of the team can get involved more frequently. Part of this process involves the user sharing their screen with us and us watching them navigate through their existing technology (discovery). Another part of this same process can be us sharing designs or clickable prototypes with the user and giving the user remote control to try it out themselves (design validation). Both of these activities provide so much insight into the challenges currently faced and how intuitive our suggested solutions are, thereby saving us so much time in the long run by helping us catch issues early and fixing them while they are just pictures, rather than a fully fledged product.
User research taught me to be the voice of the user
When building products, there are so many micro-decisions that make up the final version. These decisions are often design-related (both user interface and user experience) in terms of things like button placement, item colours, hover states, or copy. Therefore, if the product manager really understands the user’s workflow, these micro-decisions made when deciding on the journey created in the product will lead to the product being much more aligned to what the user is trying to achieve. The key to this game is understanding the user’s intuitive way of wanting to interact with the software.
User research helped me understand what users need (not just what they say)
Users are brilliant at identifying the problems they are facing, but it is important to be wary of the solutions they suggest. Users tend to lack the bigger picture that you and your team has available, so use their input to guide your solution, not define it.
One of the first products I worked on at accuRx was a structured questionnaire that GPs could send to their patients to assess their asthma. The patient responses to these would code back into the clinical system, saving GPs time (and helping allot to the practice’s annual revenue). I was conducting research with a varied group of users, and one GP at a rather large practice told me, in no uncertain terms, that her practice would absolutely not use the questionnaire unless I added a very specific question. Concerned that our questionnaire wouldn’t get used, I put in the question verbatim as she had told me. Not a week later, another GP told me the question I had put was far too specific and wanted a slightly more generic version. I realised that the first GP would probably have been happy with a more generic question as the latter GP had suggested, and decided to open up the question phrasing to a wider group of users before making a final decision.
If you simply fulfilled every request any user has, soon your software could become a Frankenstein of features that don’t get used. Being really involved in user research meant that I was able to learn to differentiate between what a user was saying, and the underlying needs they had. With this skill, we are able to build more holistically simple software that fulfils necessity but doesn’t create complications.
Read about the differences between what people say and do in Mathew Sander’s article on “Simulated realities, distorted realities.”
Just over a year has passed now since I joined accuRx, and our team has grown so that we now have full-time user researchers. Even though I have taken a bit of a back seat to conducting user research myself, I am still very much interested and involved in the ongoings of our research findings.
As I continue to learn and grow in my role, I am also getting more involved in data analysis, running A/B tests, and small and medium scale tracking metrics over time. These skills will bring my product style in another direction, as I learn to read the behaviour of our users in a yet another way.
What is your experience understanding user needs? Would love to hear any thoughts in the comments!
