Collaborative sensemaking under uncertainty: clinicians and patients

I've been discussing a couple of 'conceptual change' projects with clinicians, both of them in topic areas (pain management and contraception) where the clinical details aren't necessarily well understood, even by most clinicians. I have been struck by a few points that seem to me to be important when considering the design of new technologies to support people in managing their health:

1. Different people have different basic conceptual structures onto which they 'hang' their understanding. The most obvious differences are between health professionals (who have received formal training in the subject) and lay people (who have not), but there are also many individual differences. In the education literature, particularly building on the work of Vygotsky, we find ideas of the 'Zone of Proximal Development' and of 'scaffolding'. The key point is that people build on their existing understanding, and ideas that are too far from that understanding, or are expressed in unfamiliar terms, cannot be assimilated. In the sensemaking literature, Klein discusses this in terms of 'frames', while Pirolli, Card and Russell discuss the process of making sense of new information in terms of how people look for and integrate new information with existing understanding guided by the knowledge gaps of which they are aware. In all of these literatures, and others, it's clear that any individual starts from their current understanding and builds on it, and that significant conceptual change (throwing out existing ideas and effectively starting again from scratch) is difficult. This makes it particularly challenging to design new technologies that support sensemaking because it's necessary to understand where someone is starting from in order to design systems that support changing understanding.
2. One of the important roles of clinicians is to help people to make sense of their own health. In the usual consultation, this is a negotiative process, in which common ground is achieved – e.g., by the clinician having a repertoire of ways of assessing the patient's current understanding and building on it. The clinician's skills in this context are not well understood, as a far as I'm aware.
3. For many patients, the most important understanding is 'what to do about it': it's not to get the depth of understanding that the clinician has, but to know how to manage their condition and to make appropriately informed decisions. Designing systems to support people in obtaining different depths and types of understanding is an exciting challenge.
4. Health conditions can be understood at many different levels of abstraction (from basic chemistry and biology through to high-level causal relations), and we seem to employ metaphors and analogies to understand complex processes. Inevitably, these have great value, but also break down when pushed too far. There's probably great potential in exploring the use of different metaphors and explanations to support people in managing their health.
5. As people are being expected to take more responsibility for their own health, there's a greater onus on clinicians to support patients' understanding. Clinicians may have particular understanding that they want to get across to patients, but it needs to be communicated in different ways for different people. And we need to find ways of managing the uncertainty that still surrounds much understanding of health (e.g. risks and side-effects).

All these points make it essential to consider Human Factors in the design of technologies to support conceptual change, behavioural change and decision making in healthcare, so that we can close the gap between clinicians' and patients' understanding in ways that work well for both.

Time management tools that work (or not)

Today, I missed a lunch with friends. Oops! What happened?

My computer died (beyond repair) a couple of months ago, so I got a new one. Rather that trying to reconstruct my previous way of working, I chose to start again "from scratch", though of course that built a lot on previous practices. One of the changes I introduced was that I separated my work and leisure diaries: work is now recorded in the University Standard Diary (aka Outlook) so that managers and administrators can access my diary as needed; leisure is recorded in Google Calendar (which is what I used to use for everything).

But in practice, there's only one of me, and I only live one life. And most of my 'appointments' are work-related. So I forgot to keep looking in the leisure diary. Hence overlooking today's lunch with friends, which had been in the diary for at least six months. Because it had been in the diary for so long it wasn't "in my head". Doh!

When I was younger, life seemed simpler: if it was Monday -Friday, 9-5 (approx) then it was work time; else it was leisure time. Except holidays. Keep two diaries, one for work and one for leisure. Easy. But the boundaries between work and leisure have blurred. Personal technologies travel to work; work technologies come home; work-time and home-time have poorly defined boundaries. It's hard to keep the plans and schedules separate. But I, like most people, don't particularly want work colleagues to know the minutiae of my personal life. Yes, the work diary allows one to mark entries as "private", but:
1) that suggests that it's a "private" work event, and
2) an entry in a "work" diary is not accessible to my family, although I'd like them to be able to refer to my home diary.

The ontology of my diary is messed up: I want work colleagues to be able to access my work diary and family to be able to access my leisure diary, but actually at the heart of things I want to be able to manage my life, which isn't neatly separated into work and leisure.

The pushmepullyou of conceptual design

I've just been reading Jeff Johnson's and Austin Henderson's new book on 'conceptual models'. They say (p.18) that "A conceptual model describes how designers want users to think about the application." At first this worried me: surely the designers should be starting by understanding how users think about their activity and how the application can best support users?

Reading on, it's obvious that putting the user at the centre is important, and they include some compelling examples of this. But the question of how to develop a good conceptual model that is grounded in users' expectations and experiences is not the focus of the text: the focus is on how to go from that to an implementation. This is a very complementary approach to ours on CASSM, where we've been concerned with how to elicit and describe users' conceptual models, and then how to support them through design.

It seems to be impossible to simultaneously put both the user(s) and the technology at the centre of the discourse. In focusing on the users, CASSM is guilty of downplaying the challenges of implementation. Conversely, in focusing on implementation, Johnson and Henderson de-emphasise the challenges of eliciting users' conceptual models. These can seem, like the pushmepullyou from Dr Doolittle, to be pulling in opposite directions. But this text is a welcome reminder that conceptual models still matter in design.