GOV.UK任务列表为何要求可选顺序，而不只是服务步骤很多

一项网站服务很长，就应该把所有步骤放进任务列表吗？GOV.UK Design System的Task list说明没有只用长度作判断。它要求有证据表明，用户不想或不能一次完成全部任务，并且需要能够选择完成顺序。两项条件共同说明了组件准备服务的情境。

因此，任务多并不自动符合这个用途。原页先提出，使用任务列表前可以考虑简化服务；随后明确，不要把该组件用于必须按特定顺序完成的长服务。如果工作需要分多次继续，保留进度属于另一项可讨论的安排，不能因为要跨会话，就直接把固定先后的步骤解释成任意顺序。本文只解读文档条件，没有改变真实服务。

组件中的每项任务有名称与状态，也可以有提示文字。名称让用户合理预期将要处理什么；状态则帮助说明能否开始，以及哪些还没有完成。原文说，完成任务后回到列表，相应状态会变为Completed；只有全部任务显示Completed，才从列表继续前进。这里描述的是该交互中的任务进度，并没有把它等同于申请获批或其他业务结论。

任务入口的范围又有具体设计。页面说明，整行都链接到任务，而不只是旁边的状态文字。它的研究说明解释了一项背景：一些用户过去试着点击状态，以为那是按钮或链接。因此，新组件让整行成为入口，同时让状态看起来较不像按钮。入口承担进入任务的作用，状态负责传达进度，两者不宜只凭相邻位置混称。

不过，设计理由与新组件的验证结果仍是两层证据。Known issues and gaps一节明说，还需要对新组件开展用户测试，特别要检验整行可点击的益处是否超过误点风险、状态对比是否足够，以及建议措辞是否最有意义。本文据此保留这些仍待检验的假设，不将设计系统的一段解释改写成本篇已经证明所有问题都解决。

任务列表也不用于展示用户已经给出的答案，原页为此指向Summary list。前者组织还要做什么和完成状态，后者可以呈现已有信息。这个辅助区别不要求两者在视觉上一定相差很大，而是让读者知道组件中每一项究竟指向待办动作还是现有答案。本文没有运行示例或采用HTML配置。

对网站资料交接，任务列表最值得说明的不是一共有多少行，而是为何需要分次、顺序是否可选，以及状态和入口怎样配合。来源没有明确首次发布日期，版本变更记录也不替代首发。本文限于这份GOV.UK组件指南，不判断真实业务或法律许可，也不将它当成完整无障碍与用户体验验收。