Custom Dashboards Overview

Custom dashboards allow users of the Syniti Knowledge Platform with permissions granted by the Support Team to use QuickSight to harness metrics, milestones, schedules and more from data sources in the Stewardship Tier to create visualizations of reports as dashboards in the Knowledge Platform. We are happy to provide support for your custom dashboards, but if you have any other questions about QuickSight, check out QuickSight's user forum. Find out about new QuickSight features and fixes at QuickSight's What's New.

Once you understand some of the philosophy behind dashboard creation, check out our tutorials:

• Custom Dashboards 101

• Custom Dashboards 201

Note

Contact the Support Team for assistance in presenting Stewardship Tier data in your custom dashboards.

To get Custom Dashboard Author permissions for your account, please open a Support ticket. Custom Dashboard Author permissions can be granted to users with Admin, Business Admin and Author permissions, but not those with Viewer permissions. Credentials provided for custom dashboard Authors will not work for other QuickSight features.

Note

If you are registered as a Custom Dashboard Author, do not change the email address you used to configure the user account for which your Custom Dashboard Author permissions are allowed. If you must change your email address for an author account, please contact Customer Success to update your credentials in QuickSight.

Note

Custom Dashboard Author permissions can only be granted to 10 users at a time per Knowledge Platform tenant.

Note

The user session timeout when using the Custom Dashboard Builder is 180 minutes. If you are logged in to the Dashboard Builder and are inactive for 180 minutes, your session ends and you are automatically logged out. You will lose any unsaved work.

Key Concepts

The following are some key phrases and concepts to understand before you get started:

• Data source—A data store that is the source of data for dashboards (e.g., a specific database in a SQL Server instance).

• Dataset—Identifies the specific data in a data source that you want to use as a source of data for a dashboard (e.g., a table or view in the registered database).

• Analysis—A container for interacting with visuals. You can use multiple datasets in an analysis, although any given visual can use only one of those datasets.

• Visual—A visual representation of data in graphical or tabular form that appears on an analysis.

• Insight—A textual insight based on the data in an analysis, can be added to an analysis in the same way that a visual can to provide insights into the data in the dataset.

• Dashboard—An interactive and read-only view of an analysis.

• Calculated Fields—Calculated fields can be added to a dataset to extend or enhance the dataset. You can also apply calculations to columns. Feel free to use QuickSight’s calculated fields for aggregate functions. However, we highly recommend that all other calculations take place in the database either in procedures that put data into staging tables or in views.

To see these key concepts in action, check out the QuickSight Dashboard Workshop.

Architecture

The Custom Dashboards architecture consists of these components:

• Stewardship Tier database—This is the Data Tier portion of the Syniti Knowledge Platform that sits under the Stewardship Tier.

• Delivered data source—These are two delivered data sources that cannot be changed. One of these data sources points to the Data Tier.

• Delivered datasets—These are datasets delivered as a part of the product that can be used for custom dashboards but cannot be changed.

• Custom datasets—These are datasets created by dashboard authors that point to data in the delivered data source.

• Custom dashboards—The dashboards created in the Syniti Knowledge Platform.

Dashboard Development Life Cycle

The following lifecycle is the recommended path to develop custom dashboards and move through a testing to a deployment cycle:

Create a new dashboard

1. Create datasets—To create a visual, configure the datasets that represent the data to be displayed on the dashboards.

   Note

   We recommend that you do not use the SPICE capabilities for the custom dashboards. In nearly all cases, direct query is the preferred way to access data. SPICE provides a caching capability to read data from the specified data source for the dataset. Due to the caching, using this capability requires frequent refreshing to gather the latest information, which can affect the timeliness and thus accuracy of the data.

2. Create an analysis—Using the datasets created in step 1, add visuals and insights to create your analysis.

3. Iterate on steps 1 and 2 until your analysis is ready for review and testing.

4. Publish the analysis—Publish the analysis as a dashboard to a limited set of users; identify the initial stakeholders that need preview access to the dashboard and share the analysis with those users directly.

5. Note

   We recommend that you use a naming convention for dashboards such as the prefix “For Review.” For example, “(For Review) Data Quality for Supply Chain.”

6. Modify the datasets and analysis as necessary from the feedback above.

7. Iterate through steps 4 and 5 until the analysis is ready for publishing.

8. Publish the dashboard to all users that need access (with the descriptive prefix removed).

Document your datasets and the visuals that rely upon them. Be sure to include screenshots, fields used, placement in field wells, filters, sorts, calculations, colors, formatting, and anything else that you need to recreate the visual. Use descriptive titles for dashboards and their pages to add context to your dashboards. Analysis names can be long, so don’t shy away from providing as much context as you can in the name field. For example, web*DashReportObjectSelDEV for US filtered by Wave.

Modify a published dashboard

1. We recommend that you make copies of existing datasets rather than modifying them directly. When you modify a dataset, it may break visuals for other dashboards that use those datasets. If you do modify an existing dataset, avoid making changes that might break visuals. For example, avoid removing columns that are being used in a visual; rather, create calculated columns in their place. These replacement calculated columns must have the same name and data type as the original.

2. Make necessary changes to your analysis.

3. Iterate on steps 1 and 2 until your analysis is ready for review and testing.

4. Publish the analysis as a new dashboard to a limited set of users; identify the initial stakeholders that need preview access to the dashboard and share the analysis with those users directly.

   Note

   We recommend you use a naming convention for dashboards with a prefix such as “For Review.” For example, “(For Review) Data Quality for Supply Chain.”

5. Modify the datasets and analysis as necessary, following the best practices outlined in Design Guidance.

6. Iterate through steps 4 and 5 until the analysis is ready for publishing.

7. Publish the dashboard replacing the dashboard that was originally copied for edits.

Document your datasets and the visuals that rely upon them. Be sure to include screenshots, fields used, placement in field wells, filters, sorts, calculations, colors, formatting, and everything else that you need to recreate the visual. Use descriptive titles for dashboards and their pages to add context to your dashboards. Analysis names can be long, so don’t shy away from providing as much context as you can in the name field. For example, web*DashReportObjectSelDEV for US filtered by Wave.

Design Guidance

Dashboards that are excellent both visually and practically require forethought, finesse, and thorough planning (with supporting documentation to boot!). Creating perfect dashboards is an art. Learn these composition rules like a pro so that you can eventually break them like an artist.

Understand the context and users

Relevant self-service style dashboards must be built with purpose and persona in mind. Questions to ask and items to consider when creating a dashboard include:

Goals

• Why do we need the dashboard?

• How will it help our business or users?

• When do they need it?

Users

• Who is going to use it?

• What do they care about?

• What is most important to them?

Decisions

• What questions need to be answered with the dashboard?

• What thresholds or warnings must display?

• What will users do next after looking at / working with the dashboard?

Context of Use

• How often will users use the dashboard?

• What is the context of usage?

Data

• What data do we have?

• What is the structure of the data?

Visuals

• What graphs and charts make sense?

• How much data do we need to impact the decision making process?

Success Criteria

• What is the criteria by which the dashboard will be viewed as a success?

• How do we ensure the needs of the users are met?

Database-centric development

Delivered data sources are delivered with the tenants that point to the Data Tiers of the SKP that exist within the organization's landscape. This relational database allows for advanced computation, so we recommend that you take advantage of those database features as much as possible while preparing the datasets.

The following are recommendations for the building of datasets within the context of SKP custom dashboard creation:

• Field calculations in the database—We highly recommend that all calculations take place in the database either in procedures that put data into staging tables or in views.

• Use views as the sources of datasets—Views are the preferred source of datasets even if the view is a selection of all rows and all columns from a table. By using a view, making changes to logic and adding columns is much easier than with base tables.

• Naming convention—The preferred naming convention for dashboard views is: web*Dash. Create unique, descriptive names for each dataset and analysis in QuickSight, including an indication of the data source’s instance.

  • Dataset names—Dataset names automatically take on the name of their underlying database object. Rename the dataset to include the instance from which the data is being pulled. This is the only way to indicate the data source to dashboard viewers. For example, a good dataset name is web*DashReportObjectSelDEV.

  • Analysis names—Analysis names can be long, so don’t shy away from providing as much context as you can in the name field. For example, sa good analysis name is web*DashReportObjectSelDEV for US filtered by Wave.

• Refreshed date—If the data in the dashboards will be refreshed on a regular basis, it is recommended that the date of the last data refresh be captured in the database and displayed on the dashboard to give the viewer context.

Best practices

Planning

• Ask before you design—

  • Who is this for?

  • What problem(s) does this report/dashboard solve?

  • Why is this report/dashboard important?

  • What questions does this report/dashboard need to answer to help understand and comprehend the problem?

  • How should the data be sliced and diced?

    • What filters should be available?

    • What filters should be on by default?

    • What filters should we NOT use?

    • Should this be high-level only?

    • Should it allow for drill through to a lower level of detail (e.g., drilling from a Wave to a Process Area or Object, or drilling from a Category to an individual Category Value) drill report?

• Think about layout—

  • What’s most important to the user? Move it towards the top of the page. KPIs should be higher up, as well as charts that tell the story and need to be full-width to read, manipulate, and understand.

  • Group things together that need to be grouped. For example, if you want to show data quality metrics along with other data management metrics, put them in the same row or inside the same bounding box.

  • How much room should something take up? Some charts need to be large and that’s fine.

  • How can you most effectively use space? Unless your viewer is likely to be printing the screen over and over (which some do when they just want to show the dashboard in a Powerpoint deck), use your vertical space to give visuals enough room and let viewers scroll.

  • Use a grid layout; line up the edges of different visuals to create a cohesive look.

• Information planning affects layout, too—

  • Use your filters. Analytics systems provide filters and facets for users to slice, dice and revisualize data based on the set of data they care about.

    • Don’t worry about making 20 business unit dashboards; rather, make one and provide a business unit filter or facet.

    • Consider setting a drill action on top visuals that filters lower visuals for more concise displays.

    • Use top level controls to filter page where applicable.

  • Create an outline of your report including higher level headings and drill-downs into more granular detail.

  • When using multiple tabs, place the highest level data on the 1st tab, then drill down into the data with the subsequent tabs.

  • Within a tab, position higher-level information on top and lower-level information underneath.

  • Set actions to link to external pages (or new tabs) where it’s beneficial and relevant.

  • Use descriptive and/or instructive tab names.

  • Carefully consider the data when selecting a data element type; which type allows for as little storage space as possible while still considering edge cases?

• Look at the result and consider—

  • Does the dashboard clearly convey the problem?

  • Does the dashboard help provide a solution for the problem?

  • Is there anything that detracts from being able to see and solve the problem?

Rather than creating dashboards and reports that are irrelevant to visually take up space, change the layout of the dashboard to fill the space. Less dense, more relevant information creates a more focused experience for dashboard viewers.

Syniti Knowledge Tier color theme

Refer to Create Themes for detailed information.

Main colors

• Primary Background: #FFFFFF

• Primary Foreground: #3B617A

• Secondary Background: #F6F6F6

• Secondary Foreground: #444444

• Accent: #3B617A

• Accent Foreground: #FFFFFF

Data colors

The following list is in order of data colors to use for charts/graphs:

1. #00558B

2. #503D63

3. #1A9584

4. #ECC21F

5. #C25052

6. #E65722

7. #444444

8. #C9C9C9

Visual considerations

• Data metrics—Good dashboards focus on visualizations of data metrics, including:

  • KPIs

  • Composition (what makes up this metric, how does it change over time)

  • Comparison (of 2-3 metrics)

  • Correlation between metrics (Do X and Y affect each other?)

  • Distribution (e.g. between categories or business units)

• Composition—

  • A dashboard should not display a table or grid. These visuals can quickly overwhelm a viewer. Dashboards should help focus a viewer’s attention to a problem or a task. (if you were driving a car, would you rather look at the gauges or at an Excel printout of the last 10 minutes of performance?) A report can contain visualizations like a dashboard, but is generally focused on showing data grids.

  • Be consistent with use of color, icons and naming

  • Set names to have proper spacing and casing (e.g., totalvalue = Total Value)

  • Set the layout so that all visuals align vertically on left and right page borders

  • Aim to set uniform element sizing and spacing between elements

  • Visuals are responsive; tables will expand but columns widths remain static. Your design will need to take this into consideration.

• Color schemes—

  • Create a theme to quickly and consistently a custom color template to your analyses.

  • Use the Syniti Knowledge Tier color theme to ensure cohesive visual tone and to maintain WCAG Accessibility standards. You can mix in customer brand colors, but you may end up with a color set that does not work for people with visual impairments.

  • Set the style so that the titles on all visuals are #3B617A

  • For icons, use both color and labels for readability and download compatibility

• Shapes—

  • Don’t rely on color alone to indicate good/bad or spotlight conditions. Shapes (as in, an exclamation mark for an alert) make reports and visualizations more accessible and less prone to reading errors and confusion.

  • Consider using varied icons to show state changes (not all the same icon)

• Additional considerations—

  • QS has a bug where columns resize and hidden columns reappear. Review before publishing a dashboard.

  • Changes to the data source sometimes clear styling. Attempt to finalize your dataset early-on.

  • Not all elements support conditional formatting. You may need to be a bit creative.

  • Elements cannot be shown/hidden dynamically, you can only change the data based on controls, actions or ad-hoc filters.

Tables

• Set a background condition on the tables so all rows are #FFFFFF

• Set a text condition on the tables so that all text is #777777

• Consider setting text conditions for a row when it should be called-out (ex: current wave)

• Consider setting a text condition for values that contain link actions

• Hide unneeded columns and set column widths for expected values

Charts

• Choose the best chart—Choosing the correct chart to visualize information is not always obvious or intuitive. Luckily, there are many resources available online. Here are two:

  • ChartChooser: A visual guide to picking the right chart

  • Data Visualisation Catalog: Another visual guide (with more chart types)

    Note

    We recommend avoiding pie charts; they do a poor job showing composition, especially when there are a lot of values or when some of the values are very small or similarly sized by comparison. They can also be unappealing and hard to understand where many wedges converge at the center point. We recommend using stacked bar or stacked column charts. In cases where a pie chart seems necessary, we recommend using donut charts instead.

• After you choose the best chart to display your data—

  • Set the style so that the chart labels are grey (#3B617A) unless overlayed on a graphic that reduces the visibility of that color grey.

  • Consider if you need a legend or if the dashboard is easily understood as is.

  • If you use a legend, consider the length and number of expected values when choosing the legend’s location on the dashboard.

Further reading

• 10 Rules for Better Dashboards

• Choosing a Good Chart

• Show Me The Numbers, Stephen Few

• Information Dashboard Design: Displaying Data for At-a-Glance Monitoring, Stephen Few