Skip to content

Guide sections

55 sections from the master guidelines, rendered with their tables, checklists and evidence callouts intact.

  1. 1PurposeThis handbook consolidates the Power BI UX/UI guidance developed across our earlier discussions, interactive guides, prototypes and migration work. It is intend
  2. 2Core Design Principles
  3. 3Power BI for UX Designers — Getting StartedPower BI is an analytical report platform, not a general-purpose responsive application framework. The most common design failure is to prototype a web applicat
  4. 4Power BI Architecture Relevant to UX
  5. 5Design System StrategyThe recovered enterprise direction is to reuse the existing company design system rather than create a second standalone Power BI design system. The Power BI-sp
  6. 6Foundations
  7. 7Complete Power BI Component & Capability InventoryThe recovered interactive guide contained 133 catalog entries. That catalog intentionally mixed native Power BI visuals/features with Nudge BI representations,
  8. 8Table & Matrix StandardThe reusable standard should be a configuration of native Table and Matrix, not a new custom table control.
  9. 9Filters & SlicersUse slicers for frequently changed, user-facing controls and the Filters pane for less frequent or more technical filtering. The user must be able to understand
  10. 10Interaction Patterns
  11. 11Navigation ArchitectureThe terminology recovered from the page-flow discussions is:
  12. 12Reusable Page PatternsThe later guide expanded the earlier six templates into 24 page archetypes. The archetype tells you what the page is for; the template tells you how that archet
  13. 13Page Composition Patternstext
  14. 14KPI & Scorecard PatternsA KPI should make the primary value, comparison basis and status legible without forcing the user to decode several competing numbers.
  15. 15Chart Selection Guide- Pie / donut: difficult precise angle/area comparison; keep to a few obvious categories.
  16. 16Dashboard / Report UX Heuristics
  17. 17AccessibilityAccessibility is part of each component specification and the Definition of Ready, not a final visual-polish task.
  18. 18Responsive Design & Screen SizesPower BI should not be designed as if it were a CSS-responsive website. Desktop report pages use a configured canvas and are scaled/fitted in the viewer. Phone
  19. 19Power BI Restrictions Designers Must Know
  20. 20Native vs Custom Decision FrameworkUse the lowest-complexity layer that satisfies the analytical requirement.
  21. 21Reusable System Above the Visual LayerThe central design-system concept recovered from multiple discussions is:
  22. 22Figma → Power BI Workflowtext
  23. 23Designer → Developer HandoffUse a compact per-page specification:
  24. 24Definition of Ready for Power BI Page DevelopmentA page is ready when the team can implement and test it without unresolved design or data assumptions.
  25. 25Migration Pattern: Existing Report → New Power BI PageThe migration work established that redesign should not start by tracing the old screen one-to-one. Work with business stakeholders to decide what from the lega
  26. 26Common Anti-Patterns
  27. 27Recommended Reusable LibraryThe library should be governed from foundations downward. A change to company tokens should flow through mappings; a new page pattern should not redefine brand
  28. 28Practical Examples
  29. 29Glossary
  30. 30Open Questions / Unresolved Areas
  31. 31Source / Decision HistoryThis section records the evolution that could be recovered from previous discussions and stored artifacts.
  32. 32Designing for Power BI — the mental-model shiftA practical guide for UX/UI designers coming from web and product design.
  33. 33Web/app design vs Power BI design
  34. 34Do not design Power BI as a websiteA Figma prototype can make almost anything appear possible. Power BI cannot reproduce arbitrary frontend behavior simply because it can be drawn.
  35. 35Think in analytical questions, not screensWeb applications are often organized around tasks: dashboard → search → edit → submit → confirmation.
  36. 36Start with the question, not the chartDo not begin by asking which chart goes here. Define:
  37. 37Data is part of the design materialA web designer can sometimes design a component before knowing the backend data structure. That is much harder in Power BI, because the design depends directly
  38. 38Native components matter more than in frontend designA frontend team can build a new component when required. In Power BI every custom solution adds implementation and maintenance cost, so the designer should know
  39. 39Interaction design works differentlyPower BI already contains an interaction model; designers need to understand it rather than invent one.
  40. 40Drill-down is not drillthroughDesigners frequently confuse these two mechanisms.
  41. 41Tooltips are more constrained than web popoversIn Figma it is easy to design a hover panel with tabs, buttons, links, filters and actions. Do not assume that works as a Power BI tooltip.
  42. 42Responsive design is fundamentally differentIn web, one layout system reflows from desktop to tablet to mobile. Power BI works with a configured report canvas — page settings offer fixed aspect ratios suc
  43. 43Figma should represent Power BI, not fight itFigma remains useful for page architecture, information hierarchy, analytical flows, page templates, visual selection, layout, design-system application, intera
  44. 44Design-system thinking changes shapeA web design system commonly runs tokens → components → patterns → templates → application. For Power BI a useful structure is:
  45. 45Components should often become configurationsInstead of designing a custom "Enterprise Data Table Component", define our approved configuration of the native Power BI Table:
  46. 46Page patterns beat designing every report from scratchDesign reusable analytical archetypes and let report pages be selected rather than invented.
  47. 47Information density is differentWeb product design frequently encourages generous spacing and progressive navigation. Analytical reporting often needs higher information density — which is not
  48. 48Accessibility matters; the implementation differsPower BI includes built-in support for keyboard navigation, screen readers, high contrast, focus mode and accessible data views. Report authors still configure
  49. 49Performance becomes a UX considerationIn Figma, adding another chart costs virtually nothing. In Power BI each visual can create additional rendering and query work.
  50. 50The designer–developer relationship starts earlierA web workflow can sometimes run UX → UI → finished Figma → frontend. That handoff model is risky for Power BI, where feasibility depends on the semantic model.
  51. 51What a designer should hand overDo not hand over only a screenshot. For every page, specify:
  52. 52A practical designer checklistBefore handing a Power BI page to development, ask:
  53. 53Common mistakes moving from web UX to Power BI
  54. 54The designer's new roleDesigning for Power BI is not simply designing dashboards in Figma. The UX designer helps define the analytical interface between data and a business decision.
  55. 55Recommended working modeltext