Mobile dashboards: what to include and cut

People use phones in gaps: before a meeting, on a site visit, while travelling. The mobile job is usually to check a status, confirm a change, or respond to an alert. It is rarely to explore a dataset or compare twelve regions.

Write the mobile job in one sentence. If the sentence contains and, split it. A dashboard that supports a daily check and a monthly board review will serve neither on a small screen; build the check view and link to the full report for the review.

The first screen should answer the most common question without a tap. Show the current value, the comparison that gives it meaning, and a short trend. A target or threshold turns a number into a judgement.

Three metrics is a practical ceiling for the first screen; more compete for attention and push the trend below the fold. Put the refresh time near the top so the viewer knows whether the number is current. If a metric is stale, say so rather than hiding it.

Cut dense tables, multi-series charts with long legends, secondary breakdowns, decorative images, and precision that nobody acts on. A revenue figure does not need four decimal places on a phone.

Reduce filters to one dimension with a sensible default. Every additional filter adds a tap, a chance of an empty state, and a query. Move comparisons and breakdowns to a detail page reached by tapping the metric. Remove hover tooltips or provide a tap equivalent, since hover does not exist on touch screens.

Stack cards vertically and let the page scroll in one direction. Horizontal scrolling inside a dashboard is hard to discover and easy to trigger by accident. Full-width cards give charts room and make tap targets predictable.

Keep interactive targets at least 44 pixels in both dimensions, with spacing between them. Put primary actions within thumb reach and keep navigation in a consistent position. Test with large text settings; labels that fit at default size often truncate when the user increases font size.

Mobile connections are slower and less predictable than office wifi. Compress images, limit the number of visual queries, and avoid auto-refresh while the page is in the background. A dashboard that polls every minute drains battery and adds little to a daily check.

Design the loading, empty, error, and stale states. A blank screen on a dropped connection looks like a data failure. Show the last successful value with its timestamp, and a retry action. Skeleton placeholders are better than a spinner that covers the whole page.

Desktop browser emulation is a useful first pass, but it misses touch behaviour, keyboard differences, and real network conditions. Borrow a mid-range phone, not the newest flagship, and use it for ten minutes.

Run the checks below before calling the mobile view finished. They catch most of the problems that emulators hide.