How to (Almost) Painlessly Troubleshoot Your Client Sites

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.

The Testing Phase

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 be 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 isn’t Optional

It is a service providers’ job (you) 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.

Understanding the 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, the 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.

Co-browsing: Walk a Mile in my Shoes

Another excellent way to observe user behavior on the website – and at the same time to help them through challenges – is ‘co-browsing’. Two (or more) users can watch the same website simultaneously and each can also see the cursor and actions (such as clicks) of the other.

Websites are rendered separately for each user taking part in such co-browsing and so this functionality cannot replace screenshots. But it can be a huge boon to understanding what and how the user is doing on application to generate the error.

Surfly or Firefly both offer this service.

Surfly co-browsing interface

Cache Headaches

Cached (or temporary) files are often the curse of people identifying and fixing errors on websites. It’s commonly the case that the client sees a different site than the building editing it because the client’s browser is loading their version from a cache rather than the source. The error may have been long fixed but the client can still see it and, quite rightly, is dissatisfied.

Typically the easiest problem to solve is the browser cache – it’s enough to ask the user to empty their cache so their browser can load the most recent version of the site from a server.

Things get more difficult if the website is cached by a proxy server in the client’s company network or ISP. In these situations, you most often just need to wait for the cache to refresh. They are usually refreshed on a schedule.

The third type of caching happens on the server on which the website is stored – but here it’s the person modifying the website who has to remember to clear this type of cache. That’s probably you, a senior dev or your dev-ops person.

When it’s Over

The process doesn’t end when the client is informed about the error being fixed and confirms it. What’s the point of the client being satisfied if we haven’t drawn any conclusions for the future from the whole situation?

Apart from the error itself, you also need to define and remove its cause and protect yourself against a situation where it occurs again.

And if it is the type of error that it can occur again, the whole situation together with the solution should be carefully described and stored in the Internal Knowledge Base (not the user knowledge base).

Tools to manage the knowledge base are part of most helpdesk packages (see above). However, there are also specialized solutions, such as Helpjuice.

Helpjuice example knowledge base

Recap

Fixing website errors can be huge time and resource drain, which is why specialists from all over the world are working to shorten and simplify this process.

Many development teams are recognizing that specialized error handling tools are worth the cost. They are looked, not as a cost, but a source of real savings. Not to mention the reduced frustration involved in a shorter and more efficient process.