Web design · Usable on every screen
Responsive web design: why the mobile experience matters
A mobile website must be more than a scaled-down desktop page. People searching for a service on the move need to read text, use the menu and complete an enquiry. Layout, spacing and interactions must therefore suit the available width.
Responsive web design describes a flexible structure for different screen sizes. What matters is not three perfect preview images, but smooth transitions and understandable tasks. This guide explains what to consider during planning, implementation and acceptance testing.
1. Plan for screen widths rather than rigid device categories
A smartphone in landscape orientation can be wider than a small browser window on a computer. Tablets are used with and without keyboards, and computer windows are arranged side by side. The layout must therefore not depend solely on the device name. It needs to respond to the space actually available.
The responsive web design basics on web.dev recommend flexible layouts and appropriate breakpoints. Choose these where the content stops working well, rather than simply reproducing common device dimensions. Navigation may need more space sooner than a straightforward text page.
Start with limited space
First plan which information is essential in a narrow view. Then arrange it logically on larger screens too. This does not mean removing important content on smartphones. Instead, deciding the order forces you to distinguish clearly between the main message, supporting details and next steps.
| View | Typical challenge | Question to check |
|---|---|---|
| Smartphone | Limited space and on-screen keyboard | Can the task still be completed? |
| Tablet | Changing orientation | Does the intermediate width work? |
| Computer | Large screens and multiple windows | Do lines remain readable? |
A wide view may use more columns, but should not create infinitely long lines of text. Limit the reading width and use empty space deliberately. Otherwise, a website may look spacious yet require unnecessarily large eye movements when reading.
3. Coordinate typography, zoom and buttons
Choose font size and line spacing so that longer texts remain readable without constant zooming. A particular pixel size alone does not guarantee this, because typefaces differ. Also check contrast, paragraph length and the spacing between headings and text. Content must remain usable when enlarged too.
The W3C explains in its Reflow criterion how content should generally remain available at a width of 320 CSS pixels without two-dimensional scrolling. Exceptions apply to content that requires a two-dimensional layout. A wide data table therefore needs different treatment from an ordinary paragraph.
Design touch targets deliberately
At level AA, the Target Size (Minimum) criterion generally specifies 24 by 24 CSS pixels or an equivalent spacing rule, with defined exceptions in each case. This minimum requirement is not an ideal design dimension for every situation. Frequently used buttons can be considerably larger.
What matters is the actual active area, not just the visible icon. Leave sufficient space between adjacent actions and label consequential steps clearly. “Send enquiry” explains more than “Next” if the action already sends a message. Different screen widths do not change this responsibility.
4. Test forms with the keyboard open
Forms on small screens need a clear sequence and labels that remain visible. A placeholder inside a field does not replace a label, because it disappears when the user types. Explain required information and show errors directly beside the affected field, together with an understandable summary if necessary.
Use input fields appropriate to the content so that, for example, a suitable on-screen keyboard can be offered for telephone numbers. Check autofill and field order. Ask only for information needed at this stage rather than transferring an extensive internal data model onto the form.
Less vertical space remains when the on-screen keyboard is open. Fixed headers, contact bars and notices may then obscure the active field or submit action. Test the complete process, including correcting an invalid entry. Successful submission must be visibly confirmed.
Also test file selection and additional security measures on the device itself. A form may look suitable yet still fail when uploading a document. Avoid unnecessary personal data during testing and coordinate test submissions with the responsible person.
5. Adapt tables, images and videos thoughtfully
Tables need a solution that preserves the relationships within them. A structured list may suit a small number of values. Extensive comparison tables may require a clearly bounded horizontal scrolling area with an obvious indication. Do not let the entire page move sideways simply because one table is too wide.
Images should stay within their container and load at an appropriate resolution. A photo for a small screen does not need the same data volume as a large display. When cropping, check that faces, products and explanatory details remain visible. Information should not appear solely in an image containing embedded text.
Videos need a suitable aspect ratio and usable controls. Plan captions and, where appropriate, other accessible alternatives according to the content. Autoplaying media can disrupt use and load data unnecessarily. A carefully chosen preview image is often a sensible starting point.
For maps, calendars and sliders, scaling the frame is not enough. Check selection, feedback and possible alternatives. If an appointment view becomes confusing on a smartphone, a list with the same booking options may work better than a heavily reduced weekly calendar.
If mobile tasks fail on your website, you can make a no - obligation enquiry about targeted improvements.
Send a non - binding enquiry6. Account for keyboard navigation and reduced motion
Responsive design also concerns people who do not navigate with a finger or mouse. All important functions must be accessible by keyboard. Visible focus indicates which element is currently active. In particular, check menus, dialogues and revealed areas for a logical sequence.
A dialogue must not leave users at a dead end. After it closes, focus should return to a sensible place. Avoid information that appears only on mouse hover. This interaction is not reliably available on touch devices.
The prefers-reduced-motion media query documented by MDN allows you to respect a system preference for reduced motion. Use it to reduce or replace non-essential animation. Important status messages must remain understandable without movement.
Also review automatically changing content and large movements during scrolling. A reduced-motion presentation is more than a slower animation. Often, an immediate change of state is the clearer alternative. The device preview in this article should also work fully without animated transitions.
7. Put loading times and mobile search results into perspective
On the move, variable connections combine with limited processing power. Reduce unnecessary data, review external embeds and avoid loading large media without a reason. A tidy interface can still be technically demanding. Examine the resources actually loaded, not just the visual impression.
In its mobile - first indexing best practices , Google explains that the mobile version is used for indexing. Essential content and information should therefore also be available on mobile. However, responsive design alone does not guarantee a particular search ranking.
Content may be placed in expandable areas for clarity, provided it remains accessible and technically available. Do not hide important information behind an interaction that only then triggers its retrieval. Also check page titles, descriptions and structured data for consistency of content between views.
Do not treat a mobile search preview as a fixed display. Search engines may assemble titles and snippets differently. Your influence lies in clear page content and consistent technical information. The preview article Good business website content explores this content foundation in more depth.
8. Use the device preview as a local guide
Navigation in a menu, stacked cards and large buttons.
Switch between smartphone, tablet and computer in the local example view. Observe how navigation, text columns and the contact area are arranged. The demo only changes the displayed example width and does not store or transmit anything. It does not inspect your own website.
The device preview explains the principle but does not replace testing on real hardware. A narrow browser view only partly reproduces the on-screen keyboard, touch input and mobile browser behaviour. Use these previews for early discussions, then test essential tasks on real devices.
Use the example view to discuss more than which version looks nicer. Ask where the most important content starts and which next action is clear. This makes the display a decision aid for structure rather than a purely decorative presentation.
9. Use a specific test list for acceptance
Checks before approval
- Check narrow and intermediate widths as well as landscape orientation.
- Open, use and close the menu.
- Enlarge text and look for horizontal overflow.
- Complete the form with the on-screen keyboard and correct errors.
- Use tables, videos and interactive elements.
- Complete all important tasks using the keyboard.
- Enable reduced motion and check the display.
- Observe loading behaviour with a restricted connection.
Test at least the main page types, not just one designed sample page. Long headings, multiple languages and extensive forms reveal weaknesses sooner than short placeholders. Record errors with the device, browser, orientation and reproducible steps. This allows targeted corrections to the implementation.
Agree which tasks must work for approval. “Mobile-optimised” is too vague as an acceptance criterion. A more meaningful example is that a specific enquiry can be completed without obscured fields. Repeat the test after major content changes or new integrations.
For existing problems, website improvements may be appropriate. If you are planning a new project, website creation describes the scope of services. Related drafts in the protected preview include Website redesign and The website project process.
Summary
- Plan flexible transitions rather than only three fixed device widths.
- Retain important content and tasks in every view.
- Test navigation, forms and media with real content.
- Account for keyboard use, zoom and reduced motion.
- Use local previews for discussions and real devices for testing.
Frequently asked questions
Is a mobile website a separate website?
With responsive websites, the same site adapts to the available width. A separate mobile address is not required. What matters is that content and functions remain reliably usable.
Is testing on a computer enough?
No. A narrow browser view mainly shows the layout. Touch input, the on-screen keyboard and mobile browser behaviour should be tested on real devices.
Must every table be displayed as a vertical list?
No. This can lose important relationships. Depending on the content, consider a list or a bounded scrolling area. The surrounding page should remain easy to read.
Can mobile content be shorter?
The presentation can be arranged more compactly. However, essential information should remain available, including for mobile-first indexing. Do not remove content simply because the screen is smaller.
Are large buttons alone enough?
No. Spacing, labels and position matter too. A large button helps little if the keyboard covers it or its effect is unclear.
Does responsive web design automatically improve Google rankings?
It provides an important foundation for mobile use, but guarantees no ranking. Content, technical accessibility and other factors remain relevant.
Sources
- Responsive web design basics | Articles | web.devGoogle · checked on 2026 - 11 - 05
- Mobile - first Indexing Best Practices | Google Search Central | Documentation | Google for Developers Google · checked on 2026 - 11 - 05
- Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI | W3CW3C · checked on 2026 - 11 - 05
- Understanding Success Criterion 1.4.10: Reflow | WAI | W3CW3C · checked on 2026 - 11 - 05
- prefers - reduced - motion CSS media feature - CSS | MDN MDN Web Docs · checked on 2026 - 11 - 05
Back to the top of the article
