Mobile-first development starts by making the essential reader task work in a narrow layout, then adding space where the content needs it. Prioritise the task, preserve its useful information and inspect the points where the layout changes. Judge the result by whether someone can complete the intended action across the chosen devices and interaction methods.
Which task deserves the first screen?
Start with a task sentence: “A visitor needs to identify the appropriate service and send enough information for a useful response.” Replace it with the actual purpose of your page. List the information needed to make that decision before deciding what belongs above or below any particular screen boundary.
For a hypothetical service page, use a synthetic enquiry about a training website. The proposed exercise is to read its scope, find the next step and submit a test enquiry. Keep the important explanation and action connected as the viewport changes; record actual results when the exercise is performed.
MDN describes responsive design as an approach rather than a separate technology. The MDN responsive-design guide therefore supports a discussion about how the page behaves, rather than treating “mobile-first” as the name of a required product.
Ask the content owner to rank the task information. Which detail helps the visitor choose, which detail answers a later question and which detail belongs elsewhere? Keep that decision visible in the brief so a narrow mock-up does not become an accidental edit of the service itself.
How should the layout adapt?
MDN explains that media queries apply CSS selectively according to conditions such as viewport width. MDN calls the points where media queries introduce layout changes breakpoints. Begin the assessment with a readable narrow arrangement and expand it until the content needs a different structure. Record the reason for each change, such as a heading becoming too wide or related controls becoming separated.
The web.dev guide recommends choosing breakpoints from content rather than device brands. The web.dev responsive guide gives that content-led approach a practical basis. Ask the developer to show the layout between its chosen breakpoints as well as at the presentation sizes in the design file.
Use the enquiry action as a continuous thread through the assessment. At each width, inspect its label, surrounding explanation and relationship to the rest of the page. Keep the information order understandable when a multi-column section becomes one column.
Write down the longest realistic heading and the most demanding representative form label. Use them in the proposed evaluation rather than relying entirely on short sample copy. If content changes later, the team should know which assumptions the layout was built around.
What should happen to images and text?
MDN warns that scaling down one large image can waste bandwidth on smaller devices. Ask which image sources the implementation offers at the intended display sizes and inspect what the browser actually requests during the evaluation. Record the source selected and its displayed role rather than judging only whether the picture appears smaller.
The web.dev guide recommends image width and height attributes so the browser can reserve space before loading. Include image loading in the layout exercise: inspect the text and action before and after the image appears. If the design moves unexpectedly, keep the observation and the relevant image dimensions for the developer to investigate.
MDN advises against setting text size with viewport units alone. For the text assessment, increase the browser’s text or page zoom using the chosen testing method and inspect the same task again. Record whether labels remain understandable and whether the visitor can still reach the action. Font size in the design file is only one input to that exercise.
The web.dev guide cautions against hiding content solely because it does not fit a small screen. When the content owner proposes removing a section on phones, ask which reader question it answers. Prefer a deliberate content decision over losing an important qualification merely to shorten a screenshot. The small-screen reader still needs a coherent basis for acting.
Which device assumptions should be challenged?
The web.dev guide uses width=device-width to match the viewport to the screen width in device-independent pixels. Have the developer identify the actual viewport configuration and explain its relationship to the CSS layout. Keep the implementation evidence with the assessment so an apparently zoomed-out page can be investigated from its settings.
Choose a practical device and browser set based on the intended audience and the organisation’s support scope. Include the interaction methods that matter for the task, such as touch and keyboard. Make the chosen scope explicit so later reviewers know which conditions were actually examined.
Test the proposed enquiry with the on-screen keyboard present on an intended phone. Inspect whether the current field, its explanation and the next action remain reachable. Repeat with a validation error and ask the observer to locate the information needed to correct it.
Include rotation or a resized window where relevant. Record whether task information remains available and whether the input already entered is preserved in the assessed implementation. Keep the observed behaviour separate from the preferred outcome in the requirements brief.
What should a mobile-first acceptance record contain?
Use this original task-continuity matrix to organise a review. It connects layout decisions to what the reader is trying to do, rather than collecting disconnected screenshots of attractive sections.
| Assessment point | Evidence to retain | Reader question |
|---|---|---|
| Narrow layout | Scope, information order and next action | Can I understand what to do here? |
| Between breakpoints | Viewport and observed layout change | Do related details stay together? |
| Image loading | Selected source and before/after observation | Does the action remain where I can find it? |
| Increased text | Chosen zoom condition and task result | Can I still read and operate the page? |
| Form entry | Keyboard state and validation example | Can I complete and correct the enquiry? |
| Wider layout | Content order and action placement | Is the same task still coherent? |
Chrome DevTools Device Mode can display media-query breakpoints, according to web.dev. Use that feature to investigate a layout transition, then assess the task on the agreed physical devices as well. Keep the viewport, browser, page revision and observation with each issue so the developer can work from a reproducible condition.
Ask a reviewer who did not arrange the content to perform the enquiry task. Let them describe where they expected to find the next step and record any hesitation. Resolve the specific content or layout issue, then repeat the affected part of the exercise.
Finish with a short decision record: the supported assessment scope, the issues resolved and the remaining owner for each open question. For the wider project, see web development or send Spout your requirements with the task and the device conditions that currently cause difficulty.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.