So I took my car over to my mechanic the other day and I said to him, "My car's broken. Fix it." And then I left. Imagine my frustration when I went back two hours later and found that he hadn't done anything - my car was the only one in the garage and the mechanic hadn't done so much as pick up a screwdriver. I found him in the office, on the phone to a friend organizing a fishing trip.
What lousy service!
Okay, this didn't really happen. I completely made it up to highlight a point. I wouldn't be able to leave the mechanic without a barrage of questions - simply saying "it's broken" wouldn't give him any direction - he just wouldn't know where to start looking. What's broken? The brakes? The transmission? The engine? The automatic windows? That little thingy on the dashboard that tells you how much gas you've got? And for the mechanic to try to diagnose a problem not knowing where to begin would require checking everything, resulting in much wasted time (and expense).
But we're about computers and websites, not cars, so it's different, right? Nope, it's exactly the same. And, with the advent of email, it's entirely possible for someone to come out of the woodwork, dump an "it's broken" message on the doorstep and then disappear, only to be disgruntled later when they find that the problem has not been resolved.
I've done technical support and it is, at times, crucial to hold the person's hand and walk them step by step through the program to try to resolve the issue. In fact, it's a necessary part of the whole support process. I've never come across the "too stupid to own a computer" scenario (http://www.snopes.com/humor/business/wordperfect.asp - for a little light humor at a pervasive tech support myth) but I have received my fair share of customers complaining "it's broken" and then promptly leaving the shop.
My first response to an "it's broken" message (apart from a cynical "how sad for you" muttering under my breath) is "what's broken?" Remember that many of our clients have come to us with pre-existing sites and I don't know the ins and outs of these sites like I do with the ones that I've developed (and even then it may have been months or even years since I looked at that particular part of the site - do you remember what you had for lunch on the 21st of May, 2002?). Sometimes the site has a third party component (like an Ecommerce add-in, for example) that I don't know back to front, either. So sometimes I need a little hand holding. Here are a couple of tips for reporting problems to help us to help you (after all, that's what we're about: we make time for small business).
Tip #1 - As they said in "The Hitchhiker's Guide to the Galaxy," DON'T PANIC! This sounds obvious - panic is usually counterproductive - but there are other reasons. Firstly, no matter what the problem with your site, it can (and will) be fixed. Secondly, if you panic then, like dogs sensing fear, we pick up on it and we panic. And if we panic we make mistakes (as much as we deal with machines we're only human). If we make mistakes then we might be able to fix your problem, but we could introduce new ones and on goes the cycle.
Tip #2 - What changed? I've had people report problems saying something to the effect of "it was working just fine yesterday and now [you guessed it!] it's broken." People behave this way - one day they'll act one way and the next day, for no reason, they'll act entirely counter to their previous behaviour - and for no reason at all. Computers don't. If it works one day and doesn't the next then something changed. Try to note down everything that could possibly have been different. In entering data into a form it could be something as innocuous as using a different keystroke - anyone who knows anything about the C family of programming languages will tell you that the command "getthing" is not the same as "getThing" (the C family is case-sensitive).
Just to drive home this point, let me tell you a story that comes down through the generations. My father was also a computer programmer (one of the first in Australia) who used to work for that now-defunct behemoth of a computer company called Univac. He told me a story where he and his collegues, on completing a major project, were presenting their findings to their superiors, the customers, some government officials, top Pentagon brass and the President of the Unietd States. They all shuffled their way into the conference room, took their seats - my father proudly fired up the machines and ... nothing!
The audience was asked to talk amongst themselves while they tried, in a panic (and, of course, I've already mentioned where panic gets you) to troubleshoot and finally they had to apologise, promise they'd fix it and the audience left with mutterings of firings and public executions. So they began to troubleshoot again and everything magically started working again. Back came the superiors, customers etc. and they tried for take 2. And, again, everything went dead. Again everyone left to get their Sears catalogs with a mind to purchasing high-powered firearms (remembering that catalogs were the Ecommerce of the day).
Back to troubleshooting they went, but this time they looked for the most minute, mundane details. And, of course, they found it. What changed? The audience. That was the wildcard that these techno-savvy geeks (yeah, my dad's a geek) hadn't counted on. More specifically, one particular audience member and, more specifically still, the weight of this one particular individual. Yes, weight - how heavy he was, as he sat on his chair which happened to be located close enough to a cable so that when this person sat down it provided just enough force to drive a carpet tack into the cable, shorting out the system.
This story (and I'm sure that dad will object to the liberal embellishments that I've provided) also is a good example to highlight the next point ...
Tip #3 - Details matter! It seemed like a minor detail that someone sitting down would affect a computer system, but it was enough to provide the answer to the problem. There is no such thing as too much information when it comes to the computer industry - every minor and mundane detail could be relevant.
Tip #4 - Can you reproduce the problem? There are such things as the so-named "intermittent bug" but I've found that a bug is a bug is a bug and is always reproducable in some way, shape or form. That's why I always ask someone to take me by the hand and walk though what they did step by step, right down to "I got up and got a cup of coffee." Maybe it was the time that the computer was idle that caused the problem. This certainly could be the case where communications are concerned. If you can reproduce the problem then tell us step-by-step, how to do it. If you can't tell us step-by-step what you did.
Tip #5 - Tell us a little bit about yourself. Well, not you, personally (although we do love to be social with our clients), but your computer. I built a site for a client a couple of years ago and she kept complaining that a particular form wasn't showing up. Naturally I went though all of the processes, got a feel for how many times she went for coffee, checked the floor for carpet tacks and so forth, but I still couldn't work out why this was happening.
Now, knowing a bit about how computers and the Internet work, I was savvy enough to ask her what type of browser she was using - Internet Explorer, ok, uh huh (in case you didn't know IE and Firefox have little idiosyncracies that can sometimes cause problems, particularly when dealing with client-side, interactive stuff). Then it hit me - what kind of a computer are you using? What operating system? We'll admit it, we deal pretty much exclusively with Windows PCs around here although we do have a Macintosh for testing. But guess what? The client was using a Mac. On further investigation it was discovered that IE, despite being version 6 on both ours and the client's computers is not created equal. For what I was doing (having a form "appear" after a particular event) required an older syntax in the programming to be compatible with the Mac version.
Tip #6 - Assume we're idiots. 98% of bugs reveal themselves after an update and while we can (and do) try to test extensively, there's a mentality issue here - we're far too close to the program from a technical aspect to see it fully from a user perspective (some programmers will tell you that they always know how their users use their programs, be it a web application or otherwise, but they're liars). So you, the end user, need to test it as well.
One of my former employers once said something that I hold with me at all times: most programmers test to prove that the program works whereas they should test to prove that the program doesn't work. There's an issue of pride here and programmers can be myopic to very real problems. It also happens that a fix in one part of the program can break something in another part of the program.
That's where we rely on you, the user, to go through it and prove to us that we screwed up. You won't be insulting us (depending, of course, on your tone). In fact, quite the contrary, you'll be helping us. This, incidentally, is another reason why sometimes errors only seem to show up after months for no apparent reason - perhaps we did a fix or enhancement to part of the site that affected another part and that other part simply hasn't been used for a while (I do know that some of the applications I've built have features that only get used once in a few millenia).
So there it is - six simple, little steps to help us to help you. Let's recap:
- Don't Panic - We never get tired of saying it: Relax, we take care of small (all our) business
- What changed?
- Details matter - we want it all. Leave "just the facts, Ma'am" to Joe Friday
- Can you reproduce the problem?
- Tell us a little bit about yourself - Tell us about your computer.
- Assume we're stupid - prove that we screwed up.
If you follow these six small steps then we all take one big step towards a trouble-free computer environment which is the best for your business, our relationship and the overall harmony and good kharma of the Universe.
by Mary-Frances Main
