Ditching bells and whistles for a human-centric dashboard

by

9 September 2016
Jurgen Meershaege of DBS

The first dashboard came complete with all the bells and whistles, and users were "blown away" by its capabilities. However, soon after the initial excitement, interest waned, and Jurgen Meershaege wanted to know why. The search for an answer led eventually to a new codified approach to dashboard design at DBS - one that puts people at the centre of the bank’s self-service analytics projects.

Meershaege, head of Business Analytics and Decision Support at DBS, was sharing the bank’s experience with the use of data visualisation tools at the Qlik event Visualise Your World event in September.

Meershaege recalled how, when he started evangelising the use of self-help analytics at the bank in 2012, the concept was relatively new and the initial response from users was lukewarm. Then all of sudden, as the possibilities dawned on them, he got hit by a tsunami of dashboard requests.

His team had to filter out which requests to deal with, and decided to focus on dashboards that would help with decision making. “If you allow me to sit with you and improve decisions, then we will take on your dashboard. But if you just want us to automate your business intelligence, then no,” he said.  

To play an effective role in decision making, the dashboard would have to be human-centric in its design. “You really have to start with the people,” said Meershaege.

To illustrate this point, he recounted how, in wanting to provide self-help to users during the early days of QlikView adoption, his team created a call centre dashboard that “could solve any problem for anyone”. Six months into the project, however, they realised that call centre operations were not getting much better. The dashboards did not seem to be working.

Pulling out usage statistics, Meershaege noticed that after the initial spike of enthusiasm, the usage went down very quickly. There were also some applications that were never used and some pages that were never even looked at.

Going back to the users, he received some interesting feedback. One of them told him, “On a day-to-day basis. I need to look at three things but the dashboard was not designed such that I see these three things.” Another said, “I need 13 clicks to see productivity numbers. I can go into my email and someone sends me that number every day.”

Meershaege decided that a new approach was needed, and created new teams that brought together design thinking and data science. DBS itself had embraced design thinking a few years earlier, mainly for developing customer journeys, and it occurred to him, “Why can’t we use these techniques for dashboard design?”

Out of that eureka moment came a new codified approach to how the bank now does dashboard design. The process involves identifying the stakeholders, the jobs to be done and the decisions to be taken. A paper prototype of the dashboard is then created and taken into a discussion with the users.

Developing paper prototypes helps reduce iterations and saves time when it comes to coding, said Meershaege. He observed that when users felt that considerable time and effort had been put into producing the paper prototypes, they tended to minimise random change requests.

Another important step in user-centric dashboard development was “think-aloud testing”, which involves asking users to think out loud as they are performing a task. “No dashboard should come with a manual. It needs to be self-explanatory,” said Meerchaege. ”When we show a dashboard to users for the first time, we sit next to them and watch them, and see how they are using it. If they get it right, you have done a good design. If not, it is back to the drawing board.”

There is also a need to track usage for continuous improvement while keeping an eye on the key performance indicators (KPIs) for the jobs to be done. “If we have a call centre dashboard and no one using it and the call centre is not meeting its KPIs, obviously we didn’t do a good job. So tracking is important as well.”

The usage statistics attest to the effectiveness of the user-centric approach. Meerchaege noted that there has been a five-fold increase in the usage of dashboards by putting users at the heart of the design.

From the data science perspective, data visualisation tools like QlikView also play an important role in communicating the results of data science projects to the business. Traditionally, the business intelligence people and the data scientists do not collaborate very much, said Meershaege. However, he pointed out, “At the end of every analytics project you always need to communicate your results – generate reports and create presentations or notebooks where you combine your code and your results.”  

He found that putting data visualisation at the end of the project is “a powerful thing to do”. It enables data to be delivered in such a way that customers can approach the data set from a particular angle. In contact centre analysis, for example, the data scientists could be looking at the segment of customers that contact the centre more than twice a day, to find out why that is happening.

Looking to the future, Meerchaege said he would like to see a different way of thinking about dashboards. “Dashboarding tools are nothing more than a shining shell on top of data. A lot is still left to the user to do the analysis and make the right decisions. With enough intelligence, machines should start telling me what are the next steps that I should be taking.”

Meerchaege envisages a system that is able to learn from super users and advise on the next steps that the bank should be taking, based on an analysis of KPIs and how far these KPIs have been met. “At the moment, many of these decisions are hardwired. We should be looking at how we can use data science to do this,” he said. “Let’s have something that is the equivalent of Google’s ‘I’m feeling lucky’ button.”