1. 在选布局前先明确页面的任务
从承载客户或业务任务的页面开始：服务页、产品页、潜在客户表单、预订、账号登录、购物车和帮助页面。为每个页面写一个完成陈述，例如：“首次访问者能理解该服务、看到相关证明并请求回访。”如果页面有多个任务，要决定哪个先出现。
将内容列为必要（essential）、支持或可选。必要并不等于简短；访客可能需要价格背景、资格、配送细节或比较信息。为这些材料在窄布局上提供一条清晰路径。Google 建议移动和桌面的主要内容应等效，同时允许不同的呈现方式，例如选项卡或折叠面板。
在窄宽度下，同事应该能说出页面提供什么、帮助谁，以及下一个有意义的操作是什么。
2. 让窄屏基线完整
从一个可用的单列路径开始，而不是压缩桌面布局。使用弹性容器，让文本换行，并包含使浏览器按设备宽度缩放布局的视口设置。不要阻止缩放。检查菜单、通知、图片、嵌入内容和表单错误是否都保持在视口内；意外的整页横向滚动通常是缺陷。
以 320 CSS 像素作为普通阅读和任务内容的严格重排检查。WCAG 2.2 描述了在该宽度下以垂直方式呈现内容而不丢失信息或功能或发生二维滚动的要求。地图、图表或数据表可以有自己的滚动区域，但这并不构成让周围页面横向滚动的理由。
使图片适应其容器并提供尺寸，以便浏览器能在加载前保留空间。
3. 在不使基线路径脆弱的前提下添加增强
渐进增强（Progressive enhancement）意味着必要的内容和功能作为基线可用，而较有能力的浏览器与更大屏幕会获得额外功能。地址、产品详情、表单标签、价格说明和提交路径不应依赖动画、hover 或延迟加载的脚本。更宽的布局可以添加比较面板、常驻导航或更丰富的筛选，而不应使基线变得不完整。
让实施者在内容变得拥挤或浪费时添加断点（breakpoint），而不是因为清单中出现了某个设备名称。断点仅是布局规则变化的点。不要用窄布局默默删除帮助文本、政策条款、评价、元数据或重要结构化细节。
先展示基本的画廊图片和描述，然后在脚本可用时再添加放大或滑动控件。
4. 为触控、清晰与可恢复性设计控件
触控人体工程学意味着针对手而非精确的鼠标指针来设计。为按钮、复选框、关闭图标、数量选择器和表单选项提供足够的大小和间隔以减少误触。在图标意义不明显时加标签。不要仅用 hover 来显示价格、子菜单、说明或操作。
WCAG 2.2 包含一个针对指针目标的 AA 级大小准则：至少 24 × 24 CSS 像素，并列出了包括间距与行内链接在内的例外。将其视为最低参考，而不是舒适保证。关键操作应有清晰标签、宽松间距和可逆的确认步骤。对高风险流程或正式合规声明请寻求合格的无障碍审查。
保持标签可见，显示可用的验证反馈，并在出错后保留已输入的值。
5. 将媒体与嵌入视为访客旅程的一部分
决定每张图片是信息性、说服性还是装饰性。信息性图片需要适当的文本替代和能在窄布局上保留必要细节的裁剪。响应式图片选项允许浏览器选择合适的资源，而不是让每位访客下载最大的桌面资源。不要让首屏大图或视频遮蔽页面目的和主要动作。
列出地图、聊天、视频、支付、日程、同意和评分小组件。在窄屏上检查它们的加载状态、控件大小、边界布局以及可行的回退路线。对于支付、身份或受监管的数据流程，需让合格的安全、隐私和合规审查人员参与；视觉测试并不是安全评估。
记录每个外部组件、其所有者、业务功能以及在其缓慢或故障时的批准回退方案。
6. 在发布前测试任务路径并计划修复
尽早使用浏览器响应模式检查窄、中、宽宽度。Chrome Device Mode 可以近似视口、触控、方向、网络和 CPU 条件，但 Chrome 将其描述为近似而非真实设备执行。能做到时在真实手机和相关浏览器上完成关键路径测试。
测试一个任务，而不仅是截屏：冷启动加载、导航、无效和有效表单提交、方向改变、缩放以及从第三方屏返回。记录 URL、浏览器或设备、任务、预期结果、负责人和回滚决策。对于重大模板、结账、CMS 或依赖项更改，应分阶段发布并准备恢复到先前路径，而不是在压力下即兴处理。
仅在关键任务可用、控件可用、页面级横向滚动不存在且关键依赖项有回退时批准发布。