ServiceTick Filters — Case Study

ServiceTick Ltd, July 2017

The context of the filter and date range dialogues

PROBLEM

The filters interface was the result of unplanned growth over several years. The layout had become cluttered and hard to navigate.

Some features, such as the ability to save a set of filters, were under-used. Indeed, some clients had even requested this as a new feature, despite it being in plain sight right next to the ‘Apply filters’ button!

To compound matters the technical side of returning the filtered data was slow, becoming a potential threat to the next stage of the company’s development.

The date range picker had it’s own quirks, making it time consuming to select remote dates. In order to select a whole day, users had to select up to 1am the following day, as midnight is ‘technically’ the next day.

ACTION

I undertook a usability review of the interface, and found that users had to move their mouse to every corner of the interface to perform even the simplest filtering operation. Actions such as saving a set of filters did not happen on the interface itself — rather, the user was redirected to a separate page.

I then devised a survey that would go on every page of our console. This would segment users according to the user personas that I had previously set up, and ask simple qualitative questions about their use of the interface.

This gave several insights, particularly about consolidating the different ‘types’ of filter that we had. Over the years, different filtering mechanics had been added to the product, but this had not been done in a coherent fashion. Different types of filters were applied in different ways, and their interfaces differed in subtle and impenetrable ways.

‘How often do you use the refresh button?’

The most surprising for me was the use of the on-screen ‘refresh’ button. This added nothing to the browser’s own ‘refresh’ button, or the f5 key. It seemed superfluous and I was convinced we could be rid of it. Not so, as most users reported that they used this button either ‘frequently’ or ‘all the time’!

We invited respondents to the survey to participate in a beta-testing group. This came to two dozen people, who were first presented with our initial design prototypes.

I used Invision to create a clickable prototype, which we sent to the beta-testers with a second survey to complete. Results were promising, with most users rating the overall look and feel as 4/5, and the ease of use as 5/5, so we pressed on.

Time was then invested to develop the validated design. When this was ready we gave the beta-testing group access to a live version of the interface, for them to use with real data. There was a variety of feedback from this round of testing. Testers were clearly committed, as we had some quite specific responses relating to uniformity of font sizes, label content and button text. We were able to take this on board and modify the design to arrive at the final outcome.

OUTCOME

The new filters dialogue

I used the feedback we had gained from real users at each stage of the journey. For instance, at one point we had an ‘advanced’ options toggle, which people tended not to see. It was removed so that all options are visible at once.

We kept the ‘refresh’ button!

The different types of filter were consolidated into one interface (which provided a number of technical challenges). We have a mechanism whereby specific data-sets can be ‘pinned’ to your dashboard. Previously this was appended to the main filters as an icon. Now it was a first-class citizen with it’s own dialogue.

The flow of the user’s mouse was paid special attention. It is possible to complete filter selection, even with complex criteria, within two to five clicks, and by only moving the mouse 100 pixels to the left or right.

The saving of selected sets of filters was brought front and center, with a mini-user flow right there in the main dialogue. This was contextual and only appeared when required (when clicking on ‘save selected filters’).

The main call to action was given a much more prominent position, with secondary calls to action given a smaller or completely muted visual presence.

The new date range picker dialogue

The date range picker was given a similar overhaul, with a range of preset dates sited between the dialogue toggle and the main call to action.

The number of calendar months viewable was upped from two to three, and these were intrinsically linked — previously the left-hand calendar had been for the start date, while the right hand was for the end date. Needless to say, our users found this confusing.

A new control was added, allowing users to ‘use whole days’. We then took on ourselves the problem of what to do about midnight — rather than let our users suffer for this technical hindrance.

RESULT

A new survey was provided for all users of the system to give their views on the changes. Feedback was very positive. One experienced user commented that ‘it was like going from a Volvo to a Ferrari!’

The technical limitations of the system had been demolished with our new approach. Consolidating all the types of filter had required a ground-up rewrite of the underlying code, providing an incredible performance boost. What used to take 4/5 seconds to return now came back within 100 milliseconds.

Querying our database shows that usage of saved filters is up from 17% of all accounts to over 32% in the two months following the launch, showing that users are finding it easier to use the interface than previously.

Most importantly, the new interface has sown the seed for wider changes in the UI, and around how our users interact with our data in general. For example, providing different default views of data to the different types of user.

Thanks for reading. Share if you know someone who may appreciate this article. Follow me for more design-related stories.