[MUSIC] The first thing you need to think about when creating a dashboard is your audience. What are their expectations? What is important to them? Before beginning with any dashboard, we need to understand our core requirements. The key message here is to determine the most important question or questions that the dashboard should answer, as well as, any corresponding key performance indicator or KPI's. Remember, that all of this needs to be approached from the viewpoint of the audience. Next, we need to determine whether the data is readily available, and if it is, how to gather it. Finally, we need to construct a key message that shows our understanding of the audience needs as well as their technical background and knowledge. For example, a dashboard for a product manager will likely have a different focus than a dashboard for a CEO. The audience is going to dictate the type of dashboard that needs to be created. Once you understand your audience, you can move on to selecting the dashboard. There are three primary types of dashboards. Executive, analytical, and operational. Executive dashboards contain high level information in summary form and usually cover a long time horizon in order to communicate key organizational trends. We frequently see these in general managers, CEOs, and other core executive offices. This type of dashboard can help provide live insights into the business. And help them identify how and where to focus their time. It can also be used to communicate corporate performance. Analytical dashboards are typically more detailed, and used to facilitate further ad hoc analysis. Teams use these frequently to explore the datasets that may be too complicated to review at the detailed line item level. Operational dashboards usually cover shorter timeframes in order to focus on specific operating goals. We see these frequently in operations where they're used to measure output and other key operational KPI's. Once you have selected the type of dashboard that you need, it's important to use the principles of design. There are five principles that are intrinsically linked together. The first design principle is balance and proportions. This refers to the distribution of the visual weight of the object's color, texture, and space. Essentially, how are we utilizing both the working and the open space for each dashboarding component. The second design principle is emphasis. Which is pretty much the opposite of balance and proportions. This refers to how we bring attention to what is most important or what should be read first by the audience. The next design principle is repetition and consistency. This refers to how we can use similar elements to elicit unity and consistency across the dashboard. This makes each component feel connected, and ensures that the reader remains focused on the overall message instead of getting lost in the individual elements. The next design principle is hierarchy. This refers to how the design of the dashboard can help the reader understand the hierarchy of the different objects, which in turn, helps enforce the message of the dashboard. As mentioned in the previous courses, data should always be used to deliver a message. And the correct hierarchical design can help structure the message more effectively. The fifth and final design principle is functionality. This refers to the functional requirements that need to be met by the dashboard. These requirements are typically based on the audience and include things like having drill down capabilities to enable the user to further explore the data. It's essential to make sure the dashboard is functional, that there are no software incompatibilities with the end user and that the navigation is intuitive. These five design principles should always be considered together and we want to make sure that we integrate and respect each of them as much as possible, but without sacrificing the other four. For example, we wouldn't want to build a dashboard that is 100% balanced. Since this will likely ignore the principle of emphasis, taking away from the overall message of the dashboard. We'll get a better feel for these design principles, and how they are linked together, as we look at examples of dashboards, and then start to practice building them within Excel. To help showcase what not to do when creating a dashboard, here we have a bad example. As you can see, it's difficult to determine which controls refer to which graph. The color scheme crowds the dashboard and the chart proportions imply that revenue by category is the most important element of the business, which isn't necessarily the case. For example, we might be equally interested in seeing the revenue by category and the revenue by sales channel, so that we can see the correlation between the two. In addition, the chart on the right contains a trend line that doesn't seem to be adding much information. To summarize, we risk confusing the end user with this kind of dashboard because we have not guided them through the components by using design principles like hierarchy and repetition. This example shows a different way of displaying the same data as before. This time, the principles of design were kept in mind while designing the dashboard. Hence, the components are balanced, logically grouped, and the charts contain relevant information without extraneous gridlines and borders. With this view, the most prominent feature of the dashboard are the charts, and they are clear and concise. This version of the dashboard tells the story behind the data efficiently and concisely. Notice, that we have two primary components to the dashboard, one dedicated to the sales channel revenue and the other to the revenue by product category. Within each component, we have the same design, creating a sense of unity and balance. The buttons at the top allow the user to interact with the graph and display the underlying data in a variety of different ways. If we think back to the bad example we just looked at, this dashboard clearly contains a lot less guesswork for the end user. Additionally, the story reads clearly from top to bottom and the components are easy to navigate. When building dashboards, it is important to think about each of the individual components. When deciding on these components, we need to ensure the key message of the dashboard is prominently displayed by putting it in the highest priority position. As you move through the dashboarding process, ask yourself, whether each component serves a specific purpose and answers the key question you found during the requirements gathering phase. Present metrics and measure that can influence management decisions and policies. Unactionable information should only be used sparingly. When you are designing and developing a dashboard, it's essential to consider how it can be maintained and updated. It's worth it to spend time upfront to build enough flexibility in the dashboard, so that it can be updated with new data using minimal effort. During the requirements gathering phase, it's important to understand how often the dashboard will need to be updated and how it will be updated. For example, if the data requires frequent updates to remain relevant, it might make more sense to consider building in a direct data feed that allows the users to update the dashboard regularly. If, on the other hand, the data is pretty static and will require minimal updating, it might make more sense to rely on a manual update process. Remember to always include a timestamp on a dashboard that is not updated dynamically, so that the audience is aware of when the data was last refreshed. We also want to make sure we consider how often our requirements might change going forward. If we expect that the requirements could fluctuate in the future, we may want to leave some functionality out, if we think that it could impede our ability to make future changes. When you're done building your dashboard, and start to think about delivering it to the end user, always make sure to take some time to confirm the dashboard addresses all the questions and requirements that were collected during the requirements gathering phase. Review each component of the dashboard with the key message in mind. This will help evaluate the dashboard components for effectiveness and purpose. If the component does not serve the high-level message, consider removing the component or refocusing it to address the high-level message. Finally, consider how the tool will be delivered to the end-user. Make sure that you hide everything the user does not need to see. Lock anything that should not be changed, and consider how and where the tool will be accessed. Now that we've covered the basics of dashboarding, the next videos will move to practical portions of dashboarding. How do you actually create a dashboard? As we navigate through the practical portions, do not lose sight of the design principles that we just discussed. Namely, how to implement the principles in order to maintain a clear and concise message, and deliver an effective dashboard. [MUSIC]
