网站目标不是“展示品牌”，而是支持具体业务
把官网目标写成可衡量的业务结果，页面取舍才有统一标准。
新手引导要帮助完成首个任务
介绍所有功能不等于用户真正理解产品价值。
双钻模型的价值在于反复发散与收敛
流程图不是线性瀑布，而是帮助团队区分探索问题和选择方案。
技术架构应从变化频率和团队能力出发
最复杂的架构并不自动带来更高可靠性。
用用户任务而不是内部部门规划网站
访问者不会按公司组织架构寻找信息，他们只想尽快完成自己的任务。
空状态是产品开始对话的地方
空白页面会让用户误以为没有权限、数据丢失或产品故障。
问题定义要包含对象、情境和期望变化
“提升体验”过于宽泛，无法指导研究和方案取舍。
语义化 HTML 是可访问性和维护性的底座
全部使用 div 模拟控件，会失去浏览器原生行为和辅助技术支持。
信息架构上线前，先用树测试验证
导航名称看似清楚，不代表目标用户能在真实情境中找到内容。
错误信息要帮助恢复，而不只是报告失败
代码、红框和“操作失败”不能告诉用户如何继续。
利益相关者访谈用于识别假设与约束
内部观点重要，但不能直接替代用户证据。
CSS 组织应控制作用域、依赖和覆盖顺序
不断追加高优先级规则，会让小改动产生不可预测回归。
内容盘点是网站改版最容易被低估的一步
不先识别缺失、重复和过期内容，新结构只会搬运旧问题。
复杂表单应按决策顺序组织
字段按数据库结构排列，会增加理解和来回确认成本。
用户访谈要追问最近发生的真实行为
询问“你会不会使用”容易得到礼貌而不可靠的回答。
渐进增强让核心任务不依赖复杂脚本
把所有内容和导航交给 JavaScript，会放大加载和失败风险。
首页不是所有部门诉求的平均分配
首页应快速说明你是谁、解决什么问题，以及下一步去哪里。
产品导航需要稳定位置与清楚边界
频繁改变入口或混合不同层级，会增加用户重新学习成本。
情境观察能发现用户没有说出的工作
熟练用户常会省略习惯动作、绕行和环境限制。
PHP 项目也需要清楚的业务边界
路由、查询和 HTML 混在一个文件中，会增加测试和修改成本。
落地页要围绕一个搜索意图完成闭环
同一页面同时服务多个受众和目标，往往让每种需求都得不到完整回答。
搜索与筛选要支持逐步缩小范围
一次要求用户设置所有条件，会提高空结果和放弃率。
问卷适合测量分布，不适合独自发现原因
封闭选项会把研究者假设强加给受访者。
数据库索引应服务真实查询而不是越多越好
缺少索引会变慢，重复索引又会增加写入和维护成本。
行动按钮需要层级，而不是到处强调
每个按钮都使用强烈颜色，会让用户无法判断哪个动作最重要。
工作台应围绕行动优先级组织
堆叠指标只能展示过去，不能帮助用户决定下一步。
用户旅程图要连接行为、情绪与后台支撑
只画前台触点会遗漏交接、等待和组织责任。
数据库变更需要可重复、可回滚的迁移流程
手工改生产库会造成环境差异和不可追溯风险。
企业网站的信任来自可核验的证据
空泛的领先、专业和高品质很难帮助客户降低决策风险。
官网改版前，先别急着讨论视觉风格
当目标、受众与内容优先级没有共识，任何视觉方案都会陷入反复。
通知系统要控制打扰并保留上下文
所有事件都实时推送，会让真正重要的信息被淹没。
人物角色必须来自可验证的行为差异
用年龄、职业和虚构照片包装刻板印象，没有决策价值。
API 契约要稳定表达资源、错误和版本
仅记录成功示例，会让客户端在边界场景中自行猜测。
B2B 官网应为长决策链设计询盘路径
高客单业务很少因为一个表单就立即成交，网站需要支持多轮判断。
权限设计要让用户理解“为什么不能做”
只隐藏按钮或显示无权限，无法支持协作和申请流程。
用待办任务理解用户为何更换方案
用户购买的不是功能，而是在特定情境中获得进展。
登录安全不仅是密码哈希
会话固定、弱 Cookie 属性和无限尝试都可能绕过账号保护。
关键词规划应从搜索意图开始
只按搜索量选词，容易获得流量却无法承接真实需求。
渐进披露可以降低复杂度，但不能隐藏关键条件
把复杂功能全部折叠会让用户错过影响结果的重要设置。
“我们如何能够”问题要开放但不失焦
问题太宽会产生空泛创意，太窄则提前锁定方案。
CSRF 与 XSS 需要在输入和输出两端防护
只过滤特定字符无法覆盖不同 HTML、属性和脚本上下文。
页面标题和摘要要帮助用户做点击判断
标题堆叠关键词既不清楚，也难以形成稳定的搜索展示。
好的默认值能减少选择，但必须可理解
默认值若来自不透明规则，可能造成错误提交和信任问题。
创意工作坊先追求差异，再讨论可行性
过早评价会让团队停留在最熟悉的方案。
输入验证必须以服务器端规则为准
前端校验改善体验，但可以被绕过。
内部链接决定内容能否形成知识网络
孤立文章即使质量不错，也很难帮助用户继续完成判断。
删除和覆盖操作需要分级保护
所有操作都弹确认框会让用户形成机械点击习惯。
方案优先级需要透明的共同标准
只由职位最高者拍板，会让研究和技术风险失去作用。
文件上传要按不可信输入处理
只检查扩展名无法阻止伪装文件和资源消耗。
稳定清楚的 URL 是长期内容资产
频繁变化、参数混乱或语义不明的地址会增加迁移与统计成本。
等待反馈要匹配任务时长和可控性
没有状态提示会让用户重复点击，虚假进度也会损害信任。
低保真草图用于比较结构，不是展示美术
过早精修会增加沉没成本，也让反馈集中在颜色和细节。
密钥和密码不应进入代码仓库
删除提交后的密钥并不能消除历史泄露风险。
SaaS 工作台不该只是数据卡片集合
真正有用的工作台，应帮助用户判断今天先做什么，而不只是展示昨天发生了什么。
站点地图不是收录保证，而是发现线索
把所有地址塞进站点地图，不能替代可抓取的导航和高质量页面。
弱网与中断场景应纳入核心流程设计
只在稳定网络测试，会遗漏重复提交、状态不同步和内容丢失。
线框图应明确内容优先级和交互状态
只有灰色方框的页面不能支持有效评审。
日志要支持定位问题，同时保护敏感数据
记录所有请求正文可能泄露密码、令牌和个人信息。
结构化数据应表达真实页面内容
标记不存在的评分、问答或组织信息会带来误导和维护风险。
产品可访问性需要覆盖完整交互状态
静态页面通过对比度检查，不代表弹窗、拖拽和错误流程可用。
原型保真度应匹配当前要验证的问题
高保真不一定更好，可能让参与者误以为产品已完成。
监控应从用户可感知的服务目标开始
只看 CPU 和内存，无法及时发现结算失败或页面不可用。
移动优先不是把桌面版缩小
小屏环境改变了阅读节奏、输入成本和网络条件。
移动手势不能成为唯一操作方式
隐藏手势缺少可发现性，也可能与系统手势或辅助功能冲突。
可用性测试观察行为，不是收集喜好
问用户是否喜欢，无法发现他们在哪里理解错误或放弃。
备份只有经过恢复演练才可信
任务显示成功，不代表文件完整、密钥可用或恢复时间可接受。
核心网页指标应进入网站验收标准
只在开发电脑上感觉很快，无法代表真实用户设备和网络。
一致性不是所有页面长得相同
机械复制组件会忽略任务差异，随意创新又会增加学习成本。
启发式评估适合快速发现一致性问题
专家评估不能替代真实用户，但可在测试前降低明显缺陷。
缓存设计要先确定失效和一致性策略
盲目增加缓存层会产生旧数据、击穿和难以复现的问题。
网站图片需要内容价值，也需要性能预算
装饰图过多会拖慢首屏，却不一定增加理解。
界面文案应描述结果而不是系统动作
“确定”“提交”“处理”等词无法帮助用户预测下一步。
设计评审要围绕目标和证据讨论
“我喜欢”与“看起来高级”无法支持可追溯决策。
CDN 需要正确的缓存键和源站保护
忽略查询、Cookie 或区域差异，可能把个性化内容发给错误用户。
询盘表单要平衡销售信息与填写成本
字段越多并不一定带来更好的线索，可能先筛掉真正有需求的人。
功能发现要发生在用户需要的时刻
一次性导览容易被跳过，长期红点又会造成视觉噪声。
内容优先设计能提前暴露结构问题
用占位文字设计页面，会低估真实信息长度和证据关系。
图片优化应自动进入构建和上传流程
依赖人工压缩会随着内容更新迅速失效。
多语言网站需要内容治理，不只是翻译
逐字翻译无法解决地区差异、更新同步和搜索意图变化。
激活指标应代表用户获得价值
注册或登录只是系统事件，未必说明用户愿意继续使用。
无障碍设计应进入草图、组件和评审
把无障碍留给开发验收，会导致结构性问题返工。
性能优化要同时观察加载、交互和稳定性
只压缩文件大小无法解释主内容慢、交互延迟和布局跳动。
无障碍应从结构和内容开始
后期补颜色对比无法修复缺失标题、键盘路径和表单语义。
流失研究要连接行为数据与真实原因
只看最后一次登录，很难区分价值不足、流程困难和外部变化。
设计令牌连接视觉决策与代码实现
只维护颜色数值表，无法表达语义和主题变化。
HTTP 缓存头应与资源版本策略配合
长期缓存却不改文件名，会让用户持续看到旧资源。
埋点之前先写清楚要回答的问题
采集大量事件却没有决策场景，只会增加噪声与隐私负担。
客服问题应成为产品体验的持续输入
工单只被当作服务成本，会错过高频摩擦和文案缺口。
组件规范必须覆盖状态与内容边界
只有默认按钮和输入框，真实开发仍会产生大量分叉。
错误处理要区分用户反馈、日志和恢复动作
把异常详情直接显示给用户既难理解又可能泄露路径和查询。
网站上线后需要明确内容治理责任
没有负责人和审核周期，优质网站也会快速积累过期信息。
个性化需要可解释、可控制和可退出
推荐越精准不一定越受欢迎，错误假设可能缩小用户选择。
响应式设计要围绕内容重排而非设备名单
只为几个固定宽度画稿，会忽略中间尺寸和动态内容。
依赖升级需要持续、小步和可验证
长期冻结版本会积累安全风险，一次性大升级又放大回归范围。
网站迁移要同时保护流量、内容和数据
只关注新站发布，容易遗漏旧地址、统计代码和历史表单。
多角色产品要避免“一套界面塞给所有人”
角色目标不同，单纯隐藏菜单无法解决信息优先级问题。
设计交付需要说明规则、数据和例外
把静态画面交给开发，无法传递交互意图和边界条件。
持续集成应快速阻止可预见的回归
流水线过慢或结果不稳定，会让团队绕过检查。
什么时候值得建立设计系统？
设计系统不是组件数量竞赛，它解决的是多人长期协作中的一致性成本。
重定向和 404 页承担不同职责
把所有失效地址跳到首页，会让用户和搜索引擎失去上下文。
数据表格的核心是比较、定位和处理
无限增加列和操作，会让信息密度变成认知负担。
设计验收要在真实数据和设备上进行
只对照截图会忽略字体渲染、内容溢出和交互反馈。
测试组合要覆盖规则、集成和关键用户路径
只依赖端到端测试会慢且难定位，只做单元测试又会漏掉配置问题。
隐私说明要进入用户体验而不是藏在页脚
模糊说明和默认勾选会削弱信任，也增加合规风险。
结算流程要持续回答价格、进度与风险
隐藏费用和强制注册会在最后阶段放大不信任。
研究资料库要让证据可检索、可追溯
文件堆积不等于组织学习，结论很快会脱离原始情境。
安全响应头可以降低常见浏览器攻击面
缺少策略会让点击劫持、内容嗅探和脚本注入更容易扩大。
站内搜索是信息架构的补充诊断工具
搜索不能替代导航，但搜索词可以暴露用户语言与内容缺口。
隐私控制要用普通语言解释真实影响
把设置分散在法律文本和多个页面，会让选择失去意义。
工作坊需要清楚产出，而不是热闹讨论
没有输入准备和决策机制，便利贴只会留下模糊共识。
自动化无障碍测试只能覆盖一部分问题
通过扫描不代表键盘顺序、文案理解和辅助技术体验正确。
案例页要呈现决策过程而不只是成果图
只有视觉截图无法让潜在客户判断团队如何解决类似问题。
体验实验先定义假设，再选择指标
只比较按钮颜色，容易得到局部提升却损害长期任务。
设计决策记录能降低反复争论
团队成员变化后，缺少背景会让旧方案被无意重做。
故障响应需要角色、信息和复盘机制
临时群聊和个人经验会延长恢复时间并丢失关键证据。
网站建设应包含上线后的维护路线图
没有版本节奏和技术责任，改动会逐渐变成临时补丁。
路线图不能只按需求票数排序
高频呼声可能来自少数活跃用户，也可能掩盖更重要的未表达问题。
设计债务需要被识别、分级和偿还
局部例外不断累积，会让体验和组件维护同时失控。
技术文档要服务下一次修改和故障恢复
只描述安装步骤，无法解释系统边界和关键取舍。
企业网站技术选型，先看五年维护成本
框架是否流行不是唯一标准，团队能力、内容频率与部署环境更影响长期结果。