Website de-bugging process and tips
Trouble shooting or de-bugging most things is not particularly hard, so long as we have a good process in place. The automotive world uses a process known as the 4 C’s: Complaint, Cause, Correction and Confirm.
First, the error must be reported and a complaint created. Next we need to replicate the issue and determine the cause. We craft a solution, implement the solution, and confirm our solution has corrected the complaint.
This fantastic work flow can be applied to near any kind of de-bugging – with a bit of creative thinking. I approach website debugging with this same model.
The complaint phase is the pitfall of most website debugging processes. Most often a developer will get a call or email which says, “(some thing) doesn’t work”.
The immediate reaction often is – “Can’t be, it always worked before”. Most developers fire up their preferred browser, check the thing, and reply – “Works for me”. Case closed … right?
In order to kick off a more fruitful de-bugging session, we need a better complaint. Developers need to help their clients here. Create a quick and dirty form for the customer to fill out when there is an error reported to them. Don’t get too detailed, but do gather some quick details.
- User’s contact information for follow up questions (name, email and phone number)
- Description of the error, including basic steps on how it was introduced
- If possible …
- User’s browser (Chrome, Firefox, Safari, Internet Explorer, Edge, Safari, Opera)
- User’s device (laptop, desktop, tablet or phone,) and Operating System (Mac or PC)
Most end users will gladly provide this information. They will even appreciate that you care that they had a poor experience on the website. More often than not, they will gladly participate in the de-bugging process.
The client can have this form printed out, and kept in the office. Even better – a digital form the client can fill out and email directly to the developer. Why not automate the process, and have a “tech support” link on every page that opens a form the end user fills out, and is sent direct to the developer.
However you gather the information, the developer will now have much more information to use in order to track the issue.
Determining cause is typically easy if you have good clues to draw conclusions from. A solid complaint form will go along way. As developers, we can bake in de-bugging tools.
A major complaint is contact forms not working properly. Any good contact form should include:
- the URL of where the form was filled
- the date and time of submission
- the IP address of who submitted the form
These details will go a long way in determining the cause of an issue.
What about really long forms (the kind that typically break) or even worse – an online store? Here is where your old friend Google Analytics really comes in handy.
Google analytics as a de-bugging tool
First off, you should set up lots of goals for any website. Set up goals for reaching forms and checkout, as well as for completing the form or the checkout process. This let’s us see how many folks reached the conversion point as opposed to those that went on to convert. Knowing that success rate helps tremendously.
You can go further than that. Break those long forms up into multiple pages, and create goals for each step of the form. Create a goal for each step of the checkout process. This allows us to pin down where in a process there is a failure.
Keep digging into analytics.
Users typically report complaints as soon as they hit trouble, so we can work backward from when the complaint was issued. If we have a good complaint, it will tells us, on this date, shortly before this time, a user encountered an error.
We can then go to Google analytics for that day, and look at the data hourly. By narrowing down the error to a specific hour, we can the use other Google Analytics data to learn more. We can dig out the exact browser and device. We can compare that data to other hours and days, other browsers and devices. This detective work often reveals a pattern of failure we can then correct.
Having tracked down clues, and replicated the issue, crafting a correction is typically easy. Use data to draw your conclusions, and always think outside the box. It was an error that made it to production because it is an oddity, not the norm.
The second biggest failure in most de-bugging processes is that folks stop here. You have to go one step further
The last step is to confirm the correction 1. Actually fixes the problem and 2. Does not cause another issue.
If you have the end users contact information, have them check too. You may need to walk them through the process of clearing their cache, but hey – that’s life.
Not only will this help you confirm your correction, it will also help solidify that user for your client. In turn, your client will be extra thankful for your dedication to fixing the issue for the end user. It’s a win-win situation.