Proper Formatting of Numbers
It doesn't make sense to have a chart that displays numbers with excessive accuracy. Neither does it help if the chart is cluttered with very large numbers. So, it is best to restrict the number of decimal places to 1 or 2. And, scale large numbers by defining a proper scaling parameter. The K,M scale can be applied to financial charts to scale down numbers that are greater than thousand and million.
Dashboards are an important aspect of business management systems and are referred to during the planning and decision making process. Therefore, it is essential to make the dashboard uncluttered and user friendly.
Dashboards have become popular in recent years as uniquely powerful tools for communicating important information at a glance. The greatest display technology in the world won't help if you fail to use effective visual design. Although dashboards are powerful, their potential is rarely realized. And if a dashboard fails to tell you what you need to know in an instant, you'll never use it, even if it's filled with cute gauges, meters, and traffic lights. Don't let your investment in dashboard technology go to waste.
This book will teach you the visual design skills you need to create dashboards that communicate clearly, rapidly, and compellingly. Information Dashboard Design will explain how to:
- ? Avoid the thirteen mistakes common to dashboard design;
- ? Provide viewers with the information they need quickly and clearly;
- ? Apply what we now know about visual perception to the visual presentation of information;
- ? Minimize distractions, cliches, and unnecessary embellishments that create confusion;
- ? Organize business information to support meaning and usability;
b Create an aesthetically pleasing viewing experience; b Maintain consistency of design to provide accurate interpretation;
b Optimize the power of dashboard technology by pairing it with visual
Designing an effective UI for a dashboard can seem a deceptively simple task at first, but soon presents challenges sufficient to ensnare even the most deliberate of developers. The fundamental challenge with dashboard visualization is the conflict of having a limited amount of space in which to communicate a lot of information
Ideally dashboards are more than just business scorecards. They should do more than attempt to balance financial success with perceived business processes, in order to generate growth. Dashboards should provide users with the ability to relate and analyze large patterns of information, in order to glean new insights or understand the business condition more fully.
The UI should be designed to support the specific types of business decisions and insights users hope to gain by viewing the dashboard. This clearly requires more than just a basic understanding of the user's intent, lest we end up with a potpourri of gauges, charts, and tables that only superficially describe the health of the business and fail to uncover any meaningful or directed insights. Providing the user with an effective and engaging experience requires the effective use of layout, color, and interactivity in a synchronistic manner.
But the challenge with dashboards is even bigger yet. Beyond visualization and UI lie a unique set of engineering requirements for summarizing, aggregating, and pre-calculating information computed from large data sets. For instance, showing basic sales figures during a period of time filtered by product SKU would most likely entail gathering source information from some type of ERP transaction system on an order or line-item basis. A company with any significant order volume could easily be referencing millions of transactional records which would need to be summarized across product SKU.
Adding other filtering dimensions like geography, channel, market segment, etc., quickly creates need for some type of back-end data engine to aggregate and pre-calculate this summary information. In most cases these back end data repositories take the form of a data warehouse, with some type of online analytical processing (OLAP) system to process the data within the warehouse.
Yet for many organizations, the data warehouse will never encompass all the information that needs to be referenced. Or perhaps they may not have sufficient business intelligence systems in place to collect and aggregate the information. In these cases, calculations tend to be performed by the most pervasive analysis tool employed by businesses today - the spreadsheet.
Business analysts collect data from several sources by hand in the form of extract reports, then import it into a spreadsheet and perform manual calculations to prepare reports for consumption by higher level executives. This manual aggregation process occurs at varied intervals depending on the demands of the business and may work in isolation or in conjunction with more automated back end data aggregation.
In both of these scenarios (using a data warehouse/OLAP solution to pre-calculate or manually aggregating and calculating data via spreadsheets) the dashboard designer is faced with the same data structure challenges. The dashboard will need to collect data from several sources at once and present that data in some type of hierarchal format representing different levels of aggregations and calculations. Most dashboards need some way to transform, filter, and drill across hierarchal data structures, making it critically important to engineer a solution which accommodates these structures in a flexible and consistent manner.
When it comes to a development methodology for building dashboards there is no silver bullet solution. However, there are some general principles which have been found to be effective.