系统设计与产品体验

项目背景

我从 2016 年开始参与手机 OS 与系统应用设计。职业早期的工作集中在公共模块和工具产品：状态栏、通知中心等系统基础区域，以及计算器、录音机等高频工具。这些看似边界清晰的模块，让我建立了对系统设计的基本认识——一个局部方案不仅要在单个页面中成立，还必须与系统规则、操作习惯、信息层级和工程实现共同成立。

之后，我参与的问题逐步扩展到完整系统应用和跨模块体验。页面数量和参与角色变多以后，设计工作的重点也从“把一个界面做好”，转向“让不同场景能够共享稳定的判断方式”。这要求我在视觉气质、使用效率、业务差异与系统约束之间持续寻找可执行的平衡。

本文是基于长期实践整理的公开叙事。涉及具体产品的方案、数据和内部决策均已省略，只保留我能够公开说明的方法与反思。

我关注的问题

系统一致性并不等于所有界面完全相同。不同产品服务的任务、信息密度和使用频率不同，机械复用同一种结构，反而可能削弱体验。我更关心的是：哪些规则必须共享，哪些差异应该被保留，以及差异是否有清楚的理由。

这类工作通常会出现四个相互关联的问题：

• 如何区分公共规则和业务差异，避免把统一误解为复制；
• 如何把抽象设计原则转化为页面、组件和状态中的具体选择；
• 如何让视觉表达帮助理解，而不是与操作效率竞争；
• 如何让设计、产品与研发共享同一套判断标准，减少后期反复解释。

当这些问题没有被提前说明时，团队容易在局部方案上反复争论；当问题被定义清楚后，很多界面选择会自然收敛。

工作方式

我通常先识别真正需要统一的问题，而不是一开始就整理大量规则。通过典型任务、关键状态和跨场景对比，我会判断不一致来自原则缺失、业务差异，还是历史实现。随后把问题抽象为少量体验原则，并用关键页面验证这些原则是否足够清晰。

验证成立后，团队再决定哪些内容适合进入组件，哪些需要写入规范，哪些只需形成项目共识。过程中我负责方向判断和关键质量确认，也会与产品、研发和其他设计同事共同讨论实现边界。这样形成的标准更接近真实协作，而不是设计侧单独完成的一份文档。

反思

好的系统设计不是不断增加规则，而是减少团队在相似问题上的重复判断。规则越多并不代表体系越成熟；真正有效的规则应该能解释为什么、适用于什么场景，以及何时允许例外。

我也越来越确认，视觉质量、体验效率和实现成本不能被分成三个阶段分别讨论。它们需要从问题定义开始就进入同一张桌面。设计最终不仅要在评审时成立，还要能够被实现、被使用，并被团队长期维护。