search

Designing and Developing the Visualizations

Users can access two visualization alternatives within the platform.

hashtag
Reports

The Report module enables business users with ad-hoc and self-service reporting capabilities. By leveraging this module, any business user with minimal IT skills can create visualizations, reports, and business stories in real time.

  • The user has to create a datastore before creating a report.

  • We can create the datastore and get the data uploaded on creation for less volume of data.

  • The user can create a metadata store and load the data using a data pipeline if the volume of the data is high.

  • The user can decide on the datastore -DB based on the infrastructure.

    • You can choose ClickHouse, Mongo, PostgreSQL, Elastic, or Pinot.

hashtag
Dashboards

Designing a dashboard involves more than just visualizing data—it’s about creating an intuitive, engaging, and informative experience for the end users. Here are key considerations to keep in mind while designing an effective BI dashboard.

Area

Best-Practice Guidance

Purpose & Audience

  1. Identify primary users (executives, analysts, operations, etc.) and the questions they need answered.

  2. Decide which KPIs matter most to each group before you start designing.

Critical KPIs Up Front

  1. Use KPI tiles/cards for quick-glance metrics.

  2. Place the most business-critical indicators in the top-left, following natural reading order.

Logical Layout & Hierarchy

  1. Lay out the page from summary → detail (drill-down).

  2. To ensure natural eye flow, maintain consistency in all spacing, alignment, and sizing elements.

Right Visualizations

  1. Match the chart to the story: bar/column for comparisons, line for trends, heat-map for density, etc.

  2. Avoid 3-D, excessive color gradients, or “chart junk.”

Interactivity

  1. Provide slicers/filters (date, region, category) so users can self-serve answers.

  2. Support drill-through from KPI tiles to detailed grids.

  3. Add tooltips for extra context without clutter.

Performance & Responsiveness

  1. Optimize queries; bring back only the fields you need.

  2. Implement lazy loading / virtual scrolling for data grids that can grow large.

  3. Test on desktop, tablet, and mobile if any are in scope.

Context & Annotation

  1. Include titles, axis labels, legends, and last-refreshed timestamps.

  2. Annotate unusual spikes/dips or notes when data is incomplete.

Report vs. Dashboard

  1. Decide early whether users need a static report, an interactive dashboard, or both; each serves a different purpose.

Design Consistency

  1. Use a shared theme (color palette, fonts, spacing) and stick to it.

  2. Prototype with the approved corporate style guide if one exists.

Naming & Reuse

  1. Follow clear naming conventions for dashboards, connectors, and datasets (e.g., <DashboardName>_<DataService>).

  2. Reuse existing data connectors where possible.

Manageable Scope

  1. Don’t overload a single dashboard—split into multiple views and link via tabs or buttons.

  2. Reload only the data service relevant to the active view.

Query & Service Efficiency

  1. Monitor execution time; refactor slow queries early.

  2. Cap exports (e.g., 50k rows) if large extracts hurt performance.

Version Control & Workspaces

  1. Save work frequently and commit to Git with semantic version tags.

  2. Keep final dashboards in a “Production” (or similar) workspace; store working copies elsewhere.

Environment & Migration

  1. Use environment variables for credentials.

  2. Migrate in one direction: dev → staging → prod.

  3. Verify platform versions before migration and ensure that they match.

hashtag
Key Standards

  • Plan with Stakeholders — confirm KPIs, filters, and date columns before building.

  • Write Clear Commit Messages for every change to aid traceability.

  • Apply Naming Conventions to dashboards, connectors, and datasets.

  • Save and Version Frequently to avoid session-timeout losses.

  • Reuse Connectors/Data Services instead of duplicating them.

  • Enforce Role-Based Security — publish to groups rather than individual users.

  • Use ENV Variables for all credentials and server names.

  • Annotate Last Refresh Time so users trust data recency.

  • Prototype with Corporate Themes to speed stakeholder sign-off.

  • Drill-Down Paths — always provide a clear route from summary KPIs to underlying detail.

  • After each development phase, push the document to Git with appropriate dashboard versioning, ensuring it is available for future reference.

  • Before migrating, make sure the versions of both the accounts and servers are the same.

  • Migration should always happen in one direction: dev->stag->prod.

  • Never make any changes directly in production. Always implement changes in the development environment, test them thoroughly, and then migrate them to production.

  • Avoid reverse migration from production to development to maintain data integrity and consistency.

hashtag
Mistakes to Avoid

  • Don’t Overload a Dashboard with too many charts—split or toggle views.

  • Don’t Hard-Code Credentials in queries or config files.

  • Don’t Skip Testing on the actual data volumes expected in production.

  • Don’t Modify Dashboards Directly in Prod — always promote from dev/staging.

  • Don’t Reverse-Migrate (prod → staging/dev); it risks duplicate datasets.

  • Don’t Publish Multiple Near-Identical Versions — republish the existing asset unless the change is breaking.

  • Don’t Use Inconsistent Colors or Fonts — it confuses users and hurts brand alignment.

  • Don’t Leave KPIs Unexplained — a metric without context leads to misinterpretation.

  • The platform version of the destination account must not be lower than that of the source.

Last updated