Software user safety: How your software can ruin a
user’s life

I was watching this car commercial on TV. It spoke about how
sturdy and safe the cars were, and showed by a crash test to
reiterate. We are talking automobile driver/passenger safety.
What about software users?

‘What about them?’ you might ask. ‘At least
car drivers have their life to worry about!’ you might
remark. You’re right. Software users have information to
worry about. Information loss is equally catastrophic, now that
computers are mainstream, far from the realms of technologists
and rocket scientists.

Let’s define ‘unsafe’ software
first:

I chose some of the top ten heuristics propounded by Jakob Nielsen. Any
software that doesn’t comply with these (the ten
heuristics) may crash your satellite, result in loss of sensitive
data, or plain simple make you lose your job.

Now let’s examine some of the heuristics as against the
perils of software not complying with them.

User control and freedom (severity =
High)

Jakob Says:

“Users often choose system functions by mistake and will
need a clearly marked “emergency exit” to leave the unwanted
state without having to go through an extended dialogue. Support
undo and redo.”

What it means:

Software that does not comply with this heuristic is unsafe.
Why? If you don’t support ‘undo’ (at least for
crucial tasks) the results could be catastrophic.

Don Norman in his essay Human Error and the Design of Computer Systems says:

“In 1988, the Soviet Union’s Phobos 1 satellite was lost
on its way to Mars. Why? According to Science magazine, “not long
after the launch, a ground controller omitted a single letter in
a series of digital commands sent to the spacecraft. And by
malignant bad luck, that omission caused the code to be
mistranslated in such a way as to trigger the test sequence” (the
test sequence was stored in ROM, but was intended to be used only
during checkout of the spacecraft while on the ground) [7].
Phobos went into a tumble from which it never recovered.

Of course, it was dubbed as of ‘malignant bad
luck’ instead of ‘bad design’.

Recognition rather than recall (severity = high)

Jakob Says:

Make objects, actions, and options visible. The user should
not have to remember information from one part of the dialogue to
another. Instructions for use of the system should be visible or
easily retrievable whenever appropriate.

What it means:

How do you open doors in your office campus? How many do you
push to open and how many do you pull to open? Can’t
remember? Doesn’t matter even I don’t know remember,
but when you get to the door, if you know precisely what to do
that means the door allows you to recognize what to do, to open.
And yea, next time keep an eye out for people who pull when they
had to push or vice versa. Many doors have been broken because of
that. Especially glass doors.

You know it’s an error message the minute you see a
‘X’ encased in a red circle. It is a visual cue. The
red serves as a warning. You just know it the moment you see it
because you recognize it. I have come across software that
don’t display this graphic.

This is just one example; but a very important one. Imagine,
if you were prompted with an error message without the red circle
with the ‘X’ in it? You’d click
‘Ok’ nine times out of ten. Phew! I did a short
survey on contingency design, I found that 6 out of ten users
(all software programmers ha!) never read the pop-up alerts. They
just clicked ‘Ok’.

Help users recognize, diagnose, and recover from
errors (severity =high)

Jakob says:

“Error messages should be expressed in plain language
(no codes), precisely indicate the problem, and constructively
suggest a solution.”

What it means:

‘Java null exception error’ freaks me out. Who is
null? What is a Java? Let me get out of here before someone sees
me.

That’s a layperson’s reaction to cryptic error
messages. My word processor’s favorite is
‘Instruction at 000000×1 failed… dah dah dah’ I
have been using it for five years now and I still don’t
know what it means. But I used to lose data because of that all
right. A software is unsafe if it can’t tell the users what
went wrong, what needs to be done.

Visibility of system status

Jakob says:

“The system should always keep users informed about what
is going on, through appropriate feedback within reasonable
time.”

What it means:

Remember? Those blue progress bars that tell you how much more
to go and how long, when you download stuff from the net? Those
messages that say ‘your request is being processed please
wait’? That is telling the user what’s going on.

I wanted to book a domain name, so I went to www.net4domains.com I chose the
name I had wanted and I proceeded to payment. I gave my credit
card details and hit the ‘Proceed to payment’ or some
other button meant for finishing the transaction. The first time
I hit it, nothing happened. So I hit it again. It worked. I was
so happy that I got my own domain. It lasted only till I saw my
credit card statement. I was charged ‘TWICE’. Yea,
because I clicked twice. The transaction is in dispute now. What
if I was buying stocks or say, a costly book? I know I wont lose
money, but why take away my peace of mind?

Some sites tell the user ‘Hit only once’! but
that’s too flimsy. I mean how can I book the same domain
name twice? Shouldn’t it ask me? In my case ideally the
site should have told me ‘before hand’ ‘hit
once and wait. Sometimes it takes a few moments to fire your
request’ Or some thing like that.

Conclusion:

I am sure by now you know how ‘unsafe’ software
can get to be. And hopefully, you’ll agree with me when I
say, ‘software could ruin my life.’ Let’s hope
software companies realize the potential threats and make
software safer, taking a cue from the car manufacturers.

Leave a Comment