Is being the family tech support person a signal of technical exclusion?

While you’re here, could you take a look at the printer?

My phone was normal before, but it just started doing this weird thing.

I’ve lost the icon and now I can’t get it back.

If you work in technology, in any capacity at all, you know how it goes. If your less family or friends have problems with technology, then you are the one they call. If you are visiting, then you will spend at least some of your time configuring their phones, resetting their wireless network, or breaking the news that their ten year old laptop really isn’t going to survive another upgrade. You will be used to patiently explaining that this prompt to update their OS isn’t a virus and shouldn’t be ignored, but that this email from a friendly person who wants to help make their machine go faster is a dangerous scam and should never be opened.

Providing this amateur tech support may be irritating at times, especially when we often do no more than do an Internet search anyone could have done. (As usual, XKCD has it right.) However, I recently started to wonder whether this continuous need for tech support is a signal of a more significant problem, and one that professional technologists have a duty to address. I think that there is a problem of inadvertent technical exclusion, often born from a lack of attention to the need to create user confidence.

We all have limits of confidence with information technology. I’m fortunate to have worked with computers for most of my life, and to make a living from doing so. I started as an amateur programmer in the home micro-computer era, and I code for fun and to support some local organisations today. Yet I don’t code every day, and I haven’t been a professional developer for many years. Languages, frameworks and programming paradigms have grown up around me. The Open Source movement has bloomed to the point where there are libraries for everything, most of which work, most of the time. This means that, when I try to do something new, I have a world full of resources available to me - yet I still often find them perplexing and baffling. If I have the time, I may spend hours figuring things out. Or I may just follow some online instructions and do some cutting, pasting and tweaking until the thing works - even though I am not quite sure how it works. My limits of confidence are determined by time and familiarity. I am annoyed when they are exceeded, but it does not have a significant impact on my life. I just need to find time to figure things out.

But the limits of confidence may be very different for someone who has not had the chance to work with technology all their life. If someone has no experience of how software is built, has no chance to acquire a mental model of what goes on behind the scenes, then the only thing they have to go on is the interface they are presented with. And, despite the astonishing advances in user interface design since the green screens and error codes of my first paying programming jobs, those interfaces continue to baffle many people. This is particularly the case when navigating several layers of interface to get things done: the application, the physical device, the OS it runs on, the network it is connected to. It’s no surprise that, when we get those calls for technical support, they are either misdiagnosed (‘I think there’s a virus in the printer’) or have been treated by a series of actions learnt by heart (‘I’ve tried turning it on and off again, I’ve reset the router, and I’ve unplugged the cables and plugged them back in again.’) Of course, the actions learnt by heart work much of the time, because resetting a machine will often clear a problem - and following the sequence sometimes just gives the problem enough time to clear itself.

The reason I think that this is an important problem, and one that is likely to grow more significant as more of the world is built out of technology, is what lies on the other side of the confidence barrier. For me, as an amateur programmer who hasn’t had time to get to grips with new frameworks, the world on the other side of that barrier contains improved productivity and new features: it does not constrain my life. For many people with limited technical experience, the world on the other side of that barrier may include access to their money, the ability to pay bills or to travel. It may include communication with loved ones, and connection with the world. More and more of the world is dependent on confidence with technology.

We should also recognise how easily confidence can be damaged. In my case, if I try to install a new module and I get some alarming multi-screen error message, and I don’t immediately find an answer to that problem on the Internet, I may avoid using that module for a while until I can summon the courage to go back to it. But in the case of many people, if they get locked out of their bank account, or end up paying for something twice, or can’t make themselves understood on a video call, they may never use that service again.

I recently argued in a series of articles that professional technologists have a duty to explain. We are building a world out of technology, and that world would be better if more people understood how it worked. Those articles were mostly aimed at professionals who have not had a chance to gain technology experience in their career, but who might make better business decisions with a baseline understanding of how things work.

Reflecting further, though, I think that explanation is not enough. That assumes a luxury of time and inclination that many people don’t have. I also think that we have a duty to build systems that inspire confidence, not just in their reliability, but in the way that people interact with them. The art and science of user experience has come a very long way, there are many great examples of services which are easy and natural to use, and we should give credit to the people working in this field. But, as long as we keep getting those calls for amateur technical support, we know that we still have a problem. And, if we are professional technologists then we should do more than just fix the problem: we should take it as a signal that the systems we are building risk excluding people, and figure out how to include them.

(Views in this article are my own.)