Long gone are the days when a couple of spreadsheets and simple charts were enough to analyze data and make discoveries. With a tidal wave of information coming from data warehouses, transactional databases, application logs, mobile devices, and social networks, companies urgently need better ways to process, organize, and consume the data in order to create tangible value.
However, how do you build dashboards that are not only robust but also engaging and easy to use? Chances are that you have already acquired an analytical tool to do so, and since you are reading this book, you have made a wise choice in selecting QlikView. However, a great tool does not guarantee your success in this endeavor.
Before we dive in and start creating bar charts and scatter plots, it is vital to understand the context around our applications. The true objective of a dashboard is to tell a story, to let the user explore the data, and ultimately to provide insights that lead to good business decisions.
Throughout this book, we are going to share some best practices, tips and tricks that will help you build outstanding dashboards that truly respond to your company's information needs. In this introductory chapter, we will discuss the following topics:
The role of dashboards in your organization
Defining your audience and their needs
Handling business requirements
Creating the perfect dashboard
Even though multiple authors have elegantly defined what a dashboard is, the industry still has an abstract—almost mystical—conception about them. One thing is certain: they are a means to display information. However, if they are well designed and adequately delivered, they can do much more than that.
It is vital to understand that a dashboard is more than just a couple of charts and tables packed together. It is a tool that helps users navigate freely through the data and shows them things that cannot be seen otherwise. They transform simple data into useful and elegant visualizations that help companies gain a better view of their performance and allow them to make better decisions.
Building a dashboard is not an easy task. It requires a great understanding of the business, a lot of creativity, and a robust set of technical skills. However, most of the time, the developers are so absorbed in the tools, calculations, and data sources that they forget the true nature of dashboards: supporting the business.
We will start our journey by defining some phases that will help you understand the business environment and devise a strategy that will ultimately lead you to creating a stunning dashboard. These are not intended to be strict norms that must be followed by heart. Instead, they should be seen as general recommendations that will guide your efforts in the right direction.
The six steps that will help you to start your dashboard initiative are:
Define your audience.
Spot the business need.
Choose the right KPIs.
Get to know your data sources.
Tell a story.
Enjoy the process.
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:
What is the primary objective of the process?
Who is involved? Are there third parties?
Is there any specific problem you are facing nowadays?
How do you evaluate its performance?
Do you have a defined goal/budget/quota?
After that, ask them about the application they dream of. For instance:
What KPIs do you want to see?
Which filters do you need?
Do you have any preferences regarding the visual representations?
How often do you need to update the data?
Do you have all the data sources needed to calculate those KPIs?
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.
Choose only the most relevant metrics and avoid using KPIs that no one understands. If you think that there is a new KPI that should be included or an old one that should be taken out of the picture, communicate it to the stakeholders. Some companies often keep indicators more as a tradition than as something that adds real value to their analysis. On such occasions, an external point of view can help them fine-tune their ideas and envision a better dashboard.
There is a moment in a company's life when analyzing every chunk of data is important. However, having dozens of KPIs just because you have enough data to calculate them is not worth it. Just try to imagine the head of the HR department opening a dashboard in the morning and yelling, "Oh my God, the percentage of left-handed employees in our legal department is alarmingly high. We must take action!". This example may sound a bit extreme, but you get the idea.
In this regard, you must work side by side with the users to select only the metrics that really matter. There's nothing wrong with having a dashboard with only two or three KPIs as long as they are useful and have an impact on the business.
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:
Associations: Load the data into QlikView and take advantage of the associative model by analyzing the relationships between the fields (green, white, and gray have never been so useful).
Cardinality: Familiarize yourself with how many products, employees, and suppliers the company has. It can give you a better perspective so that you can choose the right charts for each scenario.
Rankings: Is there an element that is consistently at the top of the lists? Who is the best salesperson? What is the best-selling product?
Distributions: Discover the shape of the distributions of some metrics. Do all our stores have the same margin? Do we have certain territories where the employee turnover is higher?
Trends and fluctuations: Time to create a calendar and check if we deal with a seasonal market or a random one. Are our stocks going up or down? What is their rate of change? Are they slow and steady or fast and volatile?
Correlation: Is there a correlation between the customer's age and the average ticket? Or maybe between the types of materials we are using and the production scrap?
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.
QlikView offers a great variety of visual elements ranging from simple tables to mesmerizing gauges. However, the effectiveness of your applications will depend to a large degree on how well you apply them in each particular scenario. Remember that without the appropriate means to communicate, even the most robust model is nothing but a set of numbers. In the same manner, any visualization—as fascinating as it may be—will turn out to be worthless if it is based on incomplete or incorrect data.
Building a dashboard lies somewhere between an art and a science. If you want to succeed in this endeavor, you must take the best out of each world. From the art department, you must bring some creativity and innovation in order to make your application aesthetically appealing and encourage user engagement. From the scientific field, you must resort to disciplines such as computer science, mathematics, and statistics to produce meaningful representations that lead to insights.
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.
In this introductory chapter, we reviewed the role of QlikView applications in the organization and shared some tips on how to start your adventure of creating a new dashboard. The six steps portrayed in this section will help you focus on what is important by giving you a 360-degree view of the business context. If you apply them consistently, your understanding of the company will improve, and your applications will be more valuable.
In the next chapter, we will review how to apply the best practices from all-time design gurus such as Stephen Few, Edward Tufte, and Alberto Cairo in our applications. It is going to get really interesting, so read on!