Mobile layouts: designing dashboards for phones and field crews

The dashboard that failed in the truck. Picture a storm night at a utility, with three hundred outage reports and counting. The operations center has a beautiful dashboard on the wall. It shows outage counts, a map of downed lines, a chart of calls by hour and a list of crews. A supervisor shares the link with a line crew. The foreman opens it on his phone, in the rain, in a truck. The map is a postage stamp, the chart labels overlap, and the list he needs is five screens down. He gives up and phones the control room, which is exactly the call the dashboard was supposed to replace. In this lesson we fix that by designing for the phone on purpose.

What you will learn. By the end of this lesson you'll be able to do three things. First, explain what ArcGIS Dashboards actually does when someone opens it on a narrow screen, so nothing surprises you. Second, plan a phone layout around one field role and the few questions that role asks, using a water main break crew as the worked example. Third, test that layout properly and decide whether a single responsive dashboard is enough, or whether the field crew deserves its own trimmed copy. These three skills are what separate a dashboard crews actually open from one they quietly ignore.

What happens on a narrow screen. ArcGIS Dashboards is responsive. That's a web design word meaning the page adapts to the width of the screen, like water taking the shape of its glass. On a wide monitor your elements sit side by side exactly where you placed them. On a phone there isn't room for that, so Dashboards stacks the elements into a single column. Each element takes the full width, and the user scrolls down through them. The header and any side panel with selectors also adapt to save space. You don't draw a separate phone layout by hand. You influence it through the choices you make in the desktop layout.

Stacking order decides what comes first. Here's the practical consequence. The order of the stack on a phone follows your desktop layout, roughly from the top of the dashboard downward, with the top-left content tending to come first. So whatever you place at the top of the desktop design is what a field worker sees without scrolling. If your top row holds a decorative logo and a big trend chart, that's what fills the phone screen. So what should sit at the top for a crew? The one thing they need right now, usually a count or a short list. Treat the documented order as a guide, and always confirm it on a real phone.

Design for one role and three questions. Good phone dashboards start with a person, not with data. Name the role. For our example, it's a water main repair crew. Then write down the questions they ask during a shift. Where is my next break? How urgent is it, meaning is a hospital or a school on that line? And who do I call if I need a valve shut? That's three questions, so aim for three to five elements that answer them, and drop everything else. It feels harsh to cut the hourly trend chart, but that chart helps the manager, not the person holding a shovel. Big numbers, short lists and simple maps read best on a small screen.

Worked example: the water main crew view. Let's build it. At the top, an indicator shows the number of open breaks assigned to this crew, filtered by a crew field in the service request layer. Each crew gets its own link with its crew name as a URL parameter, so the indicator and the list show only that crew's breaks. Next, a list of those open breaks, sorted by priority, showing the street address and the time reported, because crews think in addresses. Tapping an item can filter or zoom the map. Third comes the map, with breaks and valve locations, starting zoomed to the service area rather than the whole county. Last, a rich text element with the supervisor's phone number and shift notes. Four elements, each answering one of the crew's questions, in the order they ask them.

Plan the scroll before you build. Before you touch the editor, do a rough scroll budget. A pixel is one dot on the screen, and we assume a phone shows about seven hundred usable pixels at a time. Add up the heights. The count takes one hundred fifty, the list four hundred, the map four hundred fifty and the notes two hundred, so twelve hundred pixels in total. Twelve hundred divided by seven hundred is about one point seven screens. The count, the list and the top of the map all appear on the first screen, and the notes begin on the second screen. If your total comes out at six or seven screens, crews will never reach the bottom, and that's a sign to cut elements.

Make each element phone friendly. Once you know which elements stay, tune each one for a thumb and a glance. Indicators should show one large value with a short title, like Open breaks, not a sentence. Lists work best with two lines per item, with the key field first, such as the address, then the priority and time underneath. Where two related elements both matter, stack them as tabs in one slot, so the crew switches between them instead of scrolling past both. Charts are the hardest on phones, because long category labels get squeezed. Shorten the labels, or accept that the chart belongs on the desktop version only.

One dashboard or two?. Now the big decision. If the office and the field want roughly the same information, one responsive dashboard is enough, as long as you order the elements with the phone in mind. But often the needs are very different. The operations center wants trends and totals, while crews want their own jobs. In that case, save a copy of the operations dashboard, trim it down to the crew elements, and share that copy with the field crew group you set up in the previous lesson. The copy reuses the same layers, so there's no extra data to maintain. Finally, test it on the phones crews actually carry before you send the link.

Common mistake: the map that traps the thumb. Here's the trap that catches almost everyone. On a phone, a map element grabs touch gestures. When a crew member swipes up to scroll the page, and their thumb lands on a large map, the map pans instead of the page moving. If the map fills most of the screen, the elements below it feel unreachable, and people assume the dashboard is broken. The fix is simple. Keep the map element shorter, place it after the count and the list so there's page to grab above it, and test by actually swiping through the dashboard with one thumb, not by resizing a desktop browser window.

Recap. Let's pull it together. First, on a phone ArcGIS Dashboards stacks your elements into a single scrolling column, and the desktop layout decides the order, so the most urgent element belongs at the top. Second, design for one role and the few questions they ask, keep three to five elements, and make each one readable at a glance, just like our water main crew view. Third, test with real phones and a real thumb, watch out for maps that trap the swipe, and when office and field needs differ, copy the dashboard and trim a phone version for the crew group.

Your exercise. Before the next lesson, try this. Pick a dashboard you already own, or build a quick one on a layer from Esri's Living Atlas, a free library of ready-made map layers, such as traffic incidents or current weather warnings. Name one field role, for example a traffic incident responder, and write down the three questions they ask during a shift. Save a copy of the dashboard and trim it until it answers only those questions, with the most urgent element at the top. Then open it on your own phone, scroll with one thumb, and fix the first problem you run into. Next time we'll put dashboards inside Experience Builder and Hub sites.