Creating Stunning Dashboards with QlikView: Bring real business insights to your company through effective and engaging dashboards in QlikView

Dashboards are no longer tools that are designed exclusively for the CEOs who want to review the financial results of their companies. As more organizations realize the potential behind their data, the conception of dashboards as everyday tools to enhance operations, monitor business processes, and support decision making at all levels has substantially increased.

The first step to create a stunning QlikView dashboard does not have to do with charts or tables. Instead, your initial goal is to define who your audience will be. By knowing who is going to work with the applications beforehand, you can choose the best way to present the data according to their specific needs. So jump into your users' shoes and imagine what they would want to see in their dashboards every morning, what kind of questions they are going to ask, and which visual representations would be the best options to answer them.

For example, if you were working on a dashboard for the CEO of an international firm, you would probably have to avoid enormous tables that show even the tiniest detail of the operations. His strategic role usually calls for a broader view of the company, so this level of detail would only make him lose focus. A better approach would be showing the top metrics that define the company's performance and compare them to their objectives or even industry standards. On the other hand, if you were working on a dashboard for your company's help desk, it would be useful to have not only high-level metrics but also detailed information regarding specific issues and their resolutions. As you can see, picking the correct level of granularity early in the project can save you a lot of predicaments and help you choose the correct language for each audience.

Another example of this concept is the unit of measurement that you select to present the data. The same metrics can have different representations depending on the viewers' perspective and preferences. For instance, the CFO may be accustomed to seeing all the information in monetary terms, while the plant manager (in charge of manufacturing the products) is more comfortable talking about the gallons produced, pallets shipped, or watts consumed.

Building analytical applications is both a social and a technical endeavor. So, if you have the chance, take some time to talk to the users about their everyday needs and pains. After all, any QlikView application should be focused and built around them.

Now that you have identified your audience, you must assess what they are looking for. In this regard, most IT departments rely solely on a requirement-gathering document. However, this method tends to be not only boring but also quite ineffective. These documents are usually generic templates that cover every initiative regarding technology, whether it is about programming a Point of Sales system, creating a corporate website, or changing an email password; so, they typically fall short when it comes to understanding the rationale behind a new analytical dashboard.

To ensure success, you must go further and establish a conversation directly with the users. This dialog should focus on the type of dashboard they are looking for, but more importantly, it should clarify what they want to achieve by using it. By listening to them, you will get a better grasp of the current situation, understand their goals, and—hopefully—be able to provide them with a better solution.

Start by asking simple questions about the process or business unit in hand (sales, recruitment, call center, account receivable, and so on) and the difficulties that they face while executing and monitoring it. For example:

After that, ask them about the application they dream of. For instance:

During this phase, it is also convenient to define the intent of the application. Whether it is to analyze data and foster discovery, present high-level KPIs, or just report operative metrics, each application should be designed differently depending on how it is going to be used. The number of tabs, the distribution of the filters, and the type of objects used to display the data are just a few examples of the elements that might change depending on the tone of the dashboard.

If you establish a true conversation with the users, these sessions could change a phrase such as "we need a sales application" to something much more descriptive, such as "our biggest concern is to achieve this year's quota, so we must keep a close eye on the salespersons' monthly performance". In the end, a deeper understanding of the business needs will always translate into better dashboards and happier users. As you can imagine, the motivations behind a dashboard are quite diverse, but once you understand the true business need, you can act accordingly.

When I talk about this subject, I always remember a conversation I had years ago with the vice president of a financial firm here in Mexico. After reading an extensive requirement-gathering document that left me with more questions than answers, I went to his office to try to clarify the motivation behind the QlikView initiative. As the conversation went on, we reached a point when he defined exactly the application he needed in just a few words. He told me "Julian, I want a dashboard that lets me know who I have to yell at every morning. I will not be the one fixing the issues, so do not give much detail. I just need to know where the problem is and who is responsible for solving it". To be honest, the expectations he had of the dashboard had nothing to do with what the document depicted. Unfortunately, most of the time, you will find yourself in situations like this one, so I strongly recommend you to involve the business users as soon as you can.

The term Key Performance Indicator (KPI) refers to the most relevant metrics that reflect the functioning of a company. They are calculated differently depending on the nature and goals of each organization. Whether you are working with classic indicators like the net profit, market share, and churn rate or new trends such as the number of followers and check-ins, there is no doubt that KPIs are at the heart of any meaningful dashboard.

Most of the time, the metrics you intend to show in your applications are already being captured and monitored. If this is the case, it is advisable to meet with the business unit that is doing it and ask them about the data sources, the frequency of reporting, the most common issues they face, and any other relevant information about the process.

A recurrent problem in big companies is that each department calculates the KPIs in different ways according to the data sources they have available and their particular interests (not always obtaining reliable figures). This could turn into an issue later, so it is better to address it early on by meeting with the appropriate stakeholders and selecting the correct data sources and calculations.

By this point, you should know exactly who your audience is and what they are looking for. Now, it is time to turn into the technical terrain and meet the raw materials you will be working with: the data sources.

Although data modeling is not the focus of this book, we cannot deny the fact that information and its adequate transformation are the foundations of any QlikView dashboard. Therefore, it is important to ensure that you have the appropriate resources available to fulfill the business needs described previously. In this regard, be sure to assess the following elements:

Having a basic understanding of these topics gives you a better perspective of the technical environment and may help you during the implementation of the dashboards.

Additionally, this phase is the perfect moment to bring out your inner data scientist and get your hands dirty. Don't settle for the charts and tables you have been asked for; give yourself the chance to explore the data. You might be surprised by the insights you can get from just playing with the numbers for a few minutes. Some interesting elements you can look at are:

The more you know about the data, the better understanding of the company you will have. In consequence, your analyses will be significantly more robust and derive valuable discoveries for your firm.

Building a dashboard is all about telling a story. The only problem is, most of the time, you do not know how that story will develop. It may become an epic fable of success, great sales, and operational efficiency, or it could turn into a haunting tragedy that depicts customer churn, high employee turnover, and quality issues. In either case, your dashboard should be able to handle it and communicate those insights to the users.

The best recipe is to keep it simple, focus on the key performance indicators, and start building around them. The idea is to create a robust and flexible structure that lets users navigate freely thought the data. As a result, our charts and tables will do all the work, and the story will smoothly unfold before their eyes.

In order to achieve this easy navigation schema, you just have to picture what the user will want to see next. For example, imagine that we are creating a sales dashboard for a worldwide retailer. We decide to start our story with a relevant indicator: the sales figure for this month. As we will discuss in the next chapter, numbers such as this have little value unless we put them in context, so we could opt to make a comparison against the budget or the performance for the same period of the last year, ending up with something similar to the following image:

Now, it is time to take out our Nostradamus cloak and try to foretell what the next question will be. After seeing an increase or a decline in the sales, a user could enquire whether she is dealing with a local phenomenon or whether it affects all the countries equally. In response, we could create a table with the regional performance, such as in the following image:

Once you realize that Sweden has had a rough year, you can turn the analysis towards each store or even take it to the product level; so our dashboard must be able to handle all these scenarios. As you can see, once you identify your audience and understand what objectives they pursue, it is easy to emulate their train of thought and build a dashboard that truly responds to their needs.

Last but not least, enjoy the whole experience! For me, building dashboards is one of the most rewarding activities about being a consultant. It gives you the opportunity to interact with people from multiple functional areas and get involved with intricate business processes. Without a doubt, it is a great opportunity to learn in both the technical and the functional ends.

If somewhere along the way you feel discouraged, just remember that you might not be curing cancer or ending world hunger, but you are certainly supplying your colleagues with better weapons to fight their everyday battles. Building dashboards is a way for you to boost their abilities, help them work smarter, and hopefully, make their lives easier.

Moreover, if QlikView is a new tool for your corporation, you might be fostering a paradigm shift by moving their current decision-making process away from random hunches, preconceived bias, and #YOLO to a more formal, governed, and powerful information-based process.

Just as Quintilian used to say in the ancient Hispania, the truly beautiful is never separated from the useful. While creating a dashboard, you must strive to find the balance between engaging visualizations and effective analytics. Even though most of this book will give you tips on how to make aesthetic charts, do not be tempted to create objects just for beauty's sake.

Sadly, the idea that extravagant dashboards are always great dashboards is deeply rooted in several sectors. In part, it may be our own fault (speaking as a QlikView consultant), as many of the demos we build in the presales process tend to be a little more dazzling than they should be. In our defense, let us highlight that the purpose of those apps is to impress a potential customer and not to analyze data.

For some people, the number of gauges, animations, and overly complex visualizations is directly related to the quality of a tool. However, if an interface is packed with text, shapes, and colors, our brain will be forced to do some extra work in order to pick the important elements and put aside the noise. This will make it harder to interpret the information and ultimately diminish the effectiveness of the dashboard. As a general advice to beginners, try to focus on the functional aspect of your visualization first (the numbers are correct and the message is clear) and leave the embellishing for later.

Paradoxically, the experts tend to fall in this trap quite often as well. Yet, their reasons are totally different. Once you feel comfortable with QlikView's designing options, you tend to skip the conceptual part and jump right into the technical stuff (set analysis, visual tricks, overlapping objects, and so on). There is no doubt you can create certain charts, but take a minute to ponder if you really should. Never forget that if a dashboard fails to communicate in an efficient and effective manner, nobody is going to use it. As Benjamin Parker used to say, with great power comes great responsibility.

Think about the battery icon in your computer for a while. It has an extremely simple design, yet it does its job perfectly. Though it may sound weird, a lot of its features are desirable for a QlikView application. Think about it: it conveys a clear message (how much energy is left), it uses an appropriate language (percentage and time), it looks elegant, and it even alerts you when you are approaching a critical point. Believe me, senior management would kill for a dashboard with those characteristics.

You do not have to look so hard to find simple and powerful visualizations. Take, for instance, your car's dashboard. The designers did a great job of selecting the correct KPIs and the appropriate means to display them (Well, most of the time… I have seen really awful cases). You have the time, speed, fuel, temperature, and even an alarm system that tells you when the brakes need attention, everything presented in just a glance.

Even though complex visualizations can be very powerful, you don't always need them to bring insights to the users. If you can convey a clear message using simple visualizations, such as bar or line charts, there's no need to overload the dashboard with intricate objects. However, be careful not to oversimplify. There is a huge difference between a simple and a simplistic dashboard. If you cut out more details than you should, you will end up with an empty application that lacks substance and will not be able to provide business value. The key to stunning dashboards is always balance.

While creating a dashboard, the more feedback you get, the better the final version will be; so, do not hesitate to ask for opinions. The most successful QlikView applications that I have seen are the result of continuous improvements pointed out by other developers, project managers, and business users. A stunning application is rarely a one-man effort.

Of course, you know your team members better than anyone. You might recall certain users that would be more of a threat than an ally in early stages, but there are other colleagues that may prove helpful along the way. Some of them can help you improve your understanding of the internal processes, share their knowledge about business rules, or even help you with usability tests. In the end, it is up to you to decide who you are going to select for feedback and when to do it.

Regardless of the development methodology you are using, building a dashboard is—by its nature—an iterative process, so you might try several times before landing the perfect dashboard. In this regard, I strongly recommend you to not get married to your first ideas as they may be slightly modified—or completely taken out of the game—in the feedback sessions. Focus on the big picture and remember that ultimately, the result of this effort should be focused around the business needs and not on your personal preferences.