And so we reach the fifth article, which will conclude my series on usability and UX in healthcare. Since we've already covered a lot of ground, to get into context, you might want to check out the four previous posts and then come back here. The previous articles are: Usability, design, and user experience (UX) in healthcare, UX Research in healthcare, UX Design and UX Research for healthcare service prototyping, and Usability and testing of technological solutions in healthcare.
As researchers, we must act ethically. For example:
- Never forget informed consent.
- Gain acceptance or trust from the group. This means that if we are involved in a project from the beginning, proximity to people is important.
- Do not lose perspective, meaning try not to get involved to such an extent that we might, for example, override the opinion of certain users or highlight some users more than others.
It's also important that we avoid some common mistakes such as:
-
Inducing responses with questions that use the same vocabulary as the interface.
-
Assuming that a good testing result is synonymous with sales or adoption of the solution. It's important that, if we participate in a project, even if we have provided feedback and input to the design team and tested prototypes, successful results do not guarantee that people will actually like the system once it's up and running. Usage and adoption depend on other variables such as communication, incentives, or giving visibility to the new service, because if people don't know the service exists, they obviously won't use it.
I want to offer you some advice if you want to delve deeper into everything related to human-computer interaction and service design for healthcare. Some disciplines that may be useful to you are:
- User research, especially UX Research.
- All innovation processes, from ideation to prototyping.
- Digital product and service design.
- Project management and the change process to implement new solutions.
As a softer attribute, it's important to understand the institution's need for speed, without losing the rigor of research and design.
It may be a priority and urgent to incorporate a new system, but that doesn't mean we have to skip steps. So, often we have to negotiate with different internal stakeholders to create the necessary spaces to sensitize people about the different stages of a design process, as we have seen in this series of articles.
These stakeholders are not necessarily the users for whom the system has been designed, but they are fundamental for its articulation in future use:
- Management,
- senior leadership,
- administrative staff, and
- customer service executives.
One way to bring a project closer to people is, for example, by making the process visible, explaining how we got here.
Through the different artifacts we saw earlier, such as user persona sheets, stakeholder maps, and prototypes, we need to make all of this visible. We can also facilitate co-creation workshops where we involve all these stakeholders in the different stages of the process.
Finally, we must link the artifacts with the projects to ensure continuity, because obviously we don't want to research just for these to remain in a report or on a wall, but to bring the project to life and give purpose to all these artifacts.
Designing usable technologies for teams with different needs, perspectives, and motivations.
And we have to articulate these teams around a common purpose.
To conclude, I would like to share excerpts from an article that analyzes why doctors hate their computers. These phrases resonated with me, which is why I will also share my reflections.*
"Medicine is a complex adaptive system: it is made up of many interconnected and multi-layered parts, and it is meant to evolve with time and changing conditions. Software is not. It is complex, but it does not adapt. That is the heart of the problem for its users, us humans."
That is to say, there is a perception that software should adapt, it should stop being complex and adjust to the user, but also to the situation. However, it is not doing so.
"Computerization (...) is all selection and no mutation. Leaders install a monolith, and the smallest changes require a committee decision, plus weeks of testing and debugging."
Despite living in an era of many agile methodologies, lean methodologies, and user-centered design, there is a perception that there is a kind of continuous struggle between the need of people who require speed and adaptation, and these monoliths that, once installed, are very difficult to work with.
"Technology, without a doubt, will continuously increase our ability to make diagnoses, to look deeper inside the body and brain, to offer more treatments. It will help us document everything, but not necessarily to make sense of it."
"(...) Ultimately, we need systems that simplify proper care for both patients and professionals, not complicate it. And they must do so in a way that strengthens our human connections, rather than weakens them."
Perhaps the most important thing in this article is:
- Always think about identifying the target user,
- approaching them,
- understanding their context of use, and
- involving them from the beginning and throughout the entire project.
What did you think of this series of articles? Have you had experience conducting user research in healthcare? I hope this material is very useful to you.
(*) Atul Gawande, Why Doctors Hate Their Computers. New Yorker.
Main image by Leon on Unsplash
Second image by Christina @ wocintechchat.com on Unsplash
By 
