Power BI Visuals & Design - FAQs

Yes — there are free Power BI themes designed for KPI dashboards. Several of Hopton's free Power BI themes are built for exactly this: bold, high-contrast palettes like 149 Degrees (tagged Bold, Executive) that hold up on board-level KPI dashboards, alongside accessible options like Beacon and Spectrum for teams that need colourblind-safe reporting. Each theme sets accent colours, card styling, and typography consistently across the report. Target, at-risk, or variance colour-coding on individual KPI cards is set separately through Power BI's own conditional formatting; the theme provides the consistent base it sits on top of. Themes are free JSON downloads applied via View, then Themes, then Browse for themes in Power BI Desktop.

Yes, this is a common request - reworking an existing app's navigation, audience structure, and branding without necessarily rebuilding the underlying reports themselves. It is often a relatively quick, high-value piece of work compared with a full reporting rebuild.

Yes, apps support a custom logo, theme colour, and description, which is worth using properly rather than leaving as defaults. For an app being rolled out organisation-wide, this branding is a small effort that meaningfully affects how seriously business users take the content.

Designing the app structure is part of our standard Build phase design work, alongside workspace structure, security, and dashboard design, rather than treated as an afterthought once dashboards already exist. Deciding early who the actual audiences are and what each should see shapes both the workspace and the eventual app structure.

The app mechanism itself works the same way regardless of whether the underlying workspace sits on Power BI Premium or Fabric capacity. What does change is the scale of content and audience complexity Fabric-based estates tend to reach, which makes deliberate app and audience planning even more important as the estate grows.

A sensitivity label can be both a visual tag and an enforced restriction. A sensitivity label can be purely informational, or it can be configured to enforce real restrictions - blocking export to Excel or PDF for highly confidential content, for example. Whether to enforce restrictions or use labels informationally is a deliberate governance decision, not a default setting.

Download a theme as a JSON file, then in Power BI Desktop go to View, then Themes, then Browse for themes, and select the file you downloaded. The theme applies to the whole report instantly, recolouring visuals, fonts, and backgrounds to match. Hopton publishes a set of free Power BI themes for exactly this purpose; no setup or add-in is required beyond Power BI Desktop itself.

Word layouts are easier to maintain than RDLC for simple documents. Most modern BC users build customer-facing documents in Word layouts where possible and reserve RDLC for documents needing the additional control. The skill-find for Word layouts is also broader than for RDLC, which matters in mid-market organisations without dedicated BC developers.

To get started on Power BI app design or a redesign, email hello@hoptonanalytics.com describing your current workspace and app setup, or the lack of one, and who your different report audiences actually are. We will review your current structure and recommend an audience and navigation design as part of scoping, whether as a standalone piece of work or part of a wider engagement.

Microsoft's Business Central analytics roadmap is increasingly Fabric-centric. The investment is going into Lakehouse Connector improvements, Fabric integration, and Copilot inside BC. If your strategy is BC plus Power BI on Fabric, the roadmap is in your favour. If your strategy depends on Native RDLC for analytics or on third-party tools that compete with Fabric, the roadmap is mostly orthogonal to your plans. The roadmap does not invalidate other approaches but it does signal where the integrated experience will be best.

The Hopton checklist differs from Microsoft's own Power BI design guidance in emphasis: Microsoft's guidance is mostly about what is possible. Our checklist is about what is sensible. The two are different. Microsoft will tell you how to use bookmarks, custom visuals or themes. The checklist tells you when to and when not to. It is opinionated where Microsoft is permissive, and that is where the value is.

A report should use one font family, in three or four sizes. Three colours used meaningfully, plus a neutral palette for everything else. The discipline is harder than it sounds. Most over-coloured reports are not built that way deliberately. They drift there over time as different stakeholders ask for different visuals. The annual review is when you pull the colours back into line.

You should run the Power BI design checklist on every report that goes to a real audience before sign-off. Skip it for sandbox or proof-of-concept work where the review effort would outweigh the value. The risk is in the reports that quietly become production while everyone assumed they were prototypes. The checklist is the moment the report has to declare itself.

Power BI security needs ongoing maintenance, not just a one-off design at launch. Roles change, new data sources get added, and new report consumers join the organisation. We build periodic security review into Continuity support arrangements rather than treating the initial configuration as permanent.

A Power BI theme is a JSON file that sets a report's colours, fonts, and visual styling in one go, rather than formatting each chart individually. Hopton publishes a library of free Power BI themes, covering styles from bold and executive to accessible and colourblind-safe, plus Microsoft-branded options for Fabric, Copilot, and Dynamics 365 Business Central reporting. They're free to download and use, no account or sign-up required; apply one via View, then Themes, then Browse for themes in Power BI Desktop. If you need more than a colour scheme, such as a governed data model behind the report, that's where our consulting work starts.

For years, getting a chart Power BI did not offer, or a layout the canvas would not allow, meant reaching for an SVG measure, an HTML content visual, or a stack of overlapping objects held together with hope. Those hacks work, but they take hours, break when someone resizes the page, and cannot be maintained by anyone who did not build them. Code-first reporting in Fabric makes most of them unnecessary: if you can specify a visual properly, you no longer need to smuggle it in through a workaround, which removes both the effort and the fragility.

The right way to design a KPI card is to show the value, the unit, the comparison and the direction. Comparison means against what: previous period, target, year on year. Direction means is up good or bad. Without those four elements, a KPI card is just a number. The best test is to imagine showing the card with no other context and asking yourself: would the reader know whether to be pleased or concerned?

A good example of a well-designed Power BI theme is 149 Degrees: a warm, bold palette built around deep amber and charcoal tones, tagged Bold and Executive, designed to hold strong contrast on board-level dashboards. Other examples in Hopton's free theme library cover different needs, such as Evergreen for sustainability-themed reporting, Maple for finance teams, and Beacon and Spectrum for accessible, colourblind-safe reports. Each is a downloadable JSON file with a defined accent colour and a five-colour swatch, applied via View, then Themes, then Browse for themes in Power BI Desktop.

We recommend skipping the Power BI design checklist in a few specific cases. For genuinely throwaway prototypes where the audience is one person and the report will not survive the week, the review effort is more than the report deserves. The trap is in the reports that say they are throwaway but then do not get thrown away. If there is any chance a report will go to a real audience, run the list.

You should apply the Power BI design checklist three times in the build cycle. At design, before any visuals are built, to set the bar for what good looks like. Mid-build, when there is enough on the page to spot direction-of-travel issues. And before sign-off, as the last thing that happens before release. Late-stage reviews catch the most issues but the cheapest issues to fix are the early ones.

A custom visual is a bad idea almost always, unless you have a specific reason the standard visuals cannot meet. Custom visuals add performance overhead, accessibility risk, and dependency on a third party who may stop publishing updates. Most reports do not need them. If you find yourself reaching for a custom visual, ask first whether a different standard visual would serve as well. The answer is usually yes.

Code-first reporting removes the technical limits that used to stop you building a bespoke visual, but removing a limit is not the same as needing to cross it. A custom visual is the wrong choice when a standard one would answer the question just as well, because every bespoke element is something your team has to understand, maintain, and carry forward when the person who built it moves on. The discipline is to reach for code when the requirement genuinely needs it, not simply because you now can.

Power BI reports often have inconsistent design because reports usually accumulate over months, with different builders, different stakeholders and different deadlines. Without a written standard, each addition follows the local convention rather than a global one. Consistency is the easiest thing to lose and the most visible thing when it is gone. Set a standard early, write it down, and review against it before anything new ships.

So many Power BI reports become walls of charts because adding charts is easier than thinking about which ones earn their place. A wall of charts is what you get when you say yes to every stakeholder request without asking what the page is actually for. The fix is editorial discipline. Each page should have one main message, and every visual on the page should support that message or be removed.