Guide section 31 of 31
Source / Decision History
This section records the evolution that could be recovered from previous discussions and stored artifacts.
| Topic | Earlier direction | Later decision | Current recommendation |
|---|---|---|---|
| Native-first component guidance | Initial work focused on listing native visuals/components and their capabilities. | Expanded into a 49-component/then 133-entry interactive inventory with native status, custom/preview flags and implementation mapping. | Keep the full catalog, but separate runtime capability from Nudge/Power UI/design patterns. |
| Design-system structure | Early questions considered a Power BI-specific design system. | Decision shifted to reusing the existing company design system as the single source of truth. | Do not create a separate standalone Power BI design system; create a BI-specific mapping/pattern layer. |
| Figma workflow | Figma used for report design. | Added Nudge BI as the Power BI-aware Figma library, with explicit native mapping. | Figma/Nudge are design tools; every representation must map to real runtime capability. |
| Power UI | Considered as a way to bring design-system styling into Power BI. | Positioned as a pilot/organization-specific standardization/configuration layer and theme translation mechanism. | Use where it reduces manual styling, but never claim it adds unsupported Power BI behavior. |
| Reusable system | Early focus was individual components. | Evolved to page composition, common patterns and page flows. | Standardize above the visual layer: configurations → sections → page archetypes/templates → report flows. |
| Page terminology | Overview/search/detail were initially described informally as templates/screens. | Later guide formalized archetype → template → sections → components → native implementation and expanded to 24 archetypes. | Use the formal hierarchy in documentation and Figma. |
| Page library | Initial work used five/six core templates. | Later work retained six core templates and added a broader 24-archetype catalog. | Keep both: archetype library for task selection; core templates for common standardized compositions. |
| Tables/Matrix | Questions focused on what native Table supports. | Evolved into a standardized enterprise configuration of native Table/Matrix rather than a custom table component. | Native Table/Matrix are the runtime; standardize headers, density, formatting, totals, hierarchy and interactions. |
| Navigation/interactions | Initially listed as Power BI functions. | Later separated navigation architecture, interaction vocabulary and analytical journey. | Specify behavior explicitly and keep semantics consistent across reports. |
| Responsive design | Initially compared Power BI to responsive frontend work. | Later distinguished fixed desktop canvas from separate mobile-optimized layouts and print composition. | Design to target viewport; mobile and print are alternate compositions, not automatic reflow. |
| Maps | Map visuals were part of native inventory. | Latest direction in the guide moved away from Bing-based maps to Azure Maps. | Prefer Azure Maps; do not standardize new Bing Map/Filled Map patterns. |
| Q&A | Originally part of native visual inventory. | Later platform guidance marked Q&A for December 2026 deprecation. | Do not standardize new Q&A-based experiences. |
| Migration process | Legacy MicroStrategy reports were the starting source. | Work emphasized business validation of what to retain and avoiding one-to-one lift-and-shift in redesigned pages. | Use Keep / Improve / Combine / Remove / Replace / New before selecting the Power BI page pattern. |
| Handoff / DoR | Initial handoff centered on Figma and requirements. | Expanded to data, native mapping, filters, interactions, states, accessibility, print/embed and acceptance criteria. | A page is ready only when business + UX + data + Power BI development dependencies are resolved. |
Recovered source artifacts
power-bi-ux-ui-design-guide-complete.html— earlier complete interactive guide; contained the 133-entry catalog, templates, workflow, accessibility and handoff material.powerbi_ux_ui_design_guide_updated.html— later guide; formalized page archetypes/composition, retained six core templates and added the 24-archetype library.Pasted markdown(5).md— detailed build prompt capturing the design-system architecture, token mapping, Nudge BI/Power UI roles, component status badges and guide structure.Pasted markdown(7).md— the reconstruction prompt used for this master document.- Prior August 2026 Power BI conversations — especially native components, Figma guidelines, page patterns, Table/Matrix standards, Power UI business-case/setup, handoff/Definition of Ready and Jumbo MicroStrategy → Power BI migration discussions.
Current official platform references rechecked during reconstruction
- Microsoft Learn — Visualizations overview in Power BI: https://learn.microsoft.com/en-us/power-bi/visuals/power-bi-visualizations-overview
- Microsoft Learn — Custom report themes: https://learn.microsoft.com/en-us/power-bi/create-reports/report-themes-create-custom
- Microsoft Learn — Create mobile-optimized Power BI reports: https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-create-mobile-optimized-report-about
- Microsoft Learn — Power BI accessibility for report authors: https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-accessibility-creating-reports
- Microsoft Learn — Power BI Q&A: https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-visualization-introduction-to-q-and-a
- Microsoft Learn — Convert Map/Filled Map to Azure Maps: https://learn.microsoft.com/en-us/azure/azure-maps/power-bi-visual-conversion
- Microsoft Learn — Export Power BI reports to PDF: https://learn.microsoft.com/en-us/power-bi/collaborate-share/end-user-pdf
---
Final consolidated rules
- Start with the user's decision, not the chart.
- Reuse the company design system; do not duplicate it as a separate Power BI brand/design system.
- Native Power BI is the default runtime choice.
- Use Nudge BI to design faster and more realistically, but map every design component to real Power BI capability.
- Use Power UI/theme/configuration to standardize implementation where available; it does not expand runtime capability.
- Standardize component configurations, interactions, page archetypes/templates and report flows above the individual visual layer.
- Use Overview → Analysis → Drillthrough/Detail as a common analytical journey, but select the exact archetype from the user task.
- Make filter scope, active state, defaults and reset behavior explicit.
- Treat Table and Matrix as native enterprise workhorses and standardize their configuration rather than rebuilding them.
- Use progressive disclosure: overview surfaces; analysis explains; detail proves.
- Accessibility, performance, mobile/embed and print/export are design inputs, not late QA items.
- Do not let legacy report structure dictate the new Power BI architecture; validate Keep/Improve/Combine/Remove/Replace/New with the business.
- Do not standardize preview, deprecating or custom functionality without explicit governance.
- Keep the guide and component inventory versioned because Power BI changes.