Tagging, Analyzing and fixing errors reported by clients is a delicate matter and not always the most pleasant stage of the web design process. Today, I'd like to give you a little of your life back by showing you how to simplify and shorten this stage as much as possible.
Testing
While internal testing should always remove the vast majority of bugs and errors in a website or application, a small percentage of errors can only spotted by the client or their target users.
There are simply thousands of combinations of environments (i.e. device, operating system, browser, plugins, configuration etc.) used by web users. The reality is, no software or method can guarantee a 100% error detection in the test phase.
Furthermore, there are some user behaviors that are so advanced or plain peculiarity that they are practically impossible to predict. As such, the aim of internal testing is simply to dramatically reduce the likelihood that an end user will come across an error.
This likelihood is never zero and errors reported by users do happen - then you have to cope with them as efficiently as possible. In such a way that the client won't perceive the whole situation negatively and won't be dissatisfied.
Communication
It is service providers' job to adapt to the client and, as such, the client should be able to use a communication channel of their choice. If they like calling, you can't force them to use email. The more channels that are available, the better - a telephone, email, ticket request system, chat or possibly an instant messenger popular in a given branch.
With a large number of users and, consequently, a large number of possible service requests, ticket request system and knowledge base are indispensable. The former will let you control numerous requests, users and consultants.
The client doesn't even need to be aware they are using a ticket system - their request (by email, telephone or chat) is simply given a number which will help track the issue.
The knowledge base is a developed FAQ with an intelligent search system. It makes it possible to relieve the consultants of some requests - typically these are the issues that repeat most often and are always answered the same way. The knowledge base will be used by the kind of user who prefers clicking to talking.
What is key in communication about errors is the time.
Firstly, a response to an error report should be sent as soon as possible, so the client feels that their problem is being dealt with immediately. An automatic confirmation from the ticket system is a solid start, but an answer composed by a human being will be much better.
Secondly, the person who reported an error should be kept informed about the progress with fixing it. If the process is protracted over several days the client ought to be contacted every day and informed about its current status and the estimated time of completion.
And as much as possible, the number of people contacting the client should be minimized. In an ideal world, this would be one person. Switching between contact people while a single problem is being resolved is one of the most frequent causes of users' frustration.
These are some popular ticket request systems: Zendesk, Kayako, Freshdesk and UserVoice.
User environment
As I mentioned earlier, there are countless environments used by web users - varying devices (computers, tablets or smartphones), screen resolutions, OSs, browser brands and versions, configurations and plugins - and small things can have huge effects.
To resolve the issue you'll need to know everything you can about the user's system. However getting this information can be difficult and puts a lot of responsibility onto the user. So, how do you determine their system specs?
A typical yourbrowser.is browser report
Fortunately, there's an application called yourbrowser.is that can help. It allows you to create your own checker page free of charge. You only need to send your client a URL and ask them to click. The moment the client opens the page, a report is generated about their environment and sent via email to the owner of the checker page (together with the parameters that can include, for instance, full name of the client).
What Are Your Users Seeing?
Even a full report on the user's environment isn't always enough - an obscure configuration is often difficult to replicate. That's why screenshots are often indispensable. But once again - not every user is able to (or wants to) take and deliver a screenshot - especially on mobile devices.
Usersnap is a great help in these situations - a comprehensive suite for facilitating error handling. It's built around one unique and very useful functionality, i.e. generating screenshots without the user installing any additional software or plugs. It's enough that the widget is installed on the page in question.
Usersnap website feedback interface
In fact, Usersnap doesn't take a real screenshot but instead generates one by simulating the environment of a given user. The user can easily make their own notes - mark the error location, describe it or even draw something - on the screenshot taken by Usersnap.
Going one step further, you can try to video record user's actions. Applications such as (e.g. Screenr) do offer this functionality, but it will be necessary for the user to install a local application (at least Java) and agree that a plug like this is run. This could be too much of a friction point for many.
Continue reading %How to (Almost) Painlessly Troubleshoot Your Client Sites%
by Konrad Caban via SitePoint
No comments:
Post a Comment