(Actually, due to other work pressures and a weekend on call I'm completing this and releasing it on Monday, but 'Full Stack Monday' does not have the same ring to it! ;) )
One thing I've learned as a consumer is that no matter how good the tool is, if it's clunky to use, poorly designed, or just a bit crap, it will drop further and further down my recently used tabs list until it eventually drops off into the void of suggested autodelete.
(and rarely then does it ever come back, much like that place in Supergirl, because when I'm asked to confirm if I want to save its life, I can't remember what it did anymore)
So clearly it is an important part of development, as I harped on back here: Full Stack Friday! (doctorsthatcode.com). Even more so for new developments in the healthcare setting. Too long have we all suffered in an era of front ends that appear to have been developed in the early 90's for Internet Explorer NT, or whatever.
After recently speaking to a fellow sympathiser, clinician & developer Dr. Nick Ting, we both agree that even with some of the newer tech coming through, particularly for EHR (Electronic Health Records), design and useability still seem to be an afterthought. Hello, Windows 98.
I thought we'd managed to ditch you.
Sadly though, we can't just let this drop off into the void and autodelete... much though we wish we could. Especially when the trust spent around half a million quid on it.
So... Let's talk a bit about designing our front end to avoid this pitfall in the future.
To quote Alan Kay, the best way to predict the future, is to invent it :D Awesome.
Crack on then, design my front end
Well, not quite yet. You see, one of the many barriers to entry into the healthcare system is showing that your device solves a problem using evidence.
This evidence is not limited to the tool or underlying problem, but evidence that the look and feel of it is right for the users as well. We've talked about getting doctors to try out your tools and that's very much what Adopt-A-Doc is all about, however - many of today's developments are patient-facing.
This requires a new type of evidence beasty. For those within the research realm, you may have heard the term PPI group.
(And no, thankfully we are not talking about 15 layers of plastic and painful masks!! As a shoutout to those fellow doctors who were conscripted to ITU in the first wave of the pandemic when we all thought we were going to die, this is my throwback photo)
Even though this picture has been heavily stylized you can still see the look of "Oh shit" in my eyes.
So PPI groups, what's that then?
PPI groups in healthcare for digital devices, are collaborators who help researchers design, conduct, and share research that involves digital tools. The groups are usually people who have experience or interest in the topic of the research, such as patients, service users, or members of the public. Great stuff, sounds useful.
So in the context of the digital product you're designing, you're going to want them on board. This message was made quite clear to me during my recent PhD proposal - (which is a patient / doctor facing application).
The professor had written the comment in bold, which made me somewhat embarrassed and realise I had fundamentally fudged an important part of the proposal "WHERE IS YOUR PPI GROUP DISCUSSION?!". Oops.
PPI groups can provide valuable insights and feedback on how to make digital tools more useful, accessible, and acceptable for the intended users. So get them involved early, and listen to what they say. Because if they ain't buying in, no-one will.
Right then, how am I going to find or use a PPI group?! Do they cost money. Help!?
For those of us in the UK, there is a pretty good summary of how we should be using PPI groups from Health Innovation in Wessex: Click here for PDF
It's a good resource, as a summary:
It's an evidence-based guide for digital health innovators on how to involve and engage patients and the public in the development, implementation, and evaluation of digital health technologies.
The guide is based on a collaboration between Boehringer Ingelheim, the AHSN Network, and the University of Plymouth, and draws on a systematic literature review, stakeholder engagement, and case studies.
The guide presents four categories of principles for meaningful patient and public involvement and engagement (PPIE) in digital health innovation: Engage, Acknowledge, value and support, Communicate, and Trust and transparency. (Sounds pretty sensible eh, as principles go?)
For each category, the guide provides key learnings and challenges, an illustrative case study, and a checklist of recommended actions for innovators to follow.
The guide aims to help innovators develop patient-centric and inclusive digital health technologies that meet the needs and expectations of the end-users, and facilitate their adoption and spread across the health system.
So all really sensible stuff, and if you're serious about developing a patient-facing application, this needs to be on your to-do list.
It would be NICE to have a bit of extra help with PPI stuff
Of course it would, and of course we do! :D
The NICE (National Institute for Health and Care Excellence in the UK) has a lovely guide on PPI too, so check it all out.
PPI Ready, lets get Devvy!
Before we go into the technology of development, let's think about how we might put this bad boy together on paper. Start with a plan.
Form follows Function (Or should it?)
The principle of “form follows function” is a design philosophy that originated in architecture and industrial design. It suggests that the shape of an object or building should primarily relate to its intended function or purpose.
In the context of digital health design, this principle can be interpreted as designing digital health products that prioritize functionality over aesthetics. Clearly, this has been the case. But does functionality not include useability? Or is that what is missing in the design process, attributing to many headaches and the detriment of healthcare workers' user experience?
If you do some searches on the question “Should form follow function in digital health” you go into a merry-go-round of perspectives and preferences which sort of sound like chicken and egg. For example:
For: Form follows function means that the design of a digital health product or service should be determined by its purpose and functionality. This can ensure that the product or service is effective, efficient, user-friendly, and accessible. It can also avoid unnecessary features or elements that may distract, confuse, or frustrate the users.
Against: Form follows function may limit the creativity and innovation of digital health designers and developers. It may also neglect the aesthetic, emotional, and social aspects of design that can influence the user experience and satisfaction. Moreover, the form follows function ideology and may not be applicable to all types of digital health products or services, especially those that have multiple or complex functions.
(But surely to be effective and user-friendly, aesthetics and ease of use are as important - but perhaps I'm missing something here?)
When we start extending into the realm of patient usability, arguments come forward stating digital health apps that help patients manage their medication should prioritize ease of use and accessibility over flashy graphics or animations. By prioritizing functionality over aesthetics, digital health designers can create products that are more effective and user-friendly.
Get to the point Sam! Yeah, sorry. So in summary, ultimately these days we have to blend the two together, it has to be pretty, and user-friendly, whilst also providing a clear function. Your PPI group will help steer you on this front. As for building it, thanks to a lot of effort and work by the many tech wizards out there, we have a lot of front-end frameworks that mean it isn't that hard to achieve this blend of awesomeness.
Right back to the face of the matter. Yes, UI/UX design.
A quick round of definitions to get us started:
User Interface (UI) refers to the screens, buttons, toggles, icons, and other visual elements that you interact with when using a website, app, or other electronic device. UI design is all about creating intuitive, aesthetically pleasing, interactive interfaces.
User Experience (UX) refers to the entire interaction you have with a product, including how you feel about the interaction. UX design is all about identifying and solving user problems.
UX design usually comes first in the product development process, followed by UI. UX can apply to any kind of product, service, or experience; UI is specific to digital products and experiences.
If we build it, they will come...
( Well, build your User Experience (UX), then the User Interface (UI) will come out of that.)
This is a useful stage to put a bit a lot of thought into, and as you map what you're trying to achieve, the UI will sort of be born out of it in a natural symbiotic process.
Know and define what your product needs to do. Sometimes you might realize you're trying to do too much.
Sometimes you realise you're not actually fixing the problem you set out to fix.
Often in the NHS, we are digitizing an already existing pathway, sometimes this can accidentally overcomplicate the process.
Perhaps taking a step back from the system, and thinking of the bigger picture is what is needed.. For example, you might realize that If I fixed 'step A' up the chain, perhaps this broken rung at 'step D' wouldn't even exist anymore, let alone need fixing.
In any case, understand who your users are and what they need. This includes patients, doctors, and other healthcare professionals. I can only speak from experience, but using tech in the NHS I can tell, (as can my colleagues who I've heard say through frustration- the person who designed this has clearly never had to use it!!) I'm sure we've all been there trying to use a bit of kit and being shocked at the number of steps needed to achieve something simple.
It's like when you get stuck on one of those automated phone services to pay a bill, and by the time you've entered all the digits to continually tell them you just want to pay a bill, which you specifically told me this number was for, you've got a handset that looks like this: "#1211112111231
(I'm looking at you Student Loans Co.)
Finally, At every step, keep the focus on creating a user-centered design that meets the needs of your users and provides a positive user experience. I think it needs to keep coming back to that principle.
That is where your PPI group or the early users of your system will become gold dust.
Right, I'm ready. Let's start building this.
Next step is to decide on our front end stack / framework / tech setup.
Do your homework on REACTJS, FLUTTER, VUE, ect... or just tune in next time so we can start building this thing and I'll do the chat about the above.
Thanks all and stay Awesome.
Comments