Power BI Mobile Layouts - What Actually Works on a Phone

Last year we sat in on a site meeting at a construction client in western Sydney. The project manager pulled out their phone to show us the "new dashboard" head office had rolled out. Pinch, zoom, scroll sideways, tap the wrong slicer twice. Then they gave up and rang the office to ask for the number they wanted.

That dashboard had cost real money to build. On a 27-inch monitor it looked great. On the device the people in the field actually carry, it was close to useless.

This happens all the time. Most Power BI reports in Australian organisations get designed on a laptop, by an analyst, for an audience that is assumed to be sitting at a desk. Then someone in sales, operations or a regional branch opens the Power BI mobile app and gets a shrunken version of the desktop canvas. Power BI has had a dedicated mobile layout feature for years now, and it's still one of the most underused parts of the product.

So here is what we've learned about doing mobile layouts properly, based on Microsoft's best practices for designing mobile layouts and a fair bit of trial and error on client projects.

How mobile layout works (quick refresher)

In Power BI Desktop, every report page has an optional mobile layout. You open it from the View ribbon, and you get a phone-shaped canvas with a Page visuals pane listing everything on the desktop page. You drag the visuals you want onto the phone canvas, resize them, and arrange them in a vertical scrolling layout.

A few things worth knowing up front:

• The mobile layout uses the same visuals as the desktop page. You aren't building a separate report. Filters, slicers and cross-highlighting all carry across.
• You can change some formatting for the mobile version only (font sizes, titles, labels and so on) without affecting the desktop version. This was a big improvement when it arrived.
• If a page has no mobile layout, the phone app shows the desktop page turned sideways. Users can still view it. They just won't enjoy it.
• Mobile layouts only apply when someone views the report in portrait on a phone. Tablets get the desktop layout.

That last point catches people out. We've had clients spend effort on mobile layouts expecting their iPad-carrying executives to see them. They won't.

Start with the question the phone user is asking

This is the most important thing and it has nothing to do with Power BI features.

A person looking at a report on their phone is almost never exploring. They are checking something. Did we hit the number yesterday? Is the job over budget? How many open tickets does my region have? They want an answer in under ten seconds, often while standing up or walking between meetings.

So before touching the mobile canvas, we ask the stakeholder a blunt question: "If you could only see three numbers on your phone, which three?" The answer is usually very different from what is on the desktop page. The desktop page might have twelve visuals including a detailed matrix, a decomposition tree and a scatter chart. The phone version probably needs two cards, one trend line and a slicer.

You don't have to put every visual on the mobile layout. In fact you shouldn't. Leaving things off is the whole point.

Visuals that work on mobile, and ones that don't

From what we've seen, these work well on a phone:

• Cards and multi-row cards. The single best visual for mobile. Big number, clear label, done. The newer card visual with multiple callouts is very good here.
• KPI visuals. Value, target and a small trend. Very readable.
• Simple line and column charts with a small number of categories. Five to seven bars, fine. Thirty bars, no.
• Gauges, if you must. I'm not a big fan on desktop but they read quickly on a small screen.
• Slicers set to dropdown style. These take very little space until tapped.

These are usually a mistake:

• Tables and matrices. Anything wider than three columns becomes a horizontal scrolling nightmare. If people really need detail, give them a drillthrough page instead of jamming the table into the main view.
• Maps. They technically work but pinch-zoom inside a map inside a scrolling page is an awful interaction. Use a bar chart by region.
• Scatter charts and anything with dense labels. The labels collide and become unreadable.
• Tile or button slicers with lots of options. They eat screen space fast.

There is a general principle under all this. The phone screen is narrow and tall, so visuals that grow vertically (bar charts with horizontal bars, stacked cards) fit better than visuals that grow horizontally.

Layout tips we keep coming back to

Put the most important number at the top. Users won't scroll if the first screen doesn't tell them something useful. We put the headline card or KPI right at the top, then trends, then slicers or supporting detail below.

Slicers go at the top or in a separate section, not scattered around. On desktop, slicers often sit down the left side. On mobile that doesn't translate, so we group them. Honestly, for a lot of mobile pages we leave slicers off entirely and rely on report-level filters or row-level security to show each person only their own data. A regional manager in Brisbane doesn't need a region slicer if RLS already limits them to Queensland.

Make visuals taller than you think. The default sizes when you drop a visual onto the mobile canvas are often too small. Text that's readable on the canvas preview in Desktop gets tiny on an actual phone. Bump font sizes for data labels and axis text using the mobile-specific formatting options.

Turn off things that waste space. Visual titles that repeat what the card already says, legends on single-series charts, axis titles that are obvious. On desktop these are minor clutter. On mobile they take a quarter of the visual's height.

Watch the tap targets. People use thumbs. If two small visuals sit next to each other, people will tap the wrong one and trigger a cross-filter they didn't want. Give interactive elements room.

Test on a real phone. Every time.

The mobile canvas in Power BI Desktop is a preview, not a promise. We've lost count of the number of times something looked fine in the Desktop preview and then looked wrong on an actual device. Font rendering differs. Visuals with responsive behaviour reflow differently. Dark mode on the phone can make some custom colours hard to read.

Our process now is to publish to a test workspace and have at least one person open it on an iPhone and one on an Android device before we call it done. Ideally that person is someone from the actual target audience, not the developer. Watching a sales rep use the report for two minutes tells you more than an hour of tweaking in Desktop.

What's still rough

I'll be honest about the gaps, because there are a few.

It's per page, and it's manual. Every page needs its own mobile layout, built by hand. For a report with fifteen pages that's real work, and there's no "auto-generate a sensible mobile layout" option that actually produces something good. Microsoft has experimented with automatic mobile layouts, but in our experience you still end up rearranging most of it.

Maintenance drift. When someone adds a new visual to the desktop page six months later, nobody remembers to update the mobile layout. The phone version slowly falls out of sync. We now include "check mobile layout" in the report change checklist for clients who rely on mobile.

Custom visuals vary. Some third-party visuals from AppSource behave fine on mobile. Others don't render well or don't respond to touch properly. Test them specifically.

No tablet-specific layout. Mentioned above, but it's worth repeating. If your field staff carry tablets, you're designing the desktop layout for them too.

Should you build a separate mobile report instead?

Sometimes, yes. If the mobile audience is genuinely different from the desktop audience (say, store managers on phones versus analysts at head office), a separate small report built for phone use first can be cleaner than trying to make one report serve both. It can also point at the same semantic model, so you aren't duplicating data or logic.

For most organisations though, adding mobile layouts to two or three key pages of an existing report is the right starting point. Pick the pages that people actually open on their phones. The usage metrics in the Power BI service will tell you which reports get mobile traffic, and it's often a surprisingly short list.

Where this fits in a bigger picture

Mobile layout is a small feature, but it's a good test of whether a reporting project was designed around users or around data. If nobody on the project asked "who opens this on their phone and what do they need?" then there are probably other usability gaps too.

When we run Power BI consulting engagements, mobile is part of the requirements conversation from day one, especially for clients with field teams in construction, mining or logistics where people are rarely at a desk. If you're thinking more broadly about how reporting and AI fit together for frontline staff, our work on AI for business intelligence covers some of that, and we're always happy to have a chat through our contact page.

The short version: decide what the phone user needs, show only that, make it big, and test it on a real phone. It's not complicated. It just rarely gets done.