Mobile-first intranet design: making everyday work easier on a phone

An employee should not need to get back to a desk to read an update, find a policy, or contact a colleague. Mobile intranet design should make those everyday tasks easy wherever employees are authorized and able to work.

For frontline and field teams, a phone may be the main route to company information. For others, it is an occasional convenience between meetings or away from their desk. Either way, fitting a desktop page onto a smaller screen is only the beginning. Sign-in, navigation, reading, forms, and downloads all need attention.

Start with the tasks employees need to finish, then design and test the whole journey.

In this article:

• Why does the phone experience deserve its own attention?
• Why is a smaller desktop page not enough?
• How do you make everyday tasks comfortable on a phone?
• How do you keep the intranet light on mobile data?
• How do you keep mobile access inclusive?
• How do you test with employees and keep improving?

Why does the phone experience deserve its own attention?

A field employee needs a colleague’s phone number. A shift worker wants to check an operational update before starting work. Someone visiting another office needs to open the travel policy.

These are small tasks, but a difficult intranet turns them into delays. If the answer is “find a desktop computer,” convenient access has already failed.

During requirements gathering, ask employees about their actual working conditions:

• Which tasks do they need to complete on a phone?
• Who relies on mobile access, and who uses it occasionally?
• Which company-issued, personal, or shared devices are approved?
• What connections are available where they work?
• Do short breaks, bright light, or frequent interruptions affect use?

Do not assume everyone works under the same conditions. A warehouse employee using a shared device on company Wi-Fi has different needs from a field employee using an assigned phone.

Agree on priority mobile tasks and approved access options before designing the homepage. HR and IT should also clarify whether personal phones are permitted and what alternatives employees have. Access to essential information should not depend on an unspoken expectation that employees supply their own device or pay for data.

Why is a smaller desktop page not enough?

Responsive layout makes content adapt to the screen. A useful mobile experience goes further: it lets someone finish a task comfortably with touch.

A page can fit a phone and still be difficult to use. For example:

• A collapsed desktop menu hides the link employees use most.
• Small icons sit so close together that people tap the wrong one.
• A large banner pushes the useful answer far down the page.
• A wide table requires repeated sideways scrolling.
• A policy is available only as a document designed for printing.

Employees should not need to request the browser’s desktop site, pinch and zoom, or hunt across a page to complete ordinary tasks. Nor should essential information disappear simply because the screen is smaller.

Consider finding a leave policy.

Before: An employee opens the menu, guesses which department owns the policy, navigates several pages, and downloads a PDF to find the request instructions.

After: Visible search leads to a readable policy page. The page explains eligibility and request steps near the top, links to the leave system, and retains the formal document as a clearly labeled download.

The second journey reduces searching and unnecessary downloads without removing information.

There is also a distinction between layout and data use. Requesting desktop mode does not necessarily increase downloads by itself. The resources a page requests determine how much data transfers. A responsive page may still download a large desktop image and merely display it at a smaller size.

How do you make everyday tasks comfortable on a phone?

Start with a short list of employee priorities, such as reading updates, finding contacts, checking policies, and submitting requests. Give these tasks a clear route rather than shrinking every desktop component equally.

Make navigation predictable. Keep search easy to find and use familiar destination labels such as “People,” “Policies,” and “Help.” A compact menu can hold less-used destinations, while a small set of frequent actions remains visible. Keep those labels and positions consistent across pages.

Touch controls need enough space to distinguish one action from another. Avoid interactions that depend on hovering, and do not rely on an unexplained icon when a short label would remove doubt.

Put the answer before the decoration. On a policy page, lead with what employees need to know and what they should do next. Use readable text, meaningful headings, and short sections. A large introductory image should not stand between someone and an urgent answer.

Publish everyday guidance as web pages where practical. Keep required original documents available, but label them clearly so employees can decide whether they need the download.

Make forms forgiving. A phone is not a comfortable place to work through unnecessary fields. For each form:

• Ask only for information needed to process the request.
• Use suitable input types, such as an email field for an email address.
• Keep visible labels rather than relying on placeholder text.
• Explain errors beside the affected field and say how to correct them.
• Preserve valid entries after an error.
• Where appropriate, provide a secure way to save progress through interruptions.

Any saved form data needs handling rules appropriate to its sensitivity, particularly on shared devices.

Treat sign-in as part of the task. Test company login, authentication prompts, redirects, and the return to the intended page. An employee opening a policy link should not land on the homepage and have to start searching again. Address broken journeys without weakening authentication.

Follow the task beyond the intranet, too. A usable request page achieves little if its button opens a connected HR service that is difficult to operate on a phone.

Build these patterns into a reusable design system. Shared search fields, navigation, buttons, form errors, download labels, and policy templates reduce repeated design and testing work. Document how each component behaves on small screens and with assistive technology. Give the design system an owner so new pages reuse tested patterns instead of introducing a different interaction every time.

How do you keep the intranet light on mobile data?

Smaller downloads help employees reach information sooner when they use mobile data or a slower connection. This is about respecting their time and connectivity, not chasing a technical score.

Begin with images. A phone should not receive a large desktop image when a smaller version can display it appropriately. Ask the implementation team to check image selection against both screen size and pixel density. The web.dev guidance on responsive images explains how browsers can select suitable image resources.

Then review what each page loads:

• Compress images and choose suitable formats without making important details unreadable.
• Remove scripts and third-party widgets that do not support the task.
• Avoid autoplay video and let employees choose when to load media.
• Prioritize the content needed to read or act instead of waiting for every optional element.
• Show document file types and sizes before download where possible.

For a large attachment, consider whether a short web summary can answer the immediate question. An employee checking an expense deadline should not need to download an entire handbook. Keep the full document available when the detail matters.

Test both a first visit and a repeat visit. Cached resources may make a return visit faster while hiding the cost faced by someone opening the page for the first time. Check representative slower connections as well as office Wi-Fi.

Ask the technical team to inspect transferred data and slow requests in browser developer tools. Editors can choose appropriate media and write useful summaries; they should not be expected to implement responsive image delivery, script loading, or caching.

Set performance expectations around the agreed tasks and actual working conditions. “An employee can read the shift update without waiting for optional media” is a more useful starting point than an unexplained score.

How do you keep mobile access inclusive?

Accessibility is a requirement for an employee tool, not an optional finishing touch. Employees with visual, hearing, motor, and cognitive disabilities may need different ways to read, navigate, and interact.

Include these essentials in page templates and components:

• Readable contrast and text that can enlarge without hiding content or actions.
• Meaningful headings and clear form labels.
• Captions for video with spoken information.
• Controls with understandable names that work with assistive technology.
• Visible keyboard focus and a logical navigation order.

Some choices also help in everyday conditions, such as bright light or one-handed use. Those benefits do not replace the needs of employees with disabilities.

Responsive design does not automatically make an intranet accessible. Include keyboard and mobile screen-reader checks alongside touch testing. Use WCAG as a reference for acceptance criteria, with the W3C guidance on mobile accessibility providing further direction.

How do you test with employees and keep improving?

Test real tasks on representative phones before a broad rollout. Shrinking a desktop browser window helps during design, but it cannot reproduce every touch interaction, on-screen keyboard, login redirect, or mobile screen-reader behavior.

Recruit employees from the groups identified during research. Include their devices, browsers, network conditions, and accessibility needs. Run sessions in safe settings, never while someone is driving or operating equipment.

Use a compact test plan:

Task	Test condition	What to observe
Sign in from an update link	Approved phone using company authentication	Can the employee finish sign-in and reach the intended update?
Find a leave policy	Phone in portrait orientation, without coaching	Are search and labels understandable? Is the answer readable without repeated zooming?
Open a file	Representative slower connection	Are file type and size clear? Does the file open in a usable viewer?
Locate a colleague	Touch use and a mobile screen-reader check	Can the employee identify the correct person and use the contact action?
Complete a short form	On-screen keyboard, a deliberate error, and an interruption	Are errors clear? Do valid entries remain? Can the employee resume safely?

Ask people to complete tasks without coaching. Watch for missed taps, confusing menus, repeated sideways scrolling, slow downloads, and lost form entries. If someone gets stuck, record where and why before showing them the intended path.

Agree on task-level expectations before the pilot. For example, an employee should be able to find a policy using ordinary workplace language and follow its request link without switching to a desktop. Use pilot observations to set realistic completion-time expectations rather than choosing arbitrary targets.

Combine these findings with available aggregate mobile usage data and employee feedback. Traffic alone is not proof of success: a short visit could mean a quick answer or an abandoned task. Investigate the cause.

Assign fixes to the relevant owners, including UX, IT, content owners, and connected-service teams. Resolve barriers to priority tasks before wider rollout, then repeat key tests after changes to menus, templates, forms, or integrations.

Keep a feedback route that works on a phone. Employees should not need desktop access to report that mobile access is failing them.

Ready to make your intranet work better on a phone?

Choose one common employee task and try it on the devices and connections your colleagues actually use. Start with sign-in, follow every link, and check whether the task can be completed without workarounds.

If you are planning a new intranet, talk with the Open Intranet team about configuring and testing the mobile experience around those tasks. Built on Drupal, Open Intranet is an Open Source starting point; usability, performance, and accessibility still need deliberate design and testing. Start with the work employees need to do, then build the experience around it.