Dispositions and timings
As part of our work reviewing service display, we’ve been spending some time looking at how we display dispositions and timings to users.
A disposition is a string that consists of:
- the type of service NHS Pathways wants you use
- the timeframe in which it wants you to use it
Looking at how we display these strings is part of a larger overhaul of service display. The display of dispositions and timings requires direct clinical input around risk — something that’s not always quick, but something that’s invaluable in an urgent care setting.
Why do we need to look at dispositions?
Mismatches in service names
A disposition could specify an “emergency treatment centre”, while our directory of services could quite easily return services called:
- Emergency department
- Urgent care centre
- Accident & emergency
So we’re presenting a directive, but the services we show as meeting that directive may not name themselves in the same way. We should be able to avoid this layer of confusion.
Excess precision in disposition timings
Using very precise and directive timings across the board could add confusion.
In high acuity dispositions (needing help within 4 hours) we believe confusion around timing is less likely. However, we also have low acuity timings such as “within 5 working days”.
What’s the definition of a “working day”? What if the recommended service is only open 2 days a week? What if it’s open weekends?
We should be able to direct users in a much more human way that allows for variation in how we describing timings in relation to acuity.
What’s changing?
At the moment we basically print to screen a pathways disposition. That’s a string that reads (for example) like this:
Go to an emergency treatment centre urgently
You should go within the next 1 hour
Our new string would simply read:
Get help now
We’ve removed the mention of a specific service type. Given when we display a service, we display its name, the obvious decision is to remove the service directive from the disposition.
We’re saying “Get help now” as opposed to “You should go within the next 1 hour”. There’s a couple of lines of thinking here:
Not every service available will be a physical service. There can be remote validation of dispositions, as well as services like telephone crisis lines. It’s highly likely in the near future non-physical consultations for some dispositions will become more commonplace. So saying “You should go” will not always be accurate.
We want to be able to convey timing in a direct and human way. So “Get help now” is simple and direct. A low acuity example, such as the “5 working days” mentioned above would read:
Get help within a week.
Our next steps for this piece of work will be to generate a set of example service display pages and test them with some quick popups. We’ll be looking for comprehension and people’s descriptions of what the timings might mean to them.
Mulling over T
We’re in the process of implementing our agreed minimum viable journey. During implementation small issues and clarifications to designed journeys and views always crop up. There are things that can’t be caught and dealt with up front. Whether that’s a technical issue, a case or scenario we haven’t captured, whatever. Agile working enshrines this uncertainty, and allows us to cope with it far better than a waterfall style.
However we often find ourselves in retros bemoaning how we could have spotted things if the whole team is involved throughout a given piece of work. Out of these retros we’ve consciously moved towards a more open and inclusive way of working from the get go, with group sessions and reviews.
But I think no matter how involved a team can be in the genesis of a feature, it’s unrealistic to think that we can catch everything quickly. I think it’s something to do with the “T” shape everyone’s always banging on about.
That horizontal bar in the T means you can get involved in most aspects of a digital product team and add real value. But the vertical bar is where you’re really doing your job. Within the vertical bar, you’re taking on the responsibility of your expertise. You’ve got the focus of the task and the heightened attention that requires. There’s inevitably a difference in how you approach a feature that depends on whether you’re in horizontal (wide) or vertical (expertise) mode.
Having “T” shaped team members and trying to work openly means there’s a lot of product or feature awareness at any given point, but I believe it’s to be expected that new ideas and problems appear throughout the process — and continue to do so after release, when things like analytical expertise come into play.
No revolutionary thought-leading solutions here I’m afraid. Just beard stroking.