Oracle Usable Apps | Applications User Experience Simplicity, mobility, extensibility
Customer Role: How User Experience Research Is Conducted
Planning Dashboard Content
Types of Dashboards
Print this Page
OBIA Fusion Edition will ship with one of the following types of out-of-the-box dashboards:

Functional Area Dashboard

Functional area dashboards address a sub-business process such as procurement management, inventory management, financial analysis, service management, and so on. They can be designed to serve one or more types of business users, including executive users, managerial and operational users, or business analysts.

Role-based Dashboard

Role-based dashboards address the requirements of the target role, such as CFO, plant manager, call center supervisor, and so on. Executive-level, role-based dashboards are generally cross-functional. For example, a plant manager needs to see financial, human resources, production, and order fulfillment metrics and reports in one dashboard. On the other hand, dashboards for an operational role, such as call center manager, are narrower in functional domain but deeper in operational details. These dashboards also require low data latency.
Role of Analytic Workflows Return to Top
Oracle Business Intelligence (BI) Application dashboards are designed to support key analytic workflows that support a complete process from insight to action. The entire workflow should enable users to gain insight into a problem and to take action in less than four steps. This diagram illustrates a sample workflow:

Planning for Dashboard Pages Return to Top

Contents of dashboard pages depend on whether it is an executive-oriented (i.e., designed to manage a broader business process) dashboard such as the Receivables Dashboard in the figure below or a more narrowly-focused, operation-oriented dashboard such as the Service Manager dashboard in the figure below.



Functional Area / Executive Dashboard

The executive-oriented dashboard can be divided into an Overview page and up to seven subordinate pages.
The Overview page should contain only the key Level 1 metrics that are high-level indicators of the business. These metrics and reports should be the key performance indicators that users typically want to review at the beginning of their business day.

Place subordinate pages to the right of the Overview page. Organize each of these pages around a theme, such as a business objective, a subprocess of the business process addressed by the dashboard, and so on. These pages contain Level 2 (Diagnosis) and Level 3 (Action) metrics.

Exception Page

In the dashboard for business processes that are managed by exception, include an exception page that drives the user to time-critical issues. Examples of exceptions are:

  • Top 10 sales orders that have not been filled by the scheduled date
  • Top 5 customers who are late paying their bills
  • Top 10 manufacturing work orders that have not been completed

Operational-Oriented Dashboards

Operation-oriented dashboards are generally narrow in scope and focused tightly on an operational role. These dashboards can have no more than six pages, each centered on one aspect of operation, as shown in the preceding Service Manager dashboard example. Each of these pages contains Levels 1-4 metrics, enabling the user to perform complete analysis, from gaining insight to taking action, in each area, without navigating away from the page.

Planning for Drilling and Navigation Return to Top

You can use guided navigation to help users easily navigate to typical paths of analysis that exist in another report, dashboard page, or dashboard. Guided navigation can take the form of a persistent conditional navigation or a simple embedded link.



The preceding figure shows the two types of navigation presented on reports. It also shows that a description is added to the report title when data is made drillable. The following screenshot shows that guided navigation can be made persistent by not referencing a source request. If the navigation is to be made conditional, a reference source request and the condition must be provided.


Planning for Detailed Reports Return to Top

Plan detailed reports carefully to enable users to take action without having to process an excessive number of columns and dimensions. Also, create detailed reports to anticipate the context to be passed from the higher-level reports through a set of "is prompted." Therefore, these reports should have comprehensive prompt coverage.

The following is a good example of a detailed report because it enables users to locate the source of a problem (which account is causing the ending balance to exceed the threshold) and to take specific action.

Dashboard Development Steps Return to Top
The following are the suggested steps and best development practices for building a dashboard:
  1. Determine the Level 1 reports that will be rendered on the Overview page of the dashboard and the dimensionality of the reports. In general, use the same filtering conditions for all reports on this page for consistency. Also, report filter conditions "is prompted" will match the dashboard prompt or the prompt for the Overview page.
  2. Determine the Level 2 and 3 reports that will be rendered on subordinate pages that are organized around themes. Remember that many of these reports will form analytic workflows to support a detection-to-action framework. Determine the filter conditions of these reports. A good practice is to keep all filter conditions of reports on a page the same so that "as prompted" conditions can be passed from page prompts. Normally, filter conditions of Levels 2 and 3 reports include all of the filter conditions of the parent Level 1 report.
  3. Create and save Level 1 reports with the appropriate filters. Save and reuse the filters.
  4. Create and save Levels 2 and 3 reports and the appropriate filters. Save and reuse the filters.
  5. Create and save the dashboard and page prompts. Ensure that a combination of report filters and the prompt on the page on which the report will be rendered will not result in a NULL set. For example, if a report filter is Year = CURRENT_YEAR, selection of any year other than the current year will result in a NULL set and the system will throw an error.
  6. Create dashboard pages and lay out the reports on the pages. Adjust report sizes to fit on the pages, following the guidelines provided elsewhere in this report.
  7. Test to ensure the consistency between the prompts and filters for each report on each page.
  8. Build appropriate links to create analytic workflows.
  9. If necessary, fill blank space with instructive text boxes.  |  About Oracle  |  Careers  |  Contact Us  |  Legal Notices  |  Terms of Use  |  Your Privacy Rights