The question usually arrives a few weeks after launch: "Can I do this on my phone?" It is a fair question. Staff in a workshop, a warehouse or a car do not sit at a desk, and a tool that only works on a large screen leaves them with paper or messages again.
The answer is rarely "everything" or "nothing". Making every screen comfortable on a phone is expensive, and many screens would never be used there. This article gives a short way to decide which tasks deserve mobile support.
Decide per task, not per screen
Start with a list of what people actually do in the tool. For each task, ask three questions:
- Who does it, and where are they? A manager approving requests between meetings is different from an office clerk entering fifty invoices.
- How long does it take? A task that takes under a minute suits a phone. A task that takes twenty minutes and needs several windows does not.
- What would they do instead? If the alternative is waiting until they return to the office, a small mobile feature can save days. If the alternative is waiting an hour, it probably cannot.
Write the answers in a table. A spreadsheet is enough, and it often shows that only four or five tasks matter on mobile.
What usually belongs on the phone
Tasks that work well on a small screen are short, have few fields and happen away from a desk:
- Approving or rejecting a request, with the key facts visible without scrolling.
- Looking something up, such as a customer's contact details, an order status or an address.
- Capturing a photo, a short note or a signature at the place where the work happens.
- Changing a status, for example "delivered" or "in progress".
- Receiving a link from a notification and opening the exact record.
For each of these, aim for one clear action per screen. A phone is held in one hand, often outdoors, and attention is short.
What usually stays on the desktop
Some work is simply better on a large screen, and pretending otherwise produces frustration:
- Long data entry with many fields or pasted data.
- Wide tables with many columns and comparisons.
- Reports and exports, which people read and often move into other documents.
- Administration, such as managing users and settings.
It is fine to say so. A short line such as "Reports are available on a computer" is better than a screen that technically loads but cannot be used. Where a desktop-only task is sometimes needed on the move, a tablet in landscape often works, so decide separately whether tablets count as a phone or as a small desktop.
Practical points that are easy to miss
Touch targets. Buttons and links that are comfortable with a mouse are hard to hit with a thumb. The WCAG 2.2 guidance on target size gives a minimum for how large and how far apart they should be; use it as a floor, not a goal.
Layout. The same page can adapt to the screen width. The web.dev introduction to responsive design explains the basics your developer will know. Your part is to decide which content comes first on a small screen.
Test on a real device. A narrowed desktop browser window does not show glare, gloves, a slow connection or a thumb covering half of the screen. Give a phone to someone who will actually use the task and watch them do it once.
Sign-in. Typing a long password on a phone is painful, and people respond by choosing weak ones. Agree how sign-in works on mobile, in line with how access in the tool is managed, and what happens when a phone is lost.
Signal. In a basement, a hall or a field the connection drops. Decide in advance what the tool does then: show a clear message, keep what was typed, or save it and send it later. Saving for later is more work to build and has its own risks, such as two people changing the same record, so choose it only where the need is real. The MDN overview of progressive web apps describes what is technically possible.
Personal data on personal phones. If staff use their own devices, decide what may be stored on them, and keep sensitive data in the tool rather than in photos and messages.
Tell people what is supported
Once decided, write it down in two lines: "On a phone you can approve, look up and add a photo. For everything else, use a computer." Put it in the release notes and, if useful, on the tool's start page. Without it, people try, fail and decide the tool is broken.
Common mistakes
- "Make everything mobile." Costly, and most of it is never used.
- Shrinking the desktop screen. A small copy of a wide table is not a mobile design.
- Testing only in the office. Real conditions differ.
- Ignoring signal. The first lost entry costs trust.
- Not saying what is not supported. Staff guess, and guess wrong.
A first step
Pick the five tasks people most often ask about doing away from a desk. For each, write who does it, where, how long it takes and what they do now. Mark each one "phone", "tablet" or "desktop", and show the list to two of the people who would use it.
Sources
- W3C, WCAG 2.2: Understanding Success Criterion 2.5.8, Target Size (Minimum)
- web.dev, Responsive web design basics
- MDN Web Docs, Progressive web apps
- This article is a planning aid. The examples are generic. No client results or performance figures are claimed.