Before you begin formal implementation of a project, 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 projects. 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 projects. 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 project.
- “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.
Before you begin, verify that you have completed the steps in this document leading up to the wireframing process.
GoodData considers the wireframing process to be a critical component of the implementation process. You should invest as much time as needed to reach agreement among stakeholders on the wireframes for your project.
- 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.
- Wireframe the reports. Build mockups of each dashboard tab in the project. 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.
- 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.
- 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.
- 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.
- Sign Off. Stakeholders sign off on the wireframing process.
- 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.
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.
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.
If you have the resources, your implementation project 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 project 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 project, you are ready to begin specifying the reports to create for the project.
As part of this exercise, you may discover that you need to add new KPIs to your list. Feel free to revisit the previous step as needed.
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.
- Enter the source KPI. Identify the source system that is providing the KPI data.
- 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.
- 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.
- 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.
- 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 project.
- Now, you can begin grouping reports together into dashboard tabs. A dashboard tab is a single screen in the GoodData project, containing one or more reports.
For each report, you should identify the following information in a single line in the specification.
|Category||The dashboard tab on which the report will appear|
|Report||The name of the report|
|Priority||The priority in creating the report. This field may be used to indicate the order of creation or the requirement level (must, should, might, etc.).|
|Data Source||The system that is providing the data for the report. You can include multiple data sources, if applicable.|
|Calculation||The basic calculation(s) of the report. This calculation should include any attributes (dimensions) that you are making available for slicing the report.|
|Filter||When defining reports, you should consider the data by which you wish to slice the report. For example, if you wish to slice an Opportunity report by geographical regional, you should indicate it in this column.|
|Notes/Questions||Any additional information or outstanding issues related to the report should also be listed.|
|Mock-Up||When the wireframes are completed, you should insert a screenshot in this column for easy reference.|