Programmers look at software they’re working on from the inside, but users look at it from the outside. This difference in perspective can lead to different views about what’s important – too often programmers can be consumed by the technical detail and lose sight of value to the end user. In fact, they too often assume that the only metrics worth measuring are to do with the technical side of things, rather than the user side.
An app for ICU patients
A couple of former colleagues were a big part of the team that developed an app for patients in an intensive care unit (ICU). It has a small number of screens, uses an existing 3rd party text to speech library, and doesn’t seem to have much in the way of demanding technical requirements such as 3D animation, tricky integrations with other systems etc. It doesn’t have a big name behind it such as FAANG, a big games studio etc.
So, from one point of view, you could dismiss it as a trivial thing. However, I think that this is a poor way of looking at it. It lets people who are unable to speak, for instance because they are on a ventilator because they have COVID-19, communicate. They can easily say where they have pain, how they’re feeling, and also type in whatever text they need to get across.
Because of that, the nurses and doctors treating them can get a better idea of how they are, and so treat them more effectively and sensitively. The patient and medical staff are less frustrated because communication works so much better than without it, the patient has some dignity restored by being heard, and so on.
In this case, technical difficulty does not equate to user value. In fact, I think this is often the case, particularly for products that are for a particular market vertical – estate agents, the perishable goods logistics business, florists etc. The product could be small and simple, but its benefits could be large if it fits its users’ needs well.
A tangent involving flat-pack garden furniture
I’m going to go on a bit of a tangent here, to get a different perspective on the difference between user value and other things. I’ve recently been putting together a swing seat for the garden. It came flat-packed in a box, with lots of metal parts that bolt together, a bag of nuts and bolts, and some cryptic instructions.
I have got about 70% of the way there – there are recognisable and large bits, but they’re still separate – but progress has ground to a halt. I’ve discovered that two key bolts can’t go on because the remaining nuts are the wrong size. Buying the right nuts will cost probably £1 (plus time, petrol etc.) but the value to me is large, or rather the lack of or delay to value to me is much bigger than the financial cost of the missing parts.
While I’m using a flat-packed swing seat as a tangential analogy for computer things, I may as well continue this tangent a bit further. I realised that the instructions (like many similar ones) take an interesting approach to internationalisation and localisation.
- Internationalisation – strip the instructions of all words, leaving just diagrams with incomplete, confusing and hard to read labels.
- Localisation – err, there is none. Sorry.
One size fits nobody particularly well.
Another way of looking at the difference between user value and other things could be contrasting two things:
- A sentence that starts with It’s just…
- A description from the user of the thing’s value to them.
Here the users are me, John Wick, and Marty Crane from Frasier – more tangents, but I hope you get the idea.
It’s just a bit of metal. No, it’s my wedding ring. It’s one of a pair that my then fiancée and I bought together, that my best mate looked after as part of his best man duties in his usual calm and competent way, that my wife gave to me in the wedding service all those years ago in our church in front of our friends and family, that’s the only bit of jewellery I wear.
It’s just a dog (contains swearing and violence). No, it was the last link to my wife, who helped me out of a world of death into a world of meaning and love. It was her last act of kindness to me, because she didn’t want to be alone.
It’s just a battered old chair. No, it was where I was sitting when big and important things in my life happened, and it helps secure my memories of them.
I’ve worked on systems with tricky technical requirements, and they can be stimulating challenges to get your teeth into. However, it’s important to remember that, regardless of the difficulty of the technical side of things, there’s vital hard graft that needs to be done to do with users. This is the hard graft of becoming aware of user need, then designing around it on all levels – providing the features the user needs, in a way that they find easy to use.
I think that the crux of good testing is Michael Bolton’s definition of bug:
Anything about the product that threatens its value to some person who matters
This highlights three important things:
- Value to people
- Risks or threats to that value
It doesn’t mention (on the testing side): test cases, automation or not, etc. On the building side, it doesn’t mention technical challenge, although knowing about the technical side of things can help if it highlights risks. For instance, integrations with third parties, demanding response time requirements, scale etc.
My job isn’t helping people out of poverty, giving them a home, healing them or developing cures for their ills. But I hope that I can make the world a better place, in only a tiny way, and if you’re in the software business I hope this is part of your aim too. What makes the world better isn’t necessarily big or clever technology, it’s things like people not being frustrated by yet another awful bit of software, that either doesn’t do what it should or is just hard to use.