Improving a website without web analytics may sound odd coming from a data analyst, but its quite a common occurrence for me, and in fact, part of my day job as a website performance consultant.

Following John Ekman’s guest post on the two types of personas he observed in our industry (Conversionistas are from Venus and Metrics people from Mars), I started  thinking about how best to illustrate these different approaches. I consider myself a HYBRID – part conversionista and part metrics person (may be 50:50), and this case study illustrates the conversionista side of my work…

To get started, I guide my approach with two fundamental rules:

RULE #1 – All data of interest should have a theory behind it to explain its significance. If I cannot explain it, or do not feel it is a good use of my time to try and explain it, then by definition that data is of no interest. This is my metrics approach.

RULE #2 – Conversely, not all theories require empirical data to support it. That is, some logically make sense. Proving it with data is a waste of valuable time (and money). This is my conversion approach.

To be clear, web metrics still plays its part in Rule #2 – it measures the before versus the after effect of changes. However, it is not the driving force for change. I do not analyse any data before recommending/implementing the change. Instead, it is an exercise in improving a page structure and visualisation for a better user experience.

The Case Study – using Rule #2 (Conversion approach)

The site in question has a common scenario for supporting customers – visitors to it can submit their support queries via an online form. Staff manage and respond to these via their online ticketing system. The page to be optimised is the “Manage Tickets” area that staff use. This is a key starting page for them before delving deeper into their work load.

The page to be optimised – BEFORE*

Click to zoom

This Manage Tickets page looks benign enough, even pleasing to the un-initiated eye. But that masks some serious usability issues…

*This page is part of the Trellis Helpdesk system. If you use a ticketing system to support clients, I highly recommend Trellis – free PHP software whose business model is to pay only if you require support from them.

The optimised page – AFTER

Essentially, I have worked with numerous HelpDesk systems over the past 14 years – managing clients support requests and billing them for this – so it was straight forward for me to put myself in the shoes of the end-user (the support staff). This is a key part of being a conversionista – its not smoke and mirrors, *anyone* can do it. Its called experience.

In this case, to work efficiently, support operatives needed a clear, well structured ticket summary layout – one that allows them to understand the situation (their work load) at a glance. The following was the result of my changes with the explanations below:

Click to zoom

 

Modifications explained

1. Filter area display by default
   Originally, the staff member had to click this button to bring up the filter area – a key helper when dealing with large ticket volumes (particularly search!). This now shows all the important filter options so that staff do not feel overwhelmed by tickets.
2. Colour coded ticket status – see also 5
   The filter options are colour coded to match the status colours.
3. Added user name
   Odd this was missing in the original. This change stops support staff having to drill in and out of ticket to figure out who is who.
4. Change the submitted time format
   The original was too complicated when it came to understanding how old a ticket was. This was changed to something much more reader friendly. The original timestamp is available by viewing the actual ticket.
5. Colour coded status
   The status of a ticket shows what work is outstanding. This had to stand out for an at-a-glance comparison.
6. Better visual clues
   A common mistake many (many) web designers make, is to have all text appear uniform i.e. the same. Whether it is plain text, a hyperlink, or an important-call-to-action – it looks neater, right? WRONG! It leaves no clue as to what the reader should do i.e. “What do I click on to get more information?”. By modifying the style sheet it is now obvious what is clickable text and what is not – without having to read the entire page to figure it out. Compare that with the original.

If you are a Trellis Helpdesk user, this is all achieved by modifying one file = ad_tickets.php. Feel free to use mine. You can just upload it to replace your existing file (keep the original for backup!)

The results (metrics)

The Martian inside me of course needs to measure the impact of these changes. Putting qualitative feedback to one side, a key quantitative metric is the Time on Page. Normally website owners wish to increase this – the hypothesis being that a longer time spent on a page (or time on site) equates to greater engagement. However in this case it is the opposite – a longer time means confusion, misunderstanding, laborious calculations (“Is that ticket old?”), bordom etc.

So the object is to decrease the Time on Page i.e. a negative goal. The interpretation is, a lower value means it is easier to understand your ticket workload – the support guys/girls can look after their customers more efficiently.

And that is what we found.The time on page almost halved…!

Concluding thoughts

When approaching a website optimisation project for a client, start by considering my two rules:

1. Does the visitor data have a potential theory behind it to explain its significance?
2. Can you improve the user experience significantly by changing the design and structure of key pages?

Which one of these you prioritise depends on what “low hanging fruit” is available. Everyone wants to demonstrate quick wins, and invariably, improving the user experience (rule #2) provides the greatest opportunity – as was the case here. If you use Rule #2, ensure you measure the before and after effect with your web analytics tool.

In a future post, I will describe  a metrics approach case study…

What do you think of my rules for approaching web analytics?

(please note the Trellis modification is not a supported hack).