Emotion and software development

I vividly remember an appointment with a sonographer when my wife was pregnant.  On one hand, it was a skilled professional using a combination of acoustic gel, a wand that contained a microphone and loudspeaker, a portable computer that did signal processing on what the microphone picked up, and a monitor that displayed a visual interpretation of the processed signals.  This combination of things was designed, made, tested and shipped, and involved all the management, sales and marketing, maintenance and other activities that allowed it to be in the hands of the sonographer.  This is all true.

On the other hand, it was also one of the most moving experiences I’ve ever had.  Seeing my unborn child for the first time, even in grainy black and white, knocked me for six.  It gave me a huge shove towards thinking of myself as a father, of my wife as also being the mother of our child and love her even more, and because of how I see the world, an even stronger connection to very big and deep things.

At one point the sonographer froze the image on the screen, and used a trackball to mark points on the circumference of our baby’s skull.  This would let the computer work out the size of the skull, and so estimate the baby’s due date.  As the points were being marked I wondered how the last point was going to line up exactly on top of the first, to form a loop rather than a spiral.  Then I noticed the sonographer had a special button to press, which told the machine to join the last dot up with the first dot.

I then had two thoughts in quick succession.  The first thought was “That’s really neat!”, and the second thought was “But my wife probably won’t appreciate that right now.”  (So I bored her later.)  A friend of mine, also in IT, went to the sonographer with his wife when she was pregnant.  He also noticed the problem with joining up the dots and the special button as its solution, and so also had the first thought.  Unfortunately, he didn’t also have the second thought.  His wife made it quite clear how far down her list of priorities were discussions of user interface design.

It might be that you design or build ultrasound machines – if so, thank you.  It might be that this has been a very painful article for you to read.  Parenthood, or its absence, can wound important core parts of someone in ways few other things can.  If this describes you then my heart goes out to you and I realise that my words will probably be feeble and useless.  I hope that you will excuse me while I continue to ramble about computers and emotions.

More common case

I realise that ultrasound machines are a rare and extreme example.  Much of the time, emotion doesn’t feature prominently, if at all, in building software.  If we’re lucky, it will appear in things like customer journey maps.  We don’t usually have a requirement to help our user feel a certain way – it’s to accomplish a task.

Note that I’m not talking about emotions we feel during the development of software (that’s important and valid, but not the subject of this article).  The kinds of thing I am getting at are taking pride in your work, being fed up with customers or management etc.

In that context, I think that like imagination, emotion relating to our software (and not the development process) is something we shouldn’t ignore.  This is both for our own benefit in terms of motivation, and also describing how the software should be or how it’s falling short of that.

Emotion can be there if you think about it

In the past I worked on a large project for a mobile phone company.  There were lots of things to do and keep track of, and lots of people working on it at once.  I found it helpful to think that I was helping people to use the phone to say “I love you”.  (They could equally be saying “you’re fired” or “don’t forget to buy some baked beans on your way home”, but those are less motivating).  I realise that it can be unhealthy to attach too much emotion to your work, but a little can help.

You might be thinking “I just write utilities to convert files from one format to another”.  Maybe someone’s used another program to digitise a Super 8 holiday movie shot by an elderly relative, and the digitised movie is in a format that can’t be played on the old person’s tablet.  Maybe your utility will make this movie playable by converting it to a different format, and happy memories will be refreshed.

Non-functional requirements – where emotion sneaks in

I encourage you to remember the last time you felt anything other than neutral about some software.  I hope it was something nice, but I fear it was more likely to be something like:

• Why is this site still down? I really need to book those tickets before they sell out.
• Is it that you’ve taken my payment but you’re just being slow, you’ve taken my payment and crashed, or you haven’t even taken my payment but then you crashed?
• Will you just hurry up? I need to get the address before I lose my mobile signal.
• Where is the page where I can edit that bit of information? This stupid system doesn’t let me do it here, which is a sensible place.

These were failures of availability, scalability, performance and usability.

These are all non-functional requirements, which are too often the poor relation of functional requirements.  They can be poorly specified (e.g. the system must be easy to use), they can be hard to test, they can have diffuse but widespread impacts on the system, and they can combine in unpleasant ways with other requirements.

Maybe it would be more helpful to express non-functional requirements in terms of emotion, such as the system must not make the user worried, bewildered, frustrated, angry, annoyed, feel stupid or incompetent etc.  These are hard to measure, and I can’t remember seeing any system specified in this way.

However, unless your system’s talking to another system that has a stopwatch somewhere enforcing timeouts etc, precise and more measurable performance targets are likely to be merely the means to an end.  The end is likely to be something such as the user isn’t annoyed because they feel that the system’s slowing them down.  (I think that performance isn’t the only area where the non-functional requirement is merely a means to an end.)

Intrinsic vs. extrinsic emotions

As far as you’re concerned, emotions the user feels will be a function of:

• The user
• The task they’re trying to do
• The tool they’re using (your software)

So, maybe a user is happy to be booking some flights because that will get them to a loved one’s wedding.  Or maybe the user is dreading booking some flights because they’re terrified of flying.  Neither of these involve emotions that are anything you can influence or be held responsible for.  For want of a better term, I’ll call these intrinsic emotions.  They are a function of just the user and their task, and so it’s hard for the user to do that task without those emotions being involved.

There are other emotions, which I’ll call extrinsic emotions, that you can influence and could be held responsible for.  They are what arises when the user and their task encounter the tool.  Depending on how this goes, there might be no extra emotions.  That is, the user accomplishes their task with the minimum of fuss, barely notices the tool, and moves onto the next thing.  On the other hand, things could go poorly and so the user ends up frustrated, where they were happy before they started using the tool.

The classification into intrinsic and extrinsic might seem backwards to you, but that’s probably due to a perspective that has the tool in the centre of things.  (Surely emotions that involve the tool are the important ones?)  However, it’s important to remember that the user and not the user interface is the star of the show.

If you refer back to the ultrasound example, the vast majority of my emotions were intrinsic, and only a tiny part (the “that’s really neat!” part) were extrinsic.  The main thing was meeting and checking on the health of my unborn child, and the ultrasound scanner was just a means to that end.

Conclusion

There are some reasons why users of our software might be feeling certain emotions that we need to be aware of, but aren’t responsible for, because the users bring those emotions with them when they come to our software.   The emotions that our software provokes in a user can be a warning sign that the software isn’t up to its task.  In fact, emotion, or the lack of bad emotion, is probably what many non-functional requirements are trying to reach for.