research-backed-frontend-development

有研究依据的前端开发

每次处理前端、UI 或 UX 任务时，都要应用此技能，即使只是小修复或寻求建议。根据变更范围调整工作量；下文的研究豁免不代表可以不使用此技能。

打造适合其主题、用户和主要任务的界面。追求经过深思熟虑的视觉风格和直观的交互。遵循需求说明、现有设计系统、技术栈和范围：设计请求不一定需要实现，评审也不代表授权修改。

设计前先调研

对于新界面、重大变更或尚未解决的设计决策：

• 在线搜索至少两个面向相似用户、解决类似问题的独立产品。加入一个视觉呈现出色的参考产品。检查相关界面或流程，而不只是产品的营销首页。
• 实际查看这两个产品的截图或渲染界面。在线网站、官方截图、附有图片的帮助文章、应用商店图库和录制的演示都可以作为依据。以清晰可读的尺寸打开图片。搜索摘要、网页文本、图片说明，以及保存后从未查看过的截图，都不算视觉检查。
• 对于交互、导航或动态效果，还要查看相关视频或亲自试用在线演示。检查操作前、操作中和操作后的状态；无法播放视频时，使用带时间戳的视频帧。仅凭文字稿无法了解动画或布局变化。静态构图工作无需查看视频。
• 至少从一个权威来源搜索并阅读相关 UX/UI 最佳实践，例如平台设计指南、成熟的设计系统、W3C 无障碍指南或可用性研究。阅读指南正文；仅有标题、搜索摘要或只返回元数据的结果都不算。将指南与实际问题相结合，例如表单、筛选、触控控件、导航、数据密度等。竞争产品的做法只是观察结果，并不能证明其可用性良好。

在提出初步方案前，先记下简短的研究笔记，其中包含来源 URL、实际查看的界面或视频时间戳、两个产品的视觉观察、指南正文中相关的建议，以及这些依据支持的决策。确认任何拟议的交互也参考了你实际查看过的视频或亲自试用过的交互。如果缺少证据或获取资料失败，请尝试其他来源或可用工具。称方案为“未经测试”不能代替这项研究。不要用记忆中的惯例或链接列表代替研究。用户要求快速回答或“只要代码”，也不免除这项准备工作。

重复使用为当前任务已收集且符合要求的研究。对于不改变设计的错别字、间距修正或其他范围有限的修复，只需检查受影响的界面。尊重用户不浏览的要求；如果尝试其他方法后仍无法获取资料，请指出缺失的证据，并根据提供的材料继续，不要声称已完成研究。不要将研究笔记放进产品 UI。

选定方向并构建

将证据转化为简要的设计方向：主要用户任务、信息层级、布局、字体、配色，以及相关交互状态。说明要借鉴或避免哪些模式，以及原因。从参考内容中汲取经验，但不要照搬其风格或素材。

根据主题选择字体、间距、图像和颜色。避免千篇一律的卡片网格、装饰性标签，以及毫无目的地添加流行效果。表现力强的设计需要精心处理细节；克制的设计则需要精准把握比例与对齐。让动效发挥实际作用，并尊重减少动态效果的偏好。

遵循现有项目规范进行实现。确保控件可用，使用恰当的语义元素，并兼顾键盘或控制器焦点、对比度、目标尺寸和响应式布局。涵盖功能可能遇到的加载、空内容、错误和恢复状态。使用真实可信的内容，并在文案中采用 natural-writing；同一份调研也可支持这两项技能。

检查结果

运行修改后的界面，体验其主要交互，并实际查看相关屏幕尺寸下的截图。根据设计概要和调研检查层级、间距、可读性、溢出、焦点和状态反馈。修复可见问题，并重新截取受影响状态的图像。运行适当的项目检查；仅检查代码不足以证明视觉质量。

对于仅涉及设计的工作，根据证据检查拟议的布局和状态，并明确区分设计方案与经过测试的行为。对于评审，只报告有依据的发现。交接说明应简明扼要：说明改动内容、重要设计选择的依据、已验证的内容，以及任何实质性限制。在操作浏览器时遵循 polite-browser-use，如需检查录制内容，则遵循 view-video（若可用）。