网站通过了设计审核，咨询表单却可能一封邮件也发不出去。网站在开发人员的笔记本电脑上加载很快，在客户手机上却很慢。视觉稿顺利获批，运营问题则留到上线后才出现。
网站设计与开发的实用做法，应帮助团队在访客遇到问题前发现故障。这需要清楚的内容、易用的界面、合理的技术决策，以及明确负责检查的人。
Ulement 会先了解这些环节如何相互影响。看得见的问题，只是调查的起点。
要点
- 先确定访客需要完成什么，再开始设计页面。
- 根据问题对用户和业务的影响安排优先级。
- 在项目需求中纳入无障碍体验、性能和搜索要求。
- 测试点击、提交表单或付款之后实际发生什么。
- 明确谁负责维护、账号和故障恢复。
从网站需要支持的任务开始
讨论页面布局之前，先确定访客需要通过网站完成什么。
服务型企业的访客通常需要了解服务、判断是否适合自己、查看可信的依据并提交咨询。电商顾客则需要准确的产品资料、清楚的配送条款，以及正常运作的结账流程。
先列出主要任务，再确定每项任务需要什么。
| 用户任务 | 所需信息或功能 | 完成标准 |
|---|---|---|
| 判断服务是否合适 | 服务范围、例外情况、适用对象和相关依据 | 访客能说明服务是否适合自己 |
| 询价 | 清楚的表单、有用的填写说明和正确的收件流程 | 咨询送达负责人 |
| 购买产品 | 产品资料、库存、配送和付款信息 | 订单记录与付款记录一致 |
| 查找文件 | 清楚的分类、搜索和描述性标题 | 访客找到正确版本 |
| 更新网站内容 | 合适的字段、权限和操作说明 | 编辑人员无需开发协助即可完成更新 |
这样，项目就有了具体的测试依据。
我们的网站设计服务从这些决策开始，包括内容结构、导航、用户流程，以及开发团队需要实现的功能。
按影响安排优先级
付款失败和边距不齐，不应该排在同一优先级。
评估每个问题会影响谁、阻碍了什么，以及是否存在可行的临时解决方法。
| 优先级 | 示例 | 处理方式 |
|---|---|---|
| 上线阻碍 | 结账失败、记录泄露、主要表单无法使用 | 上线前修复并重新测试 |
| 高优先级 | 导航无法访问、跳转错误、重要页面严重延迟 | 按已确认的上线要求处理 |
| 计划改进 | 次要内容难懂、编辑流程低效、筛选功能不完善 | 指定负责人和完成日期 |
| 视觉细节 | 轻微间距或装饰差异 | 先处理影响更大的问题 |
提出建议时也要记录依据。“表单坏了”说得不够具体。请说明是哪一个表单、提交了什么、出现了什么情况，以及流程在哪个环节失败。
清楚的调查结果，应让下一位处理人员能够重现问题。
页面设计获批前先规划内容
用占位文字做设计，只是把布局所依赖的决定留到以后。
服务页面可能需要说明服务范围、例外情况、证明资料、费用因素和咨询方式。如果这些要求在设计获批后才提出，团队就只能把它们硬塞进原本为其他内容设计的布局。
进入详细设计前，先确认：
- 每个页面的受众和目的。
- 页面必须回答的问题。
- 内容负责人。
- 可用的依据。
- 访客接下来要采取的行动。
- 页面与其他内容的关系。
用线框图检查内容顺序。访客应该先了解服务，再被要求提交详细需求。
Ulement 项目实例
一家马来西亚政府关联公司带着一套过时的 Liferay 门户来找我们。信息像文件库一样排列，导航没有围绕用户需求组织，日常更新内容也需要技术人员协助。
我们用 WordPress 重建门户，加入可复用模板和结构化内容字段。工作包括重新整理导航、改写英文和马来文内容、检查现有网址，以及改善安全和服务器管理。
上线后，我们检查跳转、服务器响应、性能、安全控制和咨询流程。
内容模型同时影响网站的两个方面：访客如何找到信息，以及客户如何维护网站。两者都需要认真处理。
阅读平台迁移与内容架构案例。
让导航和文案一看就懂
使用访客熟悉的标签。内部部门名称和营销活动用语，通常需要调整后才能用于导航。
每个页面都要有清楚的主标题。小标题应说明下面会讲什么。链接文字也应描述它会带访客去哪里。
“查看维护方案”比“了解更多”提供的信息多。
也要检查流程中不那么显眼的部分：
- 搜索结果应帮助用户区分不同页面。
- 空白列表要说明是没有内容，还是需要调整筛选条件。
- 表单错误应指出问题，并保留已填写的有效资料。
- 不存在的页面应返回 404 状态，并提供有用的去向。
- 暂停提供的服务应说明访客接下来可以怎么做。
这些状态也是设计的一部分。沿用软件默认提示，容易造成原本可以避免的困惑。
建立功能完整的可复用组件
设计系统应该减少访客、编辑人员和开发人员重复面对的决定。
定义共用的字体、颜色、间距、按钮、表单、导航和内容组件，并覆盖实际使用时会出现的状态：键盘焦点、错误、加载、选择和确认。
表单设计如果只展示空白字段，就还不完整。
在有助于保持一致性的地方使用设计变量，也就是代表共用样式的命名数值。修改颜色或间距时，不应该需要逐页查找和更改。
选择能够说明内容的图片。产品资料、流程图和带注释的截图，往往比装饰图片更能回答问题。
动画要有明确用途。如果动画延迟信息显示或增加操作难度，就应该移除。
不要只靠截图检查手机体验
响应式设计会根据屏幕尺寸调整布局。Mobile-first 设计则从小屏幕的限制开始规划。
单靠设计软件中的窄屏预览，无法证明这两点已经做好。
请用真实手机测试：
- 打开导航。
- 找到相关服务或产品。
- 放大文字。
- 完成表单或结账。
- 阅读确认信息。
- 在接收资料的系统中核对结果。
留意屏幕键盘打开后的情况，并检查较长的标签、验证提示、菜单和固定控件。
使用灵活布局和尺寸合适的图片。只有在内容需要时才设置断点，不要只按设备型号来选。
把无障碍要求纳入验收
在项目需求中设定无障碍目标。Web Content Accessibility Guidelines (WCAG) 2.2 AA 级提供可测试的要求，涵盖键盘操作、对比度、焦点、标签和错误协助等方面。可用W3C 快速参考找出适用的标准。
基本要求包括：
- 使用语义明确的 HTML，并按逻辑安排标题。
- 为控件提供清楚的名称和标签。
- 支持键盘操作，并让焦点状态清楚可见。
- 颜色对比度足够。
- 用文字说明错误。
- 为有信息价值的图片提供有用的替代文字。
- 为相关视频添加字幕。
- 支持减少动态效果的偏好设置。
先运行自动检查，再用键盘和屏幕阅读器进行人工测试。菜单、对话框、表单和第三方组件也要纳入测试。
记录测试过的页面、组件和用户流程。自动评分无法证明整个网站都符合无障碍要求。
在接近真实的环境中测量性能
性能包括加载速度、响应速度和视觉稳定性。
Google Core Web Vitals 的“良好”门槛如下：
| 指标 | 测量内容 | 目标 |
|---|---|---|
| Largest Contentful Paint (LCP) | 最大可见内容元素的加载时间 | 不超过 2.5 秒 |
| Interaction to Next Paint (INP) | 对用户操作的响应 | 不超过 200 毫秒 |
| Cumulative Layout Shift (CLS) | 意外的视觉移动 | 不超过 0.1 |
Google 的Web Vitals 指引建议按第 75 百分位评估三项指标，并分别查看手机和桌面体验。
Lighthouse 可在模拟环境中协助诊断问题。真实用户数据则显示不同设备、网络连接和操作下的实际表现。条件允许时，两者都要使用。
先处理造成延迟的资源：
- 调整图片尺寸并压缩。
- 不要延迟加载首屏马上需要显示的主图。
- 减少字体文件和字重。
- 移除未使用的脚本。
- 检查追踪工具、聊天工具和嵌入媒体。
- 为图片和动态内容预留空间。
- 合理设置缓存和压缩。
增加功能前，先为页面体积和脚本数量设定上限。每个第三方工具都会增加访客需要加载的内容。
把搜索要求纳入网站建设
每个重要页面都要有明确目的。页面标题、主标题、内容和内部链接，应该回应同一个需求。
服务页面需要提供足够信息，让读者能够判断是否购买。文章则应该回答标题提出的问题。
接着检查技术基础：
| 项目 | 检查内容 |
|---|---|
| 规范网址 | 首选网址指向预期页面 |
| XML sitemap | 包含重要的公开网址 |
| Robots 指令 | 抓取和索引设置符合页面用途 |
| 跳转 | 已替换的网址会转到相关页面 |
| 内部链接 | 搜索引擎可以通过链接找到重要页面 |
| JavaScript 呈现 | 搜索引擎仍能读取重要内容和链接 |
Google 搜索技术要求决定页面是否具备被索引的条件。符合这些要求并不保证一定会收录。
只有在受支持的数据类型能够准确描述页面可见内容时，才使用结构化数据。完成后要验证，但不要承诺一定会出现特殊搜索结果。Google 结构化数据政策说明了相关条件。
改网址或删除内容之前，先检查现有网站的搜索记录。我们的技术 SEO 服务会把相关影响与计划中的改动一起评估。
选择团队能够维护的技术
根据团队要完成的工作，选择内容管理系统和开发框架。
评估以下事项：
- 谁负责发布和审批内容。
- 编辑人员需要修改什么。
- 哪些系统必须连接。
- 需要哪些权限。
- 谁负责维护平台。
- 许可证和主机费用是多少。
- 组织日后如何迁移内容和数据。
如果每次更新都要找开发人员，初期较便宜的网站可能会增加长期运营成本。
采用可复用组件、版本控制、适度的代码审查和文件记录。对于系统整合，也要确定预期响应，以及其他系统无法使用时如何处理。
我们的网站开发服务涵盖这些实施决策，以及正式上线前的检查。
保护数据并测试恢复流程
使用 HTTPS、安全的身份验证、合适的权限、服务器端验证，以及符合情境的输出编码。
验证会检查提交的信息是否符合要求。输出编码则有助于避免这些信息显示时被解释为可执行代码。
OWASP 输入验证指引说明为什么服务器端也必须验证。浏览器验证可以协助用户修正错误，但可以被绕过。
保持依赖套件在支持周期内，保护机密信息，并只向账号开放所需权限。如果重复请求可能被滥用或导致系统负荷过高，应设置速率限制。
明确规定备份和恢复流程：
- 确定所需的文件、数据库和配置。
- 在不同位置保存受保护的副本。
- 指定访问权限和恢复责任人。
- 在受控环境中恢复副本。
- 检查组织依赖的功能是否正常。
备份通知只能证明备份程序运行过。恢复测试才能证明备份可以使用。
检查点击之后的结果
成功提示可能掩盖失败的交接流程。
假设表单看似提交成功，销售团队却表示没有收到咨询。请逐个检查流程环节。
| 环节 | 检查依据 |
|---|---|
| 浏览器 | 请求已发出，并收到响应 |
| 服务器 | 验证和处理已经完成 |
| 储存 | 咨询已记录在预期位置 |
| 转送 | 正确的邮箱或连接系统已收到资料 |
| 确认 | 给访客的提示准确说明处理结果 |
| 分析 | 事件记录了预期的完成阶段 |
这样可以分辨问题出在表单、邮件、系统整合还是数据测量。
表单应符合咨询需求。只询问团队会使用的资料，解释不常见的字段，并说明接下来会发生什么。
尽可能测量实际完成的行动。点击按钮和收到咨询，代表不同的流程阶段。
按检查清单上线
根据故障的影响选择测试。适合的重复检查可以自动执行，重要流程仍要人工测试。
上线前确认：
- 表单、结账、预约和账号流程。
- 键盘操作和已确认的无障碍要求。
- 导航、链接、跳转和不存在页面的处理方式。
- 索引设置、规范网址和 sitemap。
- 分析事件和隐私设置。
- 正式环境的访问权限和配置。
- 备份和恢复说明。
- 回滚步骤和上线责任分工。
先在测试环境完成测试，再对正式网站重复关键检查。主机、登录资料、邮件发送、缓存和外部连接，在正式环境中的表现可能不同。
明确谁批准上线，谁可以执行回滚。
明确上线后的责任
网站上线后仍需要有人处理内容、软件、基础设施和账号权限。
请确定由谁负责：
- 批准内容和网站更新。
- 接收警报并采取行动。
- 测试关键流程。
- 检查搜索和性能数据。
- 验证恢复流程。
- 管理域名、主机、许可证和管理员账号。
使用符合隐私要求的网站分析工具。不要把敏感信息写入录屏、事件名称、网址或报告。
根据网站的变更频率和业务重要性安排检查。重大更新之后，重新测试受影响的流程。
我们的网站维护与支援服务会列明持续工作和责任。新增功能或较大的改动，需要另行确认范围和验收方式。
常见问题
小型企业应该优先处理什么？
先做好清楚的服务信息、易用的手机导航、无障碍表单、安全的管理权限和可恢复的备份。确认公开页面可被索引，而且咨询会送达负责回复的人。
响应式设计和 Mobile-first 有什么分别？
响应式设计会根据不同屏幕尺寸调整布局。Mobile-first 则先规划小屏幕体验，再在空间较大时扩展布局。
如何检查无障碍体验、性能和 SEO？
把自动检查与人工测试结合起来。测试键盘操作和屏幕阅读器，检查性能、网站抓取情况和 Search Console，并选取有代表性的页面和完整流程进行测试。
网站制作平台或 CMS 能满足这些要求吗？
可以，前提是平台的组件、设置、主机和整合方式提供所需控制。选平台前，应检查无障碍、性能、索引、数据处理和维护要求。
多久应该检查一次网站？
条件允许时持续监测故障。更全面的检查频率，应根据网站变动情况和故障可能造成的影响来安排。重大改动后要重新测试关键流程。
现有网站需要重建吗？
先评估现有系统。调整内容、配置、设计或开发方式，可能已经可以解决问题。只有当当前架构阻碍必要改进，或令维护成本明显过高时，才考虑重建。
先确定要修复的事项
从访客打开的第一个页面开始，跟进一项重要任务，直到团队收到结果。记录故障、指定负责人，并商定每项问题关闭前需要什么依据。
如果您需要评估现有网站，欢迎与 Ulement 讨论需求。
标签： 网站设计、网站开发、无障碍体验