This week I spent my time trying to dig myself out from under a virtual pile of emails. I was trying to make a good start to reach new levels of productivity, but with so many things in progress, that was never going to happen. Maybe next week?
And so, I didn’t get to do anything interesting with data this week. I didn’t build any digital services either. But not all was lost. I got to experience digital public services – a truly demoralising experience! I managed to do some coding with Woody Zuill and Kevin Meadows too.
Contents:
- We need better digital public services
- We should design accessibility for acute disability
- Digital services can be a matter of life and death
- Software Teaming – the experience
We need to make public digital services better.
That is probably true about many of them, but especially in healthcare. We talk a lot about accessibility and user-centric design. In healthcare, they talk about delivering patient-centric care. So how is it possible to create such a monstrosity at the connection of the two worlds?
Not only are the services not very accessible, but they are also used in strange ways. Do you want to register for a GP appointment? You can only do it online and only between 8:00 and 8:35am. You got to the place with an appointment, but you need to schedule another. No, it is not possible to do it at the reception. It has to be done online. But there is no mobile reception inside, so you must go outside in the rain to book an appointment. Who comes up with these schemes?
Eventually, I ended in a phlebotomy waiting room. There were some twenty chairs and just three of us patients. The receptionist
went on a rant about patients not turning up on time or even on the right day. It is not his fault, he says, the patients don’t read or cannot understand the emails. Fair enough. It might not be his fault. But who is responsible for failed communication which appears to be working only for one side of the dialogue?
Human-Computer Interactions with Acute Disability
The problem is even more serious. In services like that, relating to healthcare, standard accessibility just isn’t cutting it. We design and test with users who are long-term sufferers of various conditions. People like that are used to their conditions, have adapted, and know conventions we can use to help them use our services.
But people who need medical help often have a sudden onset of the ailment. They can be distressed, distracted, not at their best. I regularly see people in such situations and see how modern, accessible technology fails us. Last week I was put through the mill myself and nearly lost all my faith in both the digital and the healthcare simultaneously.
And I don’t think it is only me. I heard somebody make a very pertinent joke this week on the radio. The Government Communications Headquarters, the GCHQ, used to recruit code breakers by posting cryptic puzzles in the newspapers. Now they don’t have to. They simply offer jobs to people who manage to get a GP appointment.
It shouldn’t be like that. We must be able to do something!
Good, digital services matter
Digital services and products can be a matter of life and death. Why is it that software with a distinctly 1990s feel is used in emergency services? If a healthcare professional used 1990s medicine, they would probably lose their professional registration. But if they use 1990s IT systems to deliver patient care, that’s OK.
Rant Over. Promise.
Let’s talk about Software Teaming
It used to be known as Mob Programming. A practice where a group of people develop software using a single computer. I tried it before. I really like pair programming. So when an opportunity presented itself, I couldn’t say no. On Friday, I joined Woody Zuill and Kevin Meadows and two others for a 90-minute session of Software Teaming. If you haven’t heard those names before, check out their book Software Teaming: A Mob Programming, Whole-Team Approach.
Besides Woody, Kevin and me, there were two more people on the call. One person who never programmed before and somebody who has done a little bit, but not in the language we have chosen. Nevertheless, by the end of the session, we were programming effectively together. Everybody had a go at coding. Everybody has learnt something.
I have learnt a few things myself. First of all, there is cyber-dojo.org. Don’t know it? Check it out! Second, I have never done pair programming right – not in the strict sense promoted by Woody and Kevin. They say for this to make sense, the idea has to cross from one head to another before it enters the machine. And so the driver does only what they are told by the navigator. Watching somebody code with an occasional comment or suggestion is not enough. The navigator designs the solution, and the driver is executing. They compare it to being a passenger and a driver in a cab. It really works. I want to do it more.
Michał's Blog 