CIID 09/10: User Research

So I finally got around to re-writing the project description/documentation for the user research project we carried out at a hospital outside Copenhagen just before the winter break, a few days ago. It was a tough project at the time, and equally tough, albeit for completely different reasons, to write about and describe looking back. The project write-up is here, which is probably as good a place as any to start, so that what comes next makes sense.

[A quick warning, written after the rest of this post. It has become long, and may well not make sense to anybody else. I’m writing this mostly for myself. It could certainly do with a dose of editting, but it’s not going to get it. Also, the pictures are from the project, but aren’t in any order. But pictures are good, right?]

ABOUT THE PROJECT
We were taught by a combination of Brian Rink, who had come over for the three weeks from IDEO’s San Francisco office; Joachim Halse, a design anthropologist and researcher from DKDS, and our own head of programme, Simona Maschi. They decided that we’d be best off learning to swim straight in at the deep end, so after only brief introductions to the discipline (field, area, topic) of design research and ethnographic research in a design context, we were packed off to Hillerod, a medium sized hospital about an hour outside of Copenhagen. Divided into teams of 5, we each took a department, and off we went – having set up a meeting with a senior members of management in our area of interest (in our case, the head of nursing, the head of midwifery, and the head of ‘improvement and innovation’ within the department), we were on our own.

So on and off for the next two weeks, we donned white coats, wandered the corridors and hallways observing, met with midwives and nurses on the ward, spoke with patients and expectant motheres, and discussed amongst ourselves – figuring out where there were overlaps between what we had seen, different directions that were emerging as directions for further study, and specific areas that were clearly pressure points for the various users of the system.

For part of the second and most of the third week, we focused not on researching (collecting observations) or even synthesizing (isolating insights), but on creating something from them (or from whatever we had) – a concept.  A logical next step, positioning the research not as something standalone, but a stage in a process – a design process – with tangible outcomes. It was left up to us whether we wanted to work on incremental or radical changes; products, services, or organisational changes. More on this later.

The tutors were great – each brought their own perspectives, they didn’t always agree, but they all did an amazing job of striking that elusive balance between guiding us through the project and allowing us to stumble and learn. Simona brought her experience of both design consulting and education to the course; Joachim from a more anthropological and academic social-science research perspective; and Brian came with a wealth of experience from both IDEO, and from a previous life, the skills of a diplomat to the table.

A TOUGH PROJECT
Now, for a couple of reasons, this was an especially tough project.
User research is difficult at the best of times, but especially in an environment like a hospital, with all the issues around respecting human dignity, privacy, and major moments in people’s lives going on, all at once. I have been fortunate to have worked with user research while at Radarstation (where we also worked closely together with STBY, who specialise in “social research for service design and innovation”)  but for most people, this was not only the first time they had carried out user research, but also the first time they had properly encountered the idea. So the project wasn’t simply a process of learning and becoming comfortable with the tools and methods of research – observations, interviews, etc – but also building a sense of value in the process amongst team members. Research brings up complex issues, but more importantly, they are often vague, undefined, difficult, and ambiguous issues – and not everybody feels comfortable grappling with ambiguity. Particularily when people come from backgrounds where they are more used to dealing with things being right or wrong, the very human messiness of ethnographic research can come as a bit of a shock.
And finally, inevitably, there was the issue of group dynamics. There were five of us on the team, but for large portions of the project it really felt like there were only two of us fully working on the project… although of course everybody had an opinion when it came to key decision points. There are a lot more rants to be had on this topic, but I’ll skip it here. There is a time and place for that, and it’s not in public. Get me a beer, though…

But c’est la vie, and just part of the fun, right?

SOME THOUGHTS ON THE PROJECT ITSELF
So: some thoughts, looking back.

Overall, I felt we had lots of interesting observations, and also that we synthesized those pretty well into conscise and, from a design perspective, interesting, insights. But tasked with finding room for improvement in what is clearly an extremely well functioning hospital and health system is tough. The hospital was amazing: clean, well cared for, with nice touches all over, both patient- and staff-facing. While I’m sure it wasn’t perfect (no system ever is), whenever staff had complaints I wanted to send them to a hospital in east London – with the NHS an impressive system in its own right, hardly in a third world country! Nonetheless, improvements and concepts were requested, so, always dutiful students, for potential improvements we searched.

We had several concepts, all of them fine, some of them good. The concept we eventually chose, developed, and presented – for better or worse, dubbed ‘Baby Book’ – was fine. But that’s exactly what it was. OK. It ticked a lot of boxes. It covered a lot of ground, it was easily linked back to our research – both at the insights level, but also at the ‘here’s a quote from somebody we spoke to, to prove this is true’ level. All of which is great. But in my opinion – and this is an argument I lost at the time – it was (is) a weak concept. That, if implemented, it could be a genuinely powerful addition to the healthcare services on offer, perhaps more so than any of the other concepts on the table, wasn’t so much in doubt. But the challenges in implementation would be organisational, political – things that, quickly created stakeholder maps aside, are broadly glossed over in an academic (or any other theoretical) context. Beyond that, though, it was a concept that could, all to easily, be extended to include any other insight or observation – basically, it could consume any other concept. Which, ultimately, made it hard to argue against – after all, if the concept(s) I (or anyone else) were included in this one, what was not to like?

A distinction I kept trying to make was between what would be interesting if the hospital was a client who was going to implement our suggestions, and what was interesting for us, as designers, in the context we were working in – as students at CIID. We had the luxury of not having to prove a return on investment to a client. We didn’t have to please anybody – this was no client/consultant relationship. We could think as big or as small – as radical or incremental – as we felt was appropriate. I felt, at the time and looking back, that there were some very strong elements in the concept, but that the outcome was less than the sum of it’s parts. Not because they were poorly implemented, or we spread our thinking thinly (I don’t think we did) but simply because the focus of the project shifted, and many of those small insights got lost, when I think they might have made for projects that, while less far reaching in scope, would have been more simple, surprising, and disruptive on their own. In short, more interesting as projects. Just becuase the idea could perhaps be argued for, or validated the easiest, did not make it the strongest concept, in my opinion.

All this is not to say that the project wasn’t good. We got excellent feedback both from our instructors, two recent mothers we discussed the idea with, and hospital staff themselves. At the end of our presentation, a midwife from the department asked if she could take the prototype with her, and present it to others who couldn’t make it to our presentations – and when it came back, it was with the comment that they were hoping to implement some of the thoughts we had brought up. And yet, despite all that…

ON DOCUMENTATION
Soon after completing the project, we were asked to document it – both for ourselves, but also for the CIID site, where all our projects are documented, archived, and presented. (see that documentation on the CIID site). It’s always a lot of work, but there’s a huge value in all that documentation: for ourselves, for CIID, and for external people interested in what we do here. To ensure a certain level of consistency between the projects, we were given the following headings as a template for our description: “introduction to the concept, context, gathering user insights, design challenges, experience prototyping”. Similar to the final presentations we gave at the hospital, that put the emphasis squarely on the concept, backed up by research findings – not, as I felt would have been both more appropriate given the balance of work we’d done, but also more interesting, research findings which happened to result in a concept. Although I wrote part of that text, I hate it. Not just because some of it just awkwardly worded (it is – that too), but because of the way it skews the project – away from the research, which to me should be the focus of the project, and towards the concept, which, in addition, I wasn’t completely happy with. Note those are two things – even if I had been super happy with the concept, I still think the presentation of the project is the wrong way round.

Why, you may ask? The focus of the course was the research itself: the questions we asked, what we observed, and what sense we drew out of that mass of data. I suppose the consulting term for them would be ‘actionable insights’, and the aim of having us work on a concept as part of the course ensured that the insights were indeed actionable, and added ‘using research’ as a learning outcome as well as ‘doing research’. But I felt it took both focus and time away from thinking a little more deeply about the research, rather than rushing onto concepting, prototyping, etc.. For example, something we spent quite a lot of time on at Radarstation, and I had previously encountered during my brief placement at IDEO was creating frameworks with which the various insights and observations could be conceptualised – a frame on which to hang them on, or through which to see them. Not only was this used to make sense of “the data”, but also for communicating it. Likewise, spending time on presenting the research, as research, was something we didn’t spend time on – mostly, because it simply wasn’t needed within the structure of the our projects, because we had the concepts as tangible outcomes of our research to point at. Personally, I would have found it more fulfilling to spend 3 or 4 days working out frameworks, understanding how they fitted together, finding ways to visualise that, rather than moving directly into creating solutions. We’ve designed answers in most of our courses; perhaps this was an opportunity missed to dwell on the questions a little longer.

A concept will generally take one insight – or, sometimes, just one observation or quote – and build on that. But any research, especially in a context as complex as a hospital, will raise a wide range of issues, with a mulitude of potential design responses. By focussing on just one concept (even one as multifaceted and all-encompasing as ours) means choosing one path, and choosing not to follow others. Which is fine. But by presenting the research through the window of the concept, these other paths become unimportant – relegated and ignored, when they are no less valid or interesting. In many ways, it’s the combination of emerging research questions and findings, that are the hallmark of a user research project, not simply the one finding that is chosen to be taken further.

When it came to presenting the project on my own site, I wanted to re-write it completely. Because, despite everything I’ve written above, I was actually really pleased with the work we had done, I just didn’t like the way it was presented. So I started from scratch, focusing on the questions we asked, the observations we made, and some of the insights we came up with. The concept, and the experience prototyping we did around it, was relegated to just part of a paragraph towards to end. It’s strange, re-reading the new project description, how much happier I am with the project – even though I didn’t re-do any of the work. There are elements that could do with more work, things that got dropped due to decisions taken or a simple lack of time. But even without that, a simple re-framing of the work completed has completely changed my feelings about the project. Sure, you can still get a rant out of me about it, and there are things I would change. But now, for the first time, I’m happy to send people the link, to show them the work.

LINKS

My project description

The project description on the CIID site

The course context and syllabus

The course Faculty: Brian Rink, Joachim Halse, Simona Maschi