Guide section 2 of 31
Core Design Principles
| Principle | Why it matters | Power BI implication | Designer implication | Developer implication |
|---|---|---|---|---|
| Native-first | Reduces implementation risk, support burden and inconsistent behavior. | Start with built-in visuals, filters, navigation, drill, tooltips and formatting before custom visuals. | Design only interactions and states that map to a real Power BI mechanism. | Use native capability first; add DAX/configuration before custom code or visuals. |
| Scalability | The migration spans many reports and pages; one-off solutions multiply cost. | Prefer reusable page patterns, themes, standard visual configurations and starter templates. | Choose approved patterns rather than inventing a unique composition for each report. | Implement reusable configuration and PBIP baselines rather than manual restyling. |
| Maintainability | Reports evolve with data models and requirements. | Avoid excessive bookmarks, brittle custom visuals and manual per-visual styling. | Represent maintainable states in Figma, not frontend-like behavior. | Keep configuration centralized and document exceptions. |
| Consistency | Users learn faster when filters, navigation and drill behave predictably. | Standardize placement, semantic color, comparison conventions and interaction meaning. | Reuse the same pattern for the same task. | Keep report behavior aligned with the shared specification. |
| Reuse | The reusable system lives above individual visuals. | Package approved configurations, sections, templates and flows. | Design with library components and page templates. | Reuse theme/configuration/patterns rather than rebuilding. |
| Accessibility | Accessibility cannot be repaired only at the end. | Use alt text, logical tab order, labels, contrast and non-color cues. | Include keyboard/focus/tooltip constraints in design. | Implement and test accessibility in the actual report runtime. |
| Performance | Every visual, interaction and query adds cost. | Keep pages focused; avoid unnecessary visuals and expensive interaction chains. | Do not use density as a substitute for prioritization. | Validate query cost, visual count, custom visual impact and expensive slicers. |
| Information hierarchy | A report should answer the primary question before presenting evidence. | Prioritize context → status → explanation → detail → next step. | Make the dominant answer visually obvious. | Preserve hierarchy with consistent sizing/positioning. |
| Progressive disclosure | Not every detail belongs on the overview. | Use drill-down, drillthrough, tooltips and detail pages to reveal depth. | Design overview, analysis and detail as connected levels. | Implement context-preserving navigation and back paths. |
| Business-task orientation | A page exists to support a decision or recurring task. | Choose page type and visuals from the user question, not from available chart types. | Write the question/decision before drawing the page. | Map measures, filters and actions to that task. |
| Avoid unnecessary complexity | More visuals and controls create cognitive and technical debt. | Prefer one coherent page question and the minimum evidence needed. | Remove decorative or redundant elements. | Avoid arbitrary interactions, duplicate filters and unnecessary custom logic. |