Mobile-first dashboards — why 90% of admin portals get this wrong

The owner checking today's revenue from the couch at 10pm does it on his phone. The warehouse employee updating stock does it on her phone. The freelance photographer checking invoice status in a customer portal — phone.

And yet 90% of admin portals are designed as if they'll run in an office on a 27-inch screen. The result: buttons too small, tables that scroll horizontally, forms that show the wrong keyboard for every numeric field, and a hamburger menu that hides the three things you actually use.

What mobile-first actually means

Not "works on mobile too". Not "the top 80% scales down". Mobile-first means: the primary flow is designed on a phone, and the desktop version is an extension of that.

In practice:

• Stat tiles in a 2x2 grid on mobile, four-in-a-row on desktop
• Tables become cards on mobile, not horizontally scrolling grids
• Form inputs with inputmode="numeric" for amounts, inputmode="email" for email, inputmode="decimal" for prices
• A sticky action button at the bottom (where your thumb actually is), not top-right
• Three taps maximum to the most-used action — not "open menu, scroll, sub-menu, scroll, tap"

If the most important screen of the system can't be used one-handed while standing in a warehouse, it's not finished.

Why agencies get this wrong

Designers work on desktop. Stakeholders review on desktop. The mobile prototype usually shows up somewhere around week seven. By then the information architecture has hardened around a desktop mental model — sidebar with twelve menu items, dense table with fifteen columns, modal dialogs that assume a mouse.

That's exactly the same pattern as an Excel-to-admin migration where the old desktop workflow keeps shaping the digital version instead of the other way around. The interface gets translated, not redesigned.

On the custom projects I build, I start every screen with the mobile wireframe. Not as a concession to "mobile too" — as the starting point. The question I ask first is: what does the owner need to see and do here in twenty seconds, on a phone, with one hand, possibly in sunlight? Everything else is layered on top of that answer.

The screens that matter most

Not every screen in an admin system needs the same mobile treatment. Three categories cover most of what actually gets used outside the office.

The "what's happening today" screen

For a rental business: today's pickups, today's returns, payments still pending. For a workshop: jobs in progress, ready for pickup, waiting on parts. This is the screen people open in the morning and at night. It needs to load in under a second, show four to six numbers, and let you tap straight into any of them.

Build this as a vertical stack of cards on mobile. No tabs, no filters above the fold — those go below or behind a single button. The number you tap should take you to a filtered list, not a generic overview.

The quick-edit screen

Update a price, mark something paid, change a status, add a note. These actions happen dozens of times a day and almost never sitting at a desk. On mobile they should be: open the item, see the field, edit, save — four taps maximum. No "edit mode", no separate form page, no modal that covers the field you're trying to read.

The customer-facing portal

If your customers log in to see their bookings, invoices or repair status, assume 80% of them are on a phone. A two-column desktop layout that collapses to one column on mobile is fine. A desktop dashboard with sidebars and toolbars that gets crammed into 375 pixels is not.

Where I see the worst patterns

A few things keep showing up in systems built by larger agencies or generic SaaS tools:

• Date pickers that need a mouse. A native <input type="date"> works fine on every phone. A custom JavaScript date picker that requires precise tapping on a 24×24 pixel cell does not.
• Numeric fields without inputmode. Typing € 1.250,00 on a full alphabetic keyboard is the kind of friction that adds up to minutes per day.
• Action buttons in the top-right corner. Reachable with one hand on a 13-inch laptop. Not reachable on a 6.7-inch phone without shifting your grip.
• Tables with horizontal scroll. You either hide columns and people can't find data, or you keep them all and people scroll sideways forever. Cards solve this.
• Modals stacked on modals. Fine on desktop. On mobile a second modal often covers the close button of the first one.

When mobile-first is not the right call

Honest section. There are admin systems where mobile-first is the wrong starting point:

• Heavy data-entry tools used exclusively by office staff at desks all day — accounting back-offices, dense order-entry screens, anything where a numeric keypad and three monitors actually help. Design those for desktop first.
• Reporting and BI dashboards with twelve charts that need to be compared side by side. A phone screen literally cannot show that, and pretending otherwise produces a worse desktop experience.
• Configuration screens that are touched once a month by one admin. Don't spend a week perfecting the mobile version of a settings page nobody opens on a phone.

The rule I use: if the screen is opened more than once a day by someone who is not sitting at a desk, design it mobile-first. Otherwise, design it for whichever device the actual user will be on.

What this means for your system

If you already have an admin or customer portal and you can't comfortably do the three most common actions on your phone in under twenty seconds each, the design is working against you — not against your users, against you, the owner, who checks numbers in the evening and answers customer questions from the car.

That's fixable without rebuilding everything. Often it's restructuring two or three core screens, switching tables to cards on small screens, and getting the keyboard modes right on form inputs. Two to three weeks of work, not six months.

---

A custom admin system designed for the phone from day one still feels fine on desktop — the other way around almost never works. Two languages (Spanish + English as equal rails, optionally Dutch), one person you talk to directly, a flat monthly price, and a working version in four weeks.

Send me what you're using now and I'll sketch within a day how the mobile side should look. Honest answer within a day, no pitch deck. Or read more about the customer portal panel if that's the piece you want to fix first.