Which desktop workflows belong on mobile?

Start with the place and the decision

Ask why somebody opens the system on a phone before shrinking the desktop menu. Looking up equipment on site, reviewing one pending request while traveling and checking a management summary before a meeting involve different evidence and input costs. Record the role, location, available time, network conditions and consequences of the decision on a task card. This gives the first release a defensible scope.

Tasks that require extensive comparison, many simultaneous edits or complex rule configuration may remain on desktop. Mobile should then explain the limit and provide a sensible continuation route. Hiding a button without explanation can make users think they lack permission. Conversely, inconvenient screen space is not a reason to remove evidence needed for a decision.

Retain, rearrange or defer

• Retain: short paths such as looking up a record, checking its state or identifying the responsible person.
• Rearrange: approvals, checklists and field notes, with essential evidence before the action and inputs in a usable vertical sequence.
• Defer: work requiring broad cross-record comparison, complex bulk editing or specialist input equipment, with the alternative route documented.

This is not a universal list of features. A one-button confirmation can still have substantial consequences. Its apparently simple presentation does not justify removing checks. Decide access from the actual task and applicable requirements rather than from the number of controls.

Keep decision context in the mobile detail view

Imagine a supervisor reviewing an exceptional request away from the office. The mobile detail view needs to identify the object, explain the exception, expose relevant amounts or quantities and show what the action will do. A title and an approve button do not form a complete task. If an essential attachment cannot be read on the phone, allow the decision to wait instead of encouraging approval without evidence. This is a hypothetical planning example.

Design filtering, opening a detail, returning to the previous position and moving to another pending item as one journey. People may answer a call or switch applications in the middle. On returning, they need to know what was saved and whether the record remains current. Silent data loss and accidental repeat submissions are different failures and need different recovery paths.

Rearrangement is not content removal

The WCAG 2.2 explanation of reflow addresses retaining information and functionality at narrow viewports while recognizing exceptions for content whose meaning requires two dimensions. Ordinary explanations and form fields should wrap. A genuinely comparative table may scroll within its own region. Scaling the entire page down or clipping its final columns is not an adequate adaptation strategy. The reference does not certify this particular system.

Controls also need testing with touch. Check adjacent actions, the software keyboard, browser bars and orientation changes. A narrow desktop window cannot reproduce every phone condition. Authentication, permissions, file access and submission rules must still be enforced by the business system; mobile styling cannot substitute for them.

Define what the first mobile release must prove

1. Give each retained task an entry condition, required evidence and observable completion state.
2. On the intended phone, start from the list, complete the action and return. Include long names and representative attachments.
3. Simulate slow networking, session expiry and backgrounding. Check both input preservation and result visibility.
4. Inspect every deferred operation for a clear explanation and a usable continuation route.
5. Review the result on desktop using the same account. The two interfaces must not create incompatible business records.

Scope page rearrangement, front-end implementation and additional server capabilities separately. If the current API cannot support a mobile transaction, a read-only first release can still be useful, provided that limit is explicit. A website that opens on a phone should not be described as a complete mobile workflow until the agreed tasks have actually been verified.

Choose which tasks must be completed on site, then record input, connectivity and one-handed use conditions. Display adaptation establishes viewing constraints; a business prototype establishes the task path. Those are the useful inputs for UI design services (Chinese), rather than an instruction to shrink a desktop page until its controls fit a phone.