Alan Dix recently put out a call for top tips and resources that could be passed on to research students at this year’s British HCI Doctoral Consortium. Although the main conference has been cancelled, the Consortium will run as a virtual event on 6th July. This set me thinking about the lessons I’ve learned over the years, having worked in both industry and academia, and having moved from Computer Science (at undergraduate level) into Human Factors (several years later, at post-graduate level). Probably the most important thing is the need to get out more.
After obtaining my PhD, I was lucky enough to spend all of my academic life working with people from outside of HCI, and from outside of academia. At the University of York, I was part of the Interdisciplinary Research Collaboration on the dependability of computer-based systems (DIRC). This was a large, multi-site undertaking (Newcastle, Lancaster, Edinburgh, City and York) involving people from Computer Science, Psychology, Sociology and Statistics. We spent the first few months trying to come up with a common language that we all could use, and failed miserably. This taught us one very important lesson. We realised that each discipline has its own language and meanings, often based on a culture that has been developed over many years. It is therefore a near impossible task to come up with a new lingua franca for everyone to (willingly) adopt. The most important thing was to realise that when a computer scientist uses the term event, it doesn’t mean the same thing as when a psychologist, or a sociologist uses that term.
After the DIRC project finished, I moved to the University of St Andrews, where I worked on the Large Scale Complex IT Systems project—which was also interdisciplinary—and a follow-up to the DIRC project. Both of these were also multi-site projects. In addition, I managed a project which involved working with a number of SMEs as they looked to migrate their products and services to be delivered using cloud computing. This latter project built on some of the work that had been carried out on the LSCITS project.
When I say academics need to get out more, I mean both out of the office (or lab) and into the real world, and out of their own discipline. Let me explain more…
Getting out into the Real World
Neonatal Intensive Care
As part of the aforementioned DIRC project I did some work with the staff in the Neonatal Unit at Jimmies Hospital in Leeds. This involved regular project meetings as the work was part of one of their projects to develop an expert system to help junior doctors (in particular) to make decisions about ventilator settings for premature babies. If you get the settings wrong you can give the baby brain damage (through a lack of oxygen), or make them go blind (through giving them too much oxygen), or give them a punctured lung (if the pressure of the mechanical breaths is too high). During the first few meetings the medical staff would talk about things like PIP and PEEP and PO2 and auscultation, and it all sounded like a foreign language to me. After a few months attending the meeting, doing background reading, and asking questions, it all became much clearer (this process is sometimes referred to as bootstrapping into the domain). In addition to doing the work to get up to speed, it also became clear how important it is for systems to be acceptable as well as usable. The unit had previously developed an expert system for neonatal intensive care which had won an award from the British Computer Society. The system quickly fell into disuse, however, because it required staff to spend too much time entering data and getting results, rather than focusing on caring for the sick babies.
Assistive Technologies in the Home
We also did some work on telecare, investigating how people use assistive technologies in their homes. It is only when you see people really using these devices in their daily lives that you start to fully appreciate the issues involved. Several people had a fall monitor, for example, which could be used to trigger an alarm that would be detected by the carer call centre. They would them contact the person who had fallen to see if everything was all right. The devices were designed to be clipped to a belt, so the first issue is that many of the women we spoke to did not wear belts., so they had nowhere to put the device. The second issue is that even if someone did manage to wear it, the device often went off when the person bent over.
Getting out of the domain
Paediatrics and Child Health
The neonatal work described above, led to several articles being published. The medical staff were particularly keen that my part of the project was presented at their main conference (the annual event of the Royal College of Paediatrics and Child Health). This conference is attended by people who are medical doctors rather than experts in usability or UX. In order to make sure the presentation would be interesting and comprehensible to the target audience, I rehearsed it beforehand with the staff from Jimmies, on their advice, to make sure I wasn’t using and buzz words or jargon that would be meaningless to the audience.
Safety Critical Systems
I also presented part of the work to the Safety Critical Systems Club’s annual symposium. The members of this club are mostly hard core computer scientists who are interested in real-time computing issues, and building the tools to support the development of real-time control systems for aircraft, for example. Although my presentation was about timing issues, it was coming much more from a human factors angle. I was the 13th presentation at the 13th symposium, what could possibly go wrong? As it turned out, nothing! It is always worthwhile paying attention to what people say in their presentations when you are attending a conference outside of your own domain. There may be one or two hooks that you can use to make an extra link to explain how or why your work is of interest to them.
Command and Control Systems
Some time later, when working at St Andrews, I had a similar experience when presenting a paper on high frequency (algorithmic) trading to a conference on the theory and practice of automation in command and control systems. Before submitting the paper I contacted the organisers to make sure that the paper would fit—we were exploring what high frequency trading could learn from aviation—and to understand how we may need to adapt it to make it be interesting to the regular conference audience. I was also involved in reviewing papers for the conference, so I had a better understanding of what to expect from the conference.
Finally, I was invited to give a presentation about cloud computing to student members of the Chartered Institute of Management Accountants (CIMA). CIMA are keen to give their student members a rounded education about what they see as important issues. This was another case where it involved doing background work, and talking to the organisers to try to understand the audience.
The BIG Take-home Lesson
To slightly paraphrase Atticus Lynch (in Harper Lee’s “To Kill A Mockingbird”):
You never really understand a person until you consider things from their point of view… until you climb inside their skin and walk around in it.
Getting out more is really all about empathy.
Building computer-based systems (whether it’s a simple app, or a highly complex supervisory control system for a nuclear power plant) is an interdisciplinary activity. There aren’t many polymaths who are expert in all of these disciplines, but by spending time and effort to talk with (not just to!) people from other disciplines you will (a) learn more about what they do, and (b) learn more about what you do.
At the end of the day, you will almost invariably be making something that another person will use. So it also makes sense to go and talk with(!) those people, and see what they do, and how and where they do, because these will all have an effect on how successful your product (or service) will be.