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.