As explained in part I of this series, I have been flailing and floundering in the choppy waters of product discovery the past two years. And just about making a land sighting.
The example I am running with for the purpose of illustration is an electronic medical record (EMR) system for the pet care industry. This hypothetical artefact is for the pet owner, not just for the vet. Also, the EMR system is for those who visit a chain clinic. This isn’t for the neighbourhood single-vet or small clinic.
A case of repetition for emphasis: let me once again state that in addition to the primary user base — pet owners, there would a secondary user base, the vets of the chain.
The behaviour the EMR would be replacing is the clinic emailing prescriptions and lab reports.
Here, in the manner of serialised fiction, I build on the previous post, and start from lesson #4.
#4 There should be one overarching goal governing product design. If you speak to vets, the commonest gripe is that pet owners do not visit often enough. Sure, you could be a cynic and call it a self serving opinion. I used to be a professional cynic primarily for the aesthetic. I am no longer one. Vets genuinely believe frequent checks help catch chronic problems early and help extend lifespan. It is a just cause and lines up with the broad arc of healthcare, which is the move to preemptive. One might argue the arc could even be more germane in the case of our fur-balls of love because, unlike humans, knowledge of genetic predisposition does not make their present jittery.
Every feature decision, every prioritisation decision, every trade off will be informed by this singular — and never more numerous than one, goal. It is important to make the design goal salient to all concerned through endless repetition. It must become the jingle that plays every time you turn on YouTube and must take over your being, burrowing through the ears like good jingles do. When it does take over, the team reflexively defaults to the goal whenever there is a fork on the road.
#5 In circa 2022 you cannot build anything without ML (but ML must play well with every other aspect of product design). About 12 years ago, the idea of embedded analytics entered the staid world of business applications. The goal was modest. Analytics would be presented in the context of ERP workflows and screens. If you were on a procurement module, charts of the vendor’s on-time delivery record would be on the same screen for your viewing pleasure. In context. Analytics would no longer be a place you go to. Context switching hurts productivity, and embedded analytics plugged the air gap forever.
Then came the ML boom. All kinds of hijinks followed. You could find anomalies in customer behaviour, churn risk, signs of disengagement right where you tend to your CRM housekeeping task, logging calls, and tracking follow-ups.
The fundamental expectation from business software changed. It was no longer about accessing a system of record. It was about getting things done, decision assistance in a way that foregrounded the decision enablement aspect of software, with the data record housekeeping aspect rendered table stakes. The vets in the chain clinic would expect the same from a contemporary EMR.
So would a pet parent, without actually knowing what ML is or what the acronym expands to. The warring factions in the global culture wars do not agree on much on the contentious subject of social media. But they do agree a mystical thing called “The Algorithm”, a kind of blood sugar math magic, is both tearing nations apart and lulling us into a stupor of passivity. Consumers have to come to expect an eerie, prescient, almost clairvoyant understanding of what the next step would be, and for the right content to just flow.
Therefore, in circa 2022, product discovery must grapple with how ML can improve decision making and offer the smoothest navigation to the desired goal. ML is the sherpa of customer experience.
Pet care is an unusual domain. You only need a few data points about the furry child — species, breed, reproductive status (whether neutered or spayed or intact), and stage of life. With these data points, one can predict with reasonable accuracy the demands on the owner and the vet in the years ahead. For example, the likelihood of certain chronic conditions is correlated with breed.
Therefore, would the vet care about a risk warning system about the pets under their care? Would the owner benefit from such an alert? What would it take for the alert to matter?
Let’s back up a bit, and recount the previous point about the single goal that should drive every aspect of product design. Let’s say we want to make this system of making both the vet and the owner aware of risks that are in the future. The broader goal of the EMR system is to make healthcare more pre-emptive than reactive. One construct for doing that is the exquisitely timed, personalised to the specific individual, fact-based alerting system.
If the dog breed is large, the risk of obesity and hip dysplasia are high after a certain age. The alert just shows up, both for the vet (s) and the pet owner. For the owner, it is a nudge that is perhaps more salient than the vet reminding the owner in the sagacious voice of the medical practitioner — that frequent visits are important for early detection. For the vet, it helps to keep tabs on a rotating set of jumpy mammals, some that don’t visit often. It is a reminder service for a busy professional, something that might not always be in the vet’s notes.
It is just an alert. But the alert can potentially do a lot. And when one ponders on what the alert be, how it should read, when should it be delivered, to whom, a labyrinthine maze of choices, possibilities, and constraints appear. All for a humble alert!
First, what should the alert look like? How do you strike the right balance between being useful and being dangerously alarmist?
Let’s say the alert is about obesity or hip dysplasia.
For credibility, you might want to add some social proof. Social proof, as any ecommerce UX person will tell you, is everything.
“63% of large dog breeds under our care have had a obesity check in 2022”
But then there are other signals, telegraphing virtues such as authority and the seal of science.
“With weight management, 67% our large breeds delayed dysplasia by one year”
(allow me to add some context here, a one-year extension in quality of life is a big deal for large breeds that have longevity in the region of 8–10 years)
Now, how do you know hip dysplasia is the right warning for a particular patient? It depends on breed (which is easy), ancestry (which is hard, because the owner might not always know), and behaviour (which is much harder to capture).
At a first reading, this is an ML problem similar to recommendation engines in ecommerce. However, in the case of pet care EMR, the ML would only work when we have created the right constructs for ancestry and behavioural information to enter the system and feed the ML model. And, to get to that ideal a bewildering series of product design elements, UX nudges, and ML algorithms must work in conjunction.
Consider the following:
#1 Ancestry has the highest predictive value to foretell chronic conditions. How do you nudge the vet towards capturing family history?
If your Great Dane’s family line has hip dysplasia the changes are high it would happen to them as well. But how does one capture information on lineage? Lineage is of critical importance for a quick triage at the vet’s for an emergency or acute condition. The goal therefore is to have the vet ask the owner about the family medical history as early in the vet-patient relationship as possible.
To make it happen, the ancestry fields must be a prominent part of the screen real estate for the vet.
Medical practitioners are not known for enthusiastic compliance with administrative diktats, and are, famously, tech laggards. The medical history capture process must therefore be as smooth as possible to ensure family history is captured the first time the need arises. It must be intuitive, in an UX sense. Of course.
But there is more, there is ML.
The heavy lifting must be done by auto-complete sort of prefetching of probable cause, based on the other pet attributes known at that point. We know the dog breed is a Great Dane or a Saint Bernard, hip dysplasia (alongside another condition called bloating) must be at the top of the prefetch when the vet populates the field on family history. Information on breed-specific incidence is in the public domain. Information on heritability is in the public domain. Getting the prefetch right should not require much ML wizardry. A basic likelihood score can reduce input time by a fraction of second and make a meaningful difference to how often the vet asks:
“Ah, do you remember if his parents ever had hip dysplasia?”
#2 That was the vet, now how do you make family history salient to the pet owner?
“Family history” needs to be a top-level domain, alongside things one would expect from an EMR, such as lab reports, radiology reports, and vitals. On sign-up, prompts on family history should be swift. The right UX copy (“family history information can be life saving in an emergency”) can make the difference between whether the owner calls up the shelter or breeder, or not.
#3 When and to whom do you send the alert, based on what?
Nobody likes to receive an alert that is irrelevant, or an alert that is an impersonal broadcast.
Therefore, the system needs to have a risk model built in for predicting chronic conditions. This risk model is based on both structured and unstructured information. Obesity is a risk factor for hip dysplasia. A weight check is a standard part of a vet encounter. The ceiling that defines obesity is standard. That is straightforward for a breed. But there are other scraps of information that can be picked up from vets notes.
Large breeds can grow too fast in the early months if fed the wrong kind of food. Standard baby food is verboten for large breeds because pup grub makes them grow too fast, stressing bones and joints. Home made food can have the same effect, because cooked food is unlikely to have the careful nutrient calibration commercial food goes through.
Risks are also of a behavioural nature. Romping up and down the stairs, and running on slippery floors are all risk-factors. If the vet writes “fewer treats” or “less home made food” in the assessment, things don’t bode well for the Great Dane’s long-term hip health. These predictive signals must be corralled into a likelihood score that incorporates all that is known — ancestry and behaviour. It is a supervised learning problem of the classification kind, since the outcome is binary, either the alert is sent, or other).
That was about ML-powered features. But ML should also make ordinary EMR experiences, the baseline EMR features, delightful.
The possibilities here are many:
#1 Should lab reports be summarised?
Summarisation of text is a standard NLP use case, and well researched. As would be expected, nothing in the real world is exactly ‘standard’. There are some EMR-specific issues here. The most consequential part of a lab report is the results section, where a binary categorisation (positive or negative) and/or a data value, and whether it has breached a range, or if the value is in the critical zone. Would a mere extraction of the section be enough? Should the actual data points be retrieved? Should there be a NLG step to summarise the results table in plain English?
This is where some prioritisation calls must be made.
For a chain building a EMR product of this nature, the business case for is to replicate the personal touch of the local veterinary clinic, and — to offer a level of wellness, preemptive care-oriented vet service hitherto unseen. If that goal can be achieved, can the gains in market share justify going all out on customer experience? Or, should one do nothing more than a plain vanilla EMR? Does the typical pet owner even have an expectation around electronic medical records? Is this an overkill? This is clearly a high-involvement domain. The pet is the owner’s child. Would clicking on a report and browsing through all the boiler plate be that much of a hassle?
How does one weigh all of the above against the actual cost of the NLP involved?
#2 How should the navigation pathway be smoothened by ML?
Patterns of usage will differ.
Some, maybe many, will use the EMR as little more than a quick access point for documents, with an eye on not missing information critical for triage on the next visit. Some might treat it as an accessible repository of invoices. In that case, one optimises precisely for that outcome. A no frills, Dropbox like approach to solving a common problem, and not shoving the product team’s self indulgent tech shenanigans down the customer who just wants to be left alone. A timeline UX with encounters, lab reports, and radiology artefacts arranged chronologically, rendered in the low hundreds of milliseconds is all they need. No ML wizardry required here. Perhaps.
Then there is the obsessive parent, who wishes to track vitals (weight, heart rate), go through the meds list, the vaccination list, for good reason, but also as a sort of outlet for anxiety. That outcome could be optimised for as well. It is the equivalent of next-best-action for standard web software, or recommendation engine for conventional ecommerce — all powered by standard-issue ML.
And then there are those who have gone through a prolonged period of crisis. A whole host of artefacts would have been generated — reports, encounters, a rapidly changing med list, and invoices. Perhaps there is a case here for better clustering, or grouping together similar documents. This is possibly of great help at the time of insurance claim filing. In consumer businesses it is common knowledge that a crisis leads to new habit formation. If one can be of assistance during a spell of difficulty, one can preempt churn.
#3 Do a better job making the vet human.
A little matching goes a long way. If you speak to pet owners who absolutely adore their friendly neighbourhood vet, two things become apparent.
First is the warm fuzzy feeling of familiarity with the family doctor. He has known your cutie since they were a pup. The other factor that often comes up is the hyper-specialisation of the vet.
“She too has an Australian Terrier”
“She specialises in small dog breeds.”
A vet in a chain clinic would see a lot of dogs and cats. The vet is humanised if you offer something of the nature:
“Dr. Arnold sees five Australian Terriers regularly, ranging in age from six weeks to 15 years.”
You might not want to actually match vet to pet at that level of specificity. It might not be consequential to any measurable aspect of the quality of care. But the sense of being engulfed by calm is an emotional, not entirely rational, response. These data points, whenever they are available, can be considered.
#6 One must get accustomed to moving levels of abstractions in minutes. On particular team meeting on Tuesday, somewhere around the 13th minute you deal with a question of the nature of:
What is an EMR? Should a self-diagnostic be part of EMR. Should text-based communication?
Would calling it an EMR reduce expectations, which isn’t a good thing. Should we call it something else? What would that new construct be called?”
And around the 28th minute, someone brings up:
“In any encounter should we prominently feature the vet’s name? Or a profile pic? Humans remember human faces very well. Getting to the right document would be far easier, if you make the profile image salient.”
That is a fair point.
How large, the UX person would ask, should the profile be? Should the name and the face of the vet be the most prominent part of an artefact’s icon on the top line? The pet owner might have an imprecise memory of a cholesterol test last autumn, but the image of Dr. Tracy Jones could trigger the exact entry in their mind’s register of events.
You get to the font next (as an aside, UX people really care about fonts). How big should “Dr. Tracy Jones” be? What font is business like, while not being flagrantly business?
Over a 15-minute period the conversation moved back and forth between the very nature of the enterprise, and the size of a mugshot and the font.
But there is more. A team member could bring up the issue of texting vets before and after the encounter. As the discussion goes into the specifics of texting implementation (attaching images?), someone wonders out aloud:
“Do we really want to make the individual vet persist in the mind of the owner? Don’t all chains want to make the individual professional fungible?”
At that point, an intrepid product designer could bring up a point that renders all the low level features decisions taken thus far… kosher for reconsideration.
The intrepid product designer wonders aloud:
“So, the thesis that most modern pet businesses are predicated on is humanisation. Pets are surrogate children. Millennials and Gen Zs wish to defer what an earlier generation considered necessary elements of adulthood. Some perhaps will elect to never go down the route. But the parenting instinct, hard coded by evolution, does not go away. Enter pets.”
But cats and dogs are idealised children. They don’t talk back. They are always happy to see you. There is no teenage rebellion phase. They don’t spend days sulking in their room playing bizarre music at volumes that raise zombies from graves.
Cats and dogs are idealised children. They are supposed to be mostly fun in a way that human children are not, a blank slate on which we can project the most oxytocin-rich ideas of parenting.
If we make the EMR a system that delivers bad news around the corner, a spigot of tumult, is that bad for business? Should we just be a neutral (and far less tech heavy) repository of files and vet notes?
The question of font, and font size might come up immediately after.
Stay tuned for the third and final part.
