Mobile design: prioritising content for small screens

Small screens reveal the order of information particularly clearly. Content placed side by side on a desktop appears in sequence. A secondary image can push an essential explanation far down the page. A short label can wrap into a substantial part of the navigation.

This guide plans a mobile version for a fictional household appliance repair service. All tasks and examples are original educational material. It does not claim invented usage figures, customer results or universal improvements.

1. Define the main task precisely

Start with a situation: someone needs to establish whether their appliance is supported and how to prepare an enquiry. That creates different priorities from an internal wish to place the entire company history in the opening section.

Avoid unsupported assumptions about mobile users. People also read extensive material on phones. The task is to make the journey through that material understandable. Less screen space does not automatically mean less professional interest.

Our example records questions about supported appliances, service area, information needed for a first response and the kinds of enquiry actually accepted. Those questions guide sequence and navigation.

Another audience may already have an appointment and need preparation documents. It needs a direct route without repeating the entire sales journey. Connect the tasks deliberately rather than forcing every visitor through the same process.

2. Begin with a linear content version

Write the essential material as a simple sequence. Offer, prerequisites, process and enquiry are possible groups. Explain which question each group answers. Give a decorative opening substantial space only when it genuinely supports orientation.

The linear version also supports later desktop work. Related information can appear side by side while the basic reading order remains coherent. Visual rearrangement should not produce a contradictory interaction sequence.

This is a proposal for the described task. Other offers need different decisions. Existing customer access or an urgent service function may justify another early entry when the actual process requires it.

3. Establish the viewport correctly

A mobile design needs a suitable technical foundation. Viewport metadata helps a browser display the page in the intended relationship to device width. Without that foundation, a responsive layout may behave differently on the device from what the designer expects.

<meta name="viewport" content="width=device-width, initial-scale=1">

The MDN viewport reference explains these values. Avoid unnecessary restrictions on enlargement. People require different presentation sizes and should be able to use their browser's facilities.

The declaration does not create a complete responsive layout. Fixed minimum widths, wide tables and long strings can still overflow. Inspect the actual content and containing elements when sideways scrolling appears.

4. Treat reflow as an information task

A layout change involves more than the number of columns. Each group still needs a recognisable relationship. A heading belongs to its explanation. Wrapping should not make a qualification appear to refer to another service.

The W3C reflow explanation addresses narrow or enlarged conditions without loss of information or functionality and describes exceptions for content requiring two dimensions. Apply the conditions to the actual case rather than making a general compliance claim.

The repair description and its limitations need to remain understandable together. A complex data table may use a bounded scrolling region. That does not mean the surrounding page should become unnecessarily movable sideways.

Test enlarged text as well. A page may fit a 390-pixel viewport with default text and clip labels after personal enlargement. Inspect several real states rather than one static specimen.

5. Make navigation understandable early

Compact navigation must communicate its function. Labels should retain the meaning they have in the wider view. Hiding a service area under a completely different mobile name makes returning visitors learn the organisation again.

An expandable region needs an understandable control and recognisable state. Destinations should be reachable when it is open, with a sensible continuation after it closes. Full-screen overlays introduce additional questions about focus and obscured content.

For a small number of destinations, an openly visible wrapping set of links may suffice. Use a complex menu when its value justifies the extra interaction and testing work. Let content and tasks determine the choice.

Complete several journeys: open navigation, find a service, return and choose another destination. Back navigation can reveal a different state from initial loading. A screenshot does not demonstrate the complete sequence.

6. Check controls with actual touch and keyboard input

Small adjacent targets can lead to accidental activation. Review both the visible element and its actual interactive area. A decorative icon may look larger than the link region behind it.

The W3C minimum target size explanation describes the applicable WCAG 2.2 criterion with spacing alternatives and exceptions. Assess those conditions specifically rather than replacing them with one universal pixel rule.

Our example checks contact links, menus and forms on actual devices. A generous contact action offers little help if a difficult close control blocks the next step. Include every interaction necessary for completing the task.

Mobile devices can also use physical keyboards and assistive technologies. Do not assume touch is the only input method. Visible focus and a meaningful order remain relevant.

7. Limit forms to the first necessary step

The on-screen keyboard occupies additional space, making long forms particularly demanding. Ask for information needed for the initial professional response. Complete technical documentation can be requested later where appropriate.

The repair service might need appliance type, a short fault description, location and a reply channel. Decide mandatory fields from the actual process. A field should not be required merely because it existed in an older form.

Labels remain visible during entry and instructions explain what is expected. Errors identify the affected field and useful correction. Preserve completed information where appropriate rather than making the person start again.

Review with the keyboard open. Is the active field visible? Can the next action be reached? Does an error remain associated with the relevant input? A narrow desktop viewport cannot establish every aspect of that behaviour.

8. Deliver images by purpose and size

A large desktop image can occupy much of a small screen while explaining little. Identify the visual information needed for the task. A tighter crop can help if the important detail survives.

The web.dev responsive image explanation covers adaptable delivery and alternative crops. Plan the intended information separately from the required resource size. An image displayed smaller should not unnecessarily load the same oversized file.

An actual appliance photograph might explain where to find a model plate. Cropping away that exact region removes its purpose. A suitable text alternative and nearby explanation can provide the relationship in another form.

A decorative cover and a necessary instruction image have different priorities. Choose order and loading behaviour from actual position and meaning. A blanket rule for every image may harm the initial display or download unnecessary resources.

9. Manage content density deliberately

A compact presentation comes from clear organisation. Do not force it solely through smaller type and tighter spacing. Essential explanations must remain readable. A short page filled with ambiguous abbreviations can require more work than a longer, well-organised guide.

Divide substantial explanations into meaningful sections. A contents navigation can offer direct entry points. Expandable details can support supplementary questions when the important information does not become invisibly hidden.

Price qualifications, essential prerequisites and the actual commitment implied by an action should not disappear merely to save space. The mobile version requires the same professional care as the wider presentation, even when the visual arrangement differs.

Review a concrete task rather than page length alone. Additional depth is useful when people can find and understand the information they need. The number of screenfuls is not a complete measure of quality.

10. Implement a flexible content area

This CSS sketch provides one possible service overview. A single column is the starting point. Wider views add columns when the content has enough space. Verify the specific values against the actual project.

.service-list {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1.25rem;
}
.service-card { min-width: 0; padding: 1.25rem; }
.service-card h2 { overflow-wrap: anywhere; }
@media (min-width: 48rem) {
  .service-list { grid-template-columns: repeat(2, minmax(0, 1fr)); }
}
@media (min-width: 72rem) {
  .service-list { grid-template-columns: repeat(3, minmax(0, 1fr)); }
}

This does not solve every content issue automatically. An unclear title remains unclear and a long address may need additional treatment. The sketch shows a flexible foundation supporting the editorial sequence.

11. Test conditions rather than device brands alone

A list of familiar phone models quickly becomes incomplete. Add conditions such as narrow views, enlargement, slow resources, an open keyboard and longer text. That makes the review less dependent on one particular device.

Browser emulation is a useful technical check. A real device adds actual input and rendering conditions. Record which test occurred rather than presenting a simulation as physical-device acceptance.

12. Evaluate changes through observable tasks

Ground a mobile revision in concrete observations. “More breathing room” is not yet a testable objective. “The qualification is interpreted as part of the next offer” identifies a problem that a spatial correction can address.

Compare the same task before and after the change. When using real usage data, consider the period, other influences and the limits of attribution. More enquiries alone do not establish that the mobile arrangement caused the difference.

The usability of received enquiries matters too. More incomplete messages may not meet the business need. Evaluate the actual objective rather than relying exclusively on a superficial click count.

Record the content and states reviewed. New services, longer translations or another form can introduce new requirements. Acceptance demonstrates a checked version rather than guaranteeing every later extension.

13. Plan persistent bars and overlays carefully

A persistent contact bar can keep a frequent action accessible, but consumes a significant part of a small screen. Judge the trade-off through the actual journey. It should not make relevant information or controls unreachable.

Pay particular attention to the page end and open keyboard. An action visible normally can become covered by a fixed bar during entry. An error at the bottom of the form still needs to be reachable. Each persistent layer adds review cases.

Several simultaneous layers compete for the same space. A consent region, contact bar and promotion can together displace the actual information. Assess the necessary legal and functional interaction in the intended combination rather than only in isolated specimens.

Document when a layer appears, how it closes and where focus continues. A seemingly small addition can interrupt an otherwise understandable mobile task. Without a clear task-specific benefit, its additional complexity is difficult to justify.

14. Test a service page from arrival to feedback

The fictional repair journey begins with a direct arrival on the service page. The visitor identifies supported appliances and reads the geographic limitation, then finds the information needed for an initial assessment. Only afterwards do they open the enquiry.

An obligatory input is initially missing. The form explains the error and preserves the other entries. After correction, the message is actually processed. Feedback describes that event accurately without claiming a confirmed repair appointment where further discussion is required.

Review with a narrow viewport and enlarged text, then return to the service description. This establishes whether someone can recover their context after an interruption. Resuming a task is as relevant to real use as an uninterrupted first attempt.

A complete journey makes prioritisation assessable. The question is whether the necessary information and action become understandable at the appropriate moment, rather than whether the screen contains the smallest possible amount of material.

Add a wide viewport with limited height, as can occur when a device is rotated. A menu controlled only by width may consume more of that view than expected. Check whether the content and close action remain reachable. This supplements portrait testing and prevents the review from assuming that a larger width always means more usable space.

Include this condition in the acceptance record with the actual journey and observed result. If a fixed bar or overlay causes a problem, identify that component rather than shrinking every element on the page. A targeted correction preserves the readable content and the clear priorities already established in the ordinary view.

A mobile content-prioritisation checklist

• Main visitor tasks are specific.
• A coherent linear sequence exists.
• The offer and relevant limits are explained together.
• Viewport metadata and flexible containers are reviewed.
• Enlargement does not remove information.
• Navigation wording and states remain understandable.
• Essential targets can be activated reliably.
• Forms work with the on-screen keyboard.
• Images retain meaning and suitable resource sizes.
• Supplementary material does not displace the main task.
• Emulation and real-device testing are distinguished.
• New content repeats the same task-specific review cases.

Common mobile design questions

Should mobile pages contain less information?

The task determines what information is necessary. Substantial material can be useful when it is well organised and directly reachable.

Is one viewport width enough for review?

No. Different text lengths, enlargement and input states can expose additional problems. A useful selection covers those conditions.

Is an expandable menu always necessary?

An open navigation may be simpler for a small set of destinations. Content, available space and actual interaction determine the choice.

Sources and related guides

The linked W3C WAI explanations, MDN viewport reference and web.dev material were checked on 9 November 2026. The repair service, task model and checklist are original editorial examples.

Continue with Understandable navigation, Semantic HTML and Loading performance and user experience.