Planning Your Dashboard

Before you begin formal implementation of a workspace, you should invest in the process of designing the visualizations of your dashboards. In GoodData, success begins with the final product, from which you work backward.

For purposes of this tutorial, you do not need to execute a wireframing process. This page is for your information only.

Most users have a clear idea of the information that they require in order to make meaningful decisions for their role. To support this start-from-the-end approach, GoodData recommends investing significant time in building the visualizations of each dashboard tab in your workspaces. This process is called wireframing.

The wireframing process is an important step in turning the abstract stream of data into a visualized product. The wireframes you produce become the basis for your GoodData workspaces. Through visualization, you can create images of what you want to report. When this image becomes clear, the implementation team can focus on how it is reported.

• “What” corresponds to the gathering of information about data sources and the key metrics in your workspace.
• “How” corresponds to how these pieces of information are to be displayed.

After the visualization is complete, you can use the tools to work forward and backward:

• Forward. Use the wireframes to experiment with new metrics and potential reports that may have occurred to team members as part of the wireframing process.
• Backward. Your technical team can break down dashboard tabs into individual reports, which can be broken down into individual metrics. These metrics can be decomposed into their source attributes and facts, which trace all the way back to the source fields from your enterprise data systems.

Overview of the Wireframing Process

The process by which wireframes are developed occurs in the following general steps.

Steps:

1. Prioritize the critical metrics. What are the key metrics that users want to see? How do they want to see them in a report?  You should develop a prioritized list of these metrics and try to visualize how they will appear in reports. You can break them down into buckets, which would correspond to business units. Different business units are likely to focus on different tabs in your dashboards.
2. Wireframe the reports. Build mockups of each dashboard tab in the workspace. See Building Wireframes. When building reports, you should attempt to map one report to one source dataset. Avoid creating situations in which datasets need to be joined outside of your source database.
3. Match report fields to data fields. Each field in each report should be matched up to a field among your data sources. As part of this matchup, you should verify that the data type of the field is consistent between source and all destination reports.
4. Walk through the use cases. Each representative stakeholder in your reports should walk through how he or she would use the reports to make their primary decisions and to take actions from them. If the reports do not readily enable decisive action, you should review the wireframe again.
5. Iterate. Review the wireframes and validate the data in them until you are satisfied of the following:  The source data is sufficient for populating the reports.  The key metrics are surfaced in accessible and understandable ways in the reports.  The reports satisfy the primary use cases for them and are clear to the primary users of them.
6. Sign Off. Stakeholders sign off on the wireframing process.
7. Add to Requirements Grid. When your wireframes have been approved, you should insert them into the report definition sheet(s) in your Requirements Grid for easy reference.

Building Wireframes

When you are creating your wireframes, you should use the visualization tools with which your implementation team is most comfortable. The key criteria are the following:

• Does the tool produce a result that everyone can understand, without extensive knowledge of internal discussions? If you share the visualizations with people outside the immediate team, will their contents and uses be clear?
• Can the tool be used for iterative workflows? During wireframing, you may decide to make changes as a result of the process.

Below are some wireframing methods that have been successful in GoodData implementations.

For more information on the types of charts that are supported in GoodData, see Chart Types.

Whiteboard wireframes

For rapid prototyping of the visuals, you may wish to put together your wireframes as a series of whiteboard images. This technique allows for quick development when the layout is important or otherwise unknown.

The drawbacks are that this technique does not provide much connection to the underlying data, which is represented as simple numbers on the whiteboard. And unless you have an unlimited number of whiteboards, you may have to delete a wireframe to work on another one and then rebuild the first wireframe when you iterate on the process.

Wireframing Tool

If you have the resources, your implementation workspace may greatly benefit from using a software designed for wireframing. Available tools combine the best of visual and data-driven approaches, so that you can rapidly prototype the layouts, while populating them with dummy data. Since all of your visuals are stored as software objects, they can be standardized, and key components such as color values and typefaces can be directly extracted from the wireframe.

The following image was taken from Balsamiq, a visualization tool that has been used on a number of GoodData implementations.

For more information on Balsamiq, please visit www.balsamiq.com.

Before proceeding to the next step, all team members and workspace stakeholders should sign off on the wireframes, so that there is consensus on what is going to be implemented.

Identify Reports to Create

After defining the KPIs and their related dimensions for the workspace, you are ready to begin specifying the reports to create for the workspace.

In GoodData, the basic user account has access to dashboard but does not have direct access to the Reports page. When you are defining reports for the baseline Viewer role, they need to be surfaced in at least one tab of a dashboard.

When you are specifying the report, you should define what the report needs to express to its viewers.

1. Enter the source KPI. Identify the source system that is providing the KPI data.
2. Define the metric calculation that you wish to apply to the KPI (SUM, MAX, MIN, AVG, or COUNT). In the GoodData Report Builder, this information populates the What tab for the report.
3. Identify any attributes that you wish to use to slice the report. These attributes are the dimensions that you have specifically associated with the metric. In the GoodData Report Builder, this information populates the How tab for the report.
4. Identify any ways in which you wish to filter the report. Possible options include: filter by a list of attribute values, ranking, numeric ranges, or user-defined variables. In the GoodData Report Builder, this information populates the Filter tab for the report. This information may not be known at this time.
5. You have now defined each basic report and its dependencies. The collection of this information provides a good first pass at defining the overall data model for the workspace.
6. Now, you can begin grouping reports together into dashboard tabs. A dashboard tab is a single screen in the GoodData workspace, containing one or more reports.

For each report, you should identify the following information in a single line in the specification.