ET Users

Filed Under (work.BLOG) by WildFire on 21-11-2007

Developers especially freelancers (assuming of course that their corporate counterparts are properly shielded and protected) should not only spend more time error trapping their codes, but also develop measures to error trap themselves from users.

Not all users are that bad of course.

Not all of them are 'nice' either.

And sometimes one not-so-nice out of ten nice ones is enough to pull you and your chi down.

(Note that I'm using 'error trap' and not 'idiot proof'.)

We define 'ET users'' here as not those persons who constantly ask you questions.

We love those kinds.

Even if we are answering the same questions again and again.

(And again in the middle of our coding rituals.)

Even if we have answered them before, created a help file, and posted an online link for that topic. (That we already have given them before.)

At least they're asking questions.

At least they're actually using the program.

Even if they're not reading user manuals.

Our problem lies with users who encounter a simple problem. Whines about it and never contacts us.

Now the problem lies there idle... for months.

The next thing we know the admins are pointing at us for a problem that we weren't even informed of.

To make things more annoying... somewhere in between that span of time we did contact them but received no replies.

(There were also other factors involved like administration changes and staff changes with no proper turnovers.)

So how do you protect yourself from this kind of situation..?

There are a number of ways actually.

One is to LOG.

Log everything... from feature requests... to calls to IM chats to emails and even sms-es.

I remember a year ago we were called because a certain staff claimed that we haven't been doing our job.

So we went there along with our one inch thick stack of chats/emails/sms-es and logs with dates and status reports.

We told them that even though we have complete logs of everything we would prefer to not point fingers and concentrate on solving the problem instead.

This time, partly we are lucky that someone was kind enough to follow up things for us and handle factors that are out of our hands.

Second defense mechanism would involve a maintenance scheme with fair prices that is not dependent on users contacting you.

But we're still in the process of analyzing and testing that part.

We'll keep you informed.