Most companies believe that they know their users well, but let’s be honest, continually researching your user’s actions and understanding their real wants and needs takes time and effort. But the diligence of truly understanding your customer and completing intensive research before a line of code is even written can pay off in the long-term, with not only user buy-in, but by engendering user excitement about an application that doesn’t just meet their needs, but also understands and fits into their life.
Whether your product is a mobile fitness tracker, a patient portal, or a clinical application; understanding and building into the application your user’s experience is key to developing a successful, usable solution.
Ready to Get Started?
Keeping your application’s goal in mind and your designated end-user, you’ll want to first identify the research questions you want to be answered. Once you know what kind of data you are looking for, you can review the section on research dimensions and dive into each section to see what data gathering techniques would benefit your design. Answer the question: Which one would give you the best data and open up your application in new directions? Keep in mind that you’ll likely need to use a couple of different research methods to get the data and insights you are seeking.
Once you’ve decided on your research path, you’ll also want to carefully review the paths to understanding your customer. It offers several options for building out and illustrating your customer’s potential use of your application. It may seem at first glance like an unnecessary step (you have the research / data, why bother with creating a picture?) but formatting your research into a cohesive map or storyboard can help synthesize your data. You’ll find it easier to focus on critical elements and can remove “clutter” within your research and data. Often laying out that journey or story also can expose interesting opportunities for improvement, and not just as it relates to software applications, but to the overall process and customer service as well.
Ask Yourself One More Time: Who is Your End User?
When developing for a clinical setting, developers often focus on the needs of doctors and nurses. Given that their actions directly impact the quality of patient care, that makes some sense. There are, however, other groups of users who either directly or indirectly use a healthcare application. These can include hospital / clinic administrators, physician-run-office workers, and physician or independent researchers. As well, doctors often drive changes, their voice can carry the most weight and they either influence or directly request the development of an application. As a result they are sometimes the only ones contributing to the requirements. When the software is released it can fail to deliver a clinical process improvement because it does not deliver what all end users need. Software teams need to consider direct users in addition to those who benefit downstream from the data collected by the application. Be sure to have a healthcare usability expert to assist with stakeholder identification. They can help identify and model the range of direct and indirect users, groups and institutions that contribute to — or will be affected by — a change to clinical processes.
For example, a departmental clinical triage application is used directly by doctors and nurses, but contains information that is useful to administrators. These types of applications receive referral requests, implement policies that set priorities, and schedule patient visits. Clerks and nurse managers use the application to publish and organize patient lists for any given day. When the cases are completed, the user marks them as closed and enters any relevant remarks. Physicians, on the other hand, use the system to consult on patient cases and details. And because all cases go through this system, it can also be a useful management tool for reporting on patient volumes, case types, wait times, and cancelation numbers. With a solid understanding of all potential users and their needs, the software development team is better positioned to deliver relevant, useful software that solves the problems of the healthcare organization as a whole.
Also, always keep in mind that there is no “typical” user, typically. Aim to identify the most prevalent personas and then determine the primary personas and their associated usage scenarios for your application. Make designing for the primary personas the main priority while still keeping in mind the needs of the secondary personas. Solutions that try to cater to more than a handful of personas tend to be “watered-down” and fail to address the most important needs effectively. Many poorly designed electronic health record systems, for example, try to please 15 different physician specialties but end up not meeting any individual doctor’s needs. As with EHRs, patient software also needs to provide real value to a few specific, but prominent, groups.
Don’t worry if you’re not sure who your additional stakeholders are now, the research you undertake to understand your user, will often expose additional stakeholders and help you draw out hidden interconnections before it’s too late.
Download The Complete Guide to Engaging Digital Health Software