1. 先想清楚CRM的UI到底在解决谁的什么问题做CRM系统UI设计实战这件事我前后跟过三个不同规模的项目从十几个人的小团队到几百人销售队伍的中台系统都趟过一遍。标题里从线索到订单的全流程可视化听起来像一句产品口号但真落到像素层面它其实是在回答一个非常具体的问题一个销售在早上九点打开系统他能不能在三秒内知道今天该先打给谁、这条线索卡在哪、离成单还差哪一步。CRM系统UI设计的难点从来不在于界面好不好看而在于信息密度和认知负荷之间的平衡——你要把二三十个字段塞进一屏又不能让用户产生我在填表格的抗拒。这套内容适合谁看我大概分三类。第一类是刚接手B端产品界面设计的设计师手上有一堆业务字段但不知道怎么组织第二类是前端工程师需要把线索—商机—订单这条链路的交互落地第三类是做销售运营或者业务负责人想搞清楚一个可用的CRM界面应该长什么样好在评审会上提得出具体意见。不管你是哪一类读完至少能拿到一套可以直接抄的页面骨架、几个关键的可视化参数算法以及我踩过的那些坑。1.1 三类角色的屏幕时间决定了布局优先级我见过最常见的失败案例是设计师把CRM当成一个数据仓库来做所有字段平铺所有功能入口都摆在导航栏里结果谁用都别扭。正确的做法是先算一笔账这个系统里每天在线时间最长的是谁。通常有三类人。销售代表一天里可能打开系统十几次每次停留几十秒到两分钟动作集中在查线索、记跟进、推进阶段销售主管一天看两三次每次十几分钟动作集中在看团队漏斗、看异常、分配线索运营或财务一天一次甚至一周一次动作是导出、核对、做报表。这三类人的屏幕时间比例大概是 7:2:1但很多系统把界面资源平均分配了导致销售代表最常用的记录一次跟进要点四次才能完成。我的处理方式是把首页做成今日待办驱动而不是数据展示驱动。销售代表进来先看到的是今天需要跟进的线索列表、即将超时未跟进的红标条目、以及自己本周的成单进度条而不是一张华丽的团队业绩大屏。大屏留给主管放在二级入口。这个取舍听起来简单但它直接决定了首屏的信息架构。注意不要因为老板喜欢看大屏就把大屏放到所有人默认首页。我做过一次这样的妥协结果销售代表的日均操作步数从 6 步涨到 11 步两周后投诉量翻倍。1.2 可视化不是画图表是降低状态查询成本很多人一看到全流程可视化第一反应就是加图表漏斗图、折线图、饼图、仪表盘全上。但我实际用下来发现真正让用户觉得清晰的往往不是图表而是那些把状态直接摆在眼前的小设计。举个具体例子。一条线索处在已联系但未确认需求这个阶段传统做法是在表格里放一个下拉框显示阶段名用户得点开才知道下一步该干什么。我改进的做法是在阶段标签后面直接跟一个灰度的下一步确认预算提示鼠标悬停能看到这个阶段的停留时长和团队平均时长对比。就这么一个小改动测试里销售代表判断这条线索该不该催的时间从平均 8 秒降到了 2 秒。所以说可视化的本质是把隐藏的状态变成可见的信号。漏斗图当然有用但它是给管理者看趋势的对一线来说真正管用的是那些嵌在列表行里的进度条、超时标红、阶段小圆点。这两类可视化的服务对象完全不同不能混为一谈。1.3 我给自己定的四条设计约束在动手画任何一个页面之前我会先把这四条约束写在文档最上面后面所有设计决策都拿它们来校验。第一条单屏信息量上限。列表页默认展示不超过 8 列详情页首屏不超过 3 个信息区块。超出的字段一律折叠进更多信息或者侧边抽屉。这条约束逼着我做优先级排序而不是把所有字段堆上去。第二条核心动作三步内完成。从看到一条线索到完成一次跟进记录点击次数不超过三次。这个指标我会在原型阶段就数一遍超了就重做。第三条状态永远可见。任何一个页面用户都应该能一眼看出我现在在哪条线索的哪个阶段不需要返回列表去确认。这条催生了后面要讲的顶部流程条设计。第四条颜色只表达状态不表达装饰。整个系统的主色只用在主按钮和当前选中态红黄绿灰四色只用于业务状态标识其余地方一律用中性灰阶。这条约束是最容易被破坏的尤其是当业务方说这个页面太素了但只要破一次状态色的语义就会被稀释。2. 从线索到订单先把业务流程拆成可点击的节点UI设计如果脱离业务流程画出来的东西一定是散的。我在做这套界面之前花了整整两天时间跟着销售团队旁听电话、看他们记笔记、看他们在旧系统里怎么绕路操作。这一步不能省因为它能暴露出文档里永远不会写的真实路径。2.1 一条线索的完整生命周期一条线索从进入到成单中间会经过哪些状态不同类型的业务差别很大但通用的骨架大致是这样线索进入可能是表单、可能是导入、可能是某个渠道自动进来→ 初步触达 → 需求确认 → 转为商机 → 报价与谈判 → 赢单或输单 → 转订单履约。这里有个关键的设计判断线索和商机到底要不要分成两个对象。有些团队为了简化把商机当成线索的一个阶段有些团队坚持拆开因为两者的字段、权限、统计口径完全不同。我的经验是如果你们的销售周期超过两周、客单价超过一定量级就应该拆开。因为线索阶段关注的是有没有需求商机阶段关注的是能不能赢、什么时候赢、赢多少字段重合度其实不高。拆开之后界面上就多了一个转化动作这个动作恰好是可视化流程里最需要被强调的节点。2.2 五个核心页面的职责边界我把整个链路落成了五个核心页面每个页面的职责必须单一否则就会变成什么都能干但什么都不好用。页面主要职责关键交互常见误区线索列表批量浏览与筛选筛选、排序、批量分配塞入过多字段导致横向滚动线索详情单条线索的完整档案跟进记录、阶段推进、转化信息区块平铺无主次商机看板阶段推进的全局视图拖拽换阶段、卡片展开卡片信息过载商机详情报价与决策链管理关联联系人、上传附件与线索详情重复建设订单确认从商机到订单的落地明细核对、金额校验表单过长无分段这张表我一般会直接放进设计规范的第一页用来对齐产品和开发的预期。它最大的价值是防止详情页里再加一个列表这种惯性思维——每个页面只解决一个问题用户在哪个页面就该干哪件事。2.3 状态机设计让流转规则看得见流程可视化里最容易被忽略、但最影响体验的是状态机。什么叫状态机简单说就是哪些状态可以跳到哪些状态跳过去需要满足什么条件。这件事在代码里是一个枚举加一堆 if但在界面上它必须变成用户能看懂的东西。我的做法是在详情页顶部放一条横向流程条五个节点线索、已触达、需求确认、商机、成单。当前节点高亮已完成的节点打勾未到达的节点灰显。关键点在于不允许跳级推进。如果当前是已触达用户点商机节点是点不动的鼠标悬停会提示需先完成需求确认。这个细节看起来是在限制用户实际上是在帮他避免数据混乱——我见过太多系统允许随意改阶段最后漏斗数据全是错的因为大家为了图省事都直接拖到最后。流程条下面还要跟一行小字写清楚当前阶段已停留 5 天团队平均 3 天。这就是前面说的状态可见原则用户不需要自己去算时间差。提示流程条的节点数量控制在 5 到 7 个之间。少于 5 个颗粒度太粗看不出卡点多于 7 个用户记不住反而增加认知负担。如果业务阶段确实很多用主流程条加子阶段下拉的方式分层展示。3. 核心页面实操布局、组件与参数前面讲的是思路这一节全是能直接落地的布局和参数。我会把每个页面的栅格、间距、组件尺寸都写清楚你拿去改改就能用。3.1 线索列表页表格优先卡片兜底列表页到底用表格还是卡片这个问题我被问过无数次。结论是默认表格移动端或线索数量少的时候用卡片。原因是表格的横向对比效率远高于卡片销售在扫列表的时候本质是在做哪条更值得先跟的对比决策。表格的具体参数我是这么定的行高 56px这个高度能舒服地放下两行文字主标题加副信息又不会让一屏只能看到五六行。列宽采用弹性布局主列线索名称加公司固定最小 240px状态列固定 100px其余列按比例分配最小不低于 80px。表头固定在顶部横向滚动时左两列冻结这样用户滚到最右边看最后跟进时间时还能知道自己在看哪条线索。状态列的呈现我不用纯文字而是用色点加文字的组合绿色圆点配已成交黄色圆点配跟进中灰色圆点配待触达红色圆点配已超时。色点直径 8px和文字基线对齐。为什么用色点不用整行变色因为整行变色会破坏表格的阅读节奏眼睛在彩色块之间跳会累。还有一个细节值得说超时条目的处理。我不用红色背景而是在行首加一条 3px 宽的红色竖条同时在最后跟进时间那一列把数字标红。两个信号叠加既醒目又不刺眼。测试下来这种方式比整行标红的识别速度快 40%而且用户长时间盯着列表不容易疲劳。批量操作栏怎么放我的做法是选中任意一行后表格顶部浮现一条操作条包含批量分配批量打标签导出三个动作右侧显示已选 3 条。不选中的时候这条操作条隐藏把空间还给数据。这是典型的渐进式披露避免常驻工具栏占地方。3.2 线索详情页三段式信息架构详情页是整个系统里信息最密集的页面也是最容易做砸的。我用的结构是顶部流程条 左侧主信息 右侧辅助信息的三段式。顶部流程条高 72px包含阶段节点、当前阶段停留时长、以及一个主行动按钮。这个主按钮是动态的当前在已触达阶段时显示记录跟进在需求确认阶段时显示转化为商机。按钮只有这一个颜色用主色其余次要动作全部收进右上角的更多菜单。这是为了强制执行前面定的核心动作三步内完成约束。左侧主信息区占 65% 宽度从上到下依次是基本信息卡公司、联系人、来源、负责人、跟进记录时间线、附件与报价。右侧 35% 是辅助区关联联系人列表、标签、以及一个小的阶段停留对比条形图用来说明这条线索在当前阶段比团队平均快还是慢。跟进记录时间线是我花时间最多的地方。每条记录包含时间、操作人、类型电话、邮件、拜访、备注、内容摘要。类型用不同的小图标区分但颜色统一用中性灰只有关键节点比如首次报价、合同发送用主色标注。时间线默认只展示最近 5 条下面是查看全部链接。为什么不默认全展开因为线索跟了三个月之后时间线可能有四五十条全展开会把整个页面撑得没法看。这里有个实操心得时间线的倒序还是正序。我一开始用正序最早的在上结果用户每次都要滚到底才能看到最新动态。改成倒序之后体验好很多但会带来另一个问题——新用户不理解为什么最上面是昨天的事。解决办法是在时间线顶部加一个最新动态的小标签明确告诉用户这是倒序。这个小标签成本极低但解决了认知歧义。3.3 商机看板拖拽交互的实操细节看板是流程可视化里最直观的一块。每一列代表一个阶段卡片代表商机用户拖拽卡片就能推进阶段。看起来简单但做起来坑不少。先说列宽。我的经验是每列固定 280px列间距 16px这样在 1440px 的屏幕上刚好能放下四列多一点用户能感知到右边还有内容自然产生横向滚动的预期。如果列宽做成弹性的铺满全屏用户反而不知道还有没有更多列。卡片的信息量要严格控制。我一开始把客户名、金额、预计成交日期、负责人、标签全放上去结果卡片高得像一堵墙一屏只能看三四张。后来砍到只剩三行第一行客户名加金额金额右对齐用等宽数字第二行预计成交日期加负责人头像第三行是一到两个关键标签。卡片高度固定在 96px这样一列能放七八张全局感就出来了。拖拽交互有几个必须处理的边界情况我在实际项目里都踩过第一个是拖拽后的状态校验。用户把卡片从需求确认拖到成单系统要不要直接接受我的做法是拖过去之后弹一个轻量的确认浮层让用户补填成单金额和成交日期填完才真正落库。如果不拦数据里会凭空多出一堆金额为空的订单。第二个是拖拽的视觉反馈。拖动时原位置留一个虚线占位框被拖的卡片降低透明度并轻微放大1.02 倍目标列高亮边框。这三件事必须同时做否则用户会觉得我拖了但不知道拖到哪了。第三个是乐观更新与失败回滚。拖拽松手的瞬间界面立刻更新同时在后台发请求。如果请求失败卡片要平滑地滑回原位并弹一个提示。这里最忌讳的是等请求回来再更新界面那半秒的延迟会让用户以为操作没生效然后重复拖拽。注意看板拖拽在触屏设备上的体验很差手指滑动容易误触滚动。如果要做移动端适配建议改成点开卡片、在弹层里选择新阶段的方式而不是硬做拖拽。3.4 订单转化页把确认做成一次呼吸从商机到订单这一步是整条链路上风险最高的动作——金额、明细、折扣、付款方式任何一项错了都要走复杂的逆向流程。所以这个页面的设计目标不是快而是稳。我把页面分成三步用顶部步骤条展示第一步核对客户与联系人信息第二步核对商品明细与金额第三步确认付款与交付条款。每一步只展示相关内容用户点下一步才进入下一段。这样做的好处是单屏信息量可控用户不会因为看到一张巨长的表单而产生随便点点算了的心态。商品明细部分用可编辑表格每行包含商品名、数量、单价、折扣、小计。关键参数是数量输入框宽度 80px单价和金额右对齐小计自动计算且不可编辑折扣用百分比输入并实时显示折后金额。底部固定一个汇总条显示商品总额、折扣总额、应付金额金额用加粗等宽字体字号比正文大两号。这里有个我坚持要做的细节金额的二次校验提示。如果应付金额和商机阶段记录的预计金额偏差超过 15%页面顶部出现一条黄色提示条写当前订单金额与商机预计金额差异较大请确认。这不是拦路只是提醒。上线之后因金额填错导致的返工单量下降了一半多。第三步确认页我特意做得慢一点所有关键信息以只读形式再列一遍主按钮文案写确认并生成订单而不是简单的提交。同时在按钮下方加一行小字说明生成后可在订单列表查看并修改履约信息。这几句文案的作用是降低用户的不确定感让他知道点下去之后会发生什么。4. 全流程可视化漏斗、时间轴与仪表盘前面三节讲的都是单页面这一节讲跨页面的可视化。这部分是给管理者看的但设计不好会反噬一线所以同样要认真对待。4.1 销售漏斗的画法与转化率计算漏斗图几乎是CRM的标配但我见过太多画错的漏斗。最常见的错误是把漏斗画成数量堆叠各层宽度按数量比例缩放看起来很直观实际上会误导人——如果第一层是 10000 条线索第二层是 200 条那第二层在图上几乎看不见用户会以为这一层不存在。我的做法是每层用等高条形长度按对数比例或者固定分段同时在每层右侧标注三个数字本层数量、相对上一层的转化率、相对首层的累计转化率。这样即使数量差距悬殊每一层都清晰可读转化率的真实情况也一目了然。转化率怎么算我举个具体的例子。假设某月进入线索 1200 条完成首次触达 720 条确认需求 360 条转为商机 180 条最终成单 54 条。那么相邻转化率分别是 60%、50%、50%、30%从线索到成单的累计转化率是 4.5%。这四个数字里最有诊断价值的是转化率最低的那一环。上面这个例子里商机到成单只有 30%说明报价或谈判环节有问题而不是线索质量问题。如果反过来首次触达转化率只有 40%那就要去看线索来源渠道了。所以漏斗图不只是展示它应该带环比对比。我在每层旁边加一个小三角红色向下表示比上月差绿色向上表示比上月好鼠标悬停显示具体数值。这个设计让主管在三十秒内就能定位问题环节而不需要导出数据再做透视表。还有一点漏斗的时间口径必须写清楚。是按本月新增线索在本月的流转算还是按本月所有发生流转的线索算这两种算法结果差很多。我在漏斗图右上角固定放一个口径说明的小问号点开有详细定义。这件事看着琐碎但它是数据可信度的基础。4.2 客户时间轴的信息排布时间轴这个组件我建议每个CRM都做一个统一版本而不是每个页面各画各的。统一版本的好处是用户可以形成肌肉记忆知道时间在左、内容在右、图标代表类型、主色代表关键节点。具体的排布参数时间轴主线在左侧距离容器左边缘 24px线宽 2px颜色用浅灰。节点圆点直径 12px普通节点是空心圆关键节点是实心圆加主色。每条记录的内容区距离主线 24px第一行是标题操作类型加操作人第二行是内容摘要第三行是时间。记录之间的垂直间距 16px如果两条记录间隔超过一天中间插入一个日期分隔标签背景用极浅的灰文字写3 月 12 日。信息密度上摘要最多两行超出部分截断加省略号点击展开。这个限制很重要因为销售记的备注有时候是一大段话全展开会把时间轴撑得乱七八糟。另外一个容易被忽略的点是时间轴的筛选。客户跟了半年时间轴上有上百条记录用户想找上次报价是什么时候就得很费劲。我在时间轴上方加了一排筛选标签全部、通话、邮件、拜访、报价、合同。点击即过滤选中态用主色下划线。这个功能实现成本不高但使用频率极高。4.3 仪表盘指标卡与图表选型主管的仪表盘我一般放四类内容核心指标卡、趋势折线、漏斗、以及团队排行。指标卡放最上面一排四张分别是本月新增线索、本月成单金额、当前商机总数、平均成交周期。每张卡片的结构是指标名小字灰色、数值大字加粗等宽字体、环比变化小三角加百分比。数值字号我用 32px这是在一屏放四张卡的前提下还能保证可读性的上限。图表选型上我有几条自己的规矩。趋势看时间序列用折线图不用面积图因为面积图的填充色会让人误以为是在看累计量。阶段分布用横向条形图不用饼图因为饼图在类别超过五个之后就很难比较大小。团队排行用横向条形图加头像不用柱状图因为横向排列能放下较长的姓名。颜色方面图表里最多用三个色系主色表示本期浅灰表示上期橙色表示预警。绝对不要在同一个图表里用五种以上颜色那是给设计稿看的不是给决策看的。提示所有图表都要有无数据状态的设计。我见过太多系统在没数据的时候显示一片空白用户以为是加载失败。正确做法是显示一个灰度的空状态插画加一句本月暂无数据可切换时间范围查看。5. 设计交付与前端落地那些评审会上吵不完的细节设计稿画得再漂亮落地走样了也是白搭。这一节讲的是怎么让前端把你的想法还原出来以及怎么处理那些设计稿上体现不出来的问题。5.1 组件库与设计令牌我的建议是不要从零画组件先盘一遍现有组件库能覆盖多少。大部分企业级前端组件库已经提供了表格、表单、弹层、步骤条、时间轴这些基础件你要做的是在其上做业务封装而不是重新发明。但直接用也不行因为原生组件的默认样式往往偏通用缺少业务语义。所以我会先定义一套设计令牌也就是颜色、间距、圆角、字号的变量表然后让前端把这些令牌映射到组件库的主题配置里。这样做的好处是后面改一次主色全站同步生效不用一个个页面去调。令牌的数量要克制。我一般定 12 个颜色主色三档、中性灰六档、状态色四个、6 个间距4、8、12、16、24、32、3 个圆角2、4、8、5 个字号12、14、16、20、32。就这些够用了。令牌一多前端记不住最后还是会写死数值。业务组件我会额外封装四个状态标签、金额展示、时间轴条目、流程条。这四个在系统里复用率最高封装好了能省大量重复工作。特别是金额展示要处理千分位、货币符号、负数标红、空值显示横杠这些细节每个页面各写一遍必然会不一致。5.2 屏幕密度与响应式适配CRM是典型的重度桌面端系统但用户屏幕尺寸差异很大从 1366 到 2560 都有。我的适配策略是以 1440 为基准做三档断点。1440 及以上完整布局侧边导航展开详情页左右分栏。1280 到 1439侧边导航收成图标模式详情页右栏折叠成抽屉。1280 以下进入紧凑模式列表列数减少看板改成单列纵向滚动。这三档之外不再细分因为再细分维护成本会失控。还有一个常被忽略的点高密度屏幕下的表格行高。在 2K 屏上56px 的行高看起来会偏矮因为像素密度高了视觉上会觉得挤。我的处理是用相对单位而不是固定像素或者干脆在 2K 以上把行高提到 64px。这个细节不影响功能但直接影响长时间使用的舒适度。打印和导出也得考虑。销售经常要把订单详情打印出来给客户签字如果页面布局是响应式的打印出来很可能错位。我的做法是单独做一套打印样式隐藏导航和操作按钮把关键信息重排成 A4 宽度的两栏字号统一调大。这套样式写起来不难但一定要在开发初期就提不要等上线前才想起来。6. 常见问题与排查实录这一节全是我在项目里真实遇到的问题按出现频率排序每条都附上排查思路。6.1 状态不同步列表显示跟进中详情却是已成交这是最高频的问题本质是缓存和刷新机制没做好。用户从列表点进详情改完阶段返回列表列表还是旧数据。排查的时候先看列表是否做了本地缓存如果做了返回时有没有触发失效重取。我的解决方案是三层。第一层详情页修改成功后通过一个全局的状态管理把对应条目的数据标记为脏列表监听到脏标记就静默重取这一条。第二层列表页在窗口重新获得焦点时做一次轻量刷新只拉当前页。第三层给用户一个手动刷新的按钮虽然大部分时候用不上但它是兜底的心理安慰。现象可能原因排查步骤解决方向列表与详情数据不一致详情修改后列表缓存未失效检查是否有全局状态同步机制加脏标记与静默重取切换标签页后数据不更新页面未监听焦点事件在控制台手动触发焦点看是否重取加焦点刷新修改后短暂显示旧值再跳新值乐观更新与请求回填冲突看网络面板请求时序统一以服务端返回为准6.2 权限导致的界面混乱按钮时有时无CRM的权限粒度通常很细谁能看金额、谁能改阶段、谁能导出都不一样。问题是很多实现是没权限就隐藏按钮这会导致不同角色的界面布局完全不同培训和沟通成本极高。我的处理原则是有权限看但没权限操作的显示为禁用态并给出原因提示完全没权限看的才隐藏。比如一个销售助理没有改阶段的权限流程条照样显示但节点不可点击悬停提示该操作需要主管权限。这样界面结构稳定用户也知道自己缺什么权限而不是一脸茫然地发现我的界面怎么跟别人不一样。按钮的禁用态要做得明显透明度降到 40%鼠标指针变成禁止符号点击时不弹任何东西只有悬停时出提示。千万不要做成能点但点了报错那是最糟糕的体验。6.3 大数据量下的卡顿列表滚动像幻灯片线索量上到几万条之后列表页如果不做虚拟滚动浏览器会直接卡死。排查的时候先看 DOM 节点数量如果一次渲染了上千行那肯定是没做虚拟化。解决方案是引入虚拟滚动只渲染视口内加缓冲区的行通常 20 到 30 行就够。配套要注意两件事一是行高必须固定否则虚拟滚动算不准位置二是如果表格有合并单元格或者展开行虚拟滚动的实现会复杂很多这时候要考虑分页而不是无限滚动。看板页面的性能问题通常来自拖拽库。如果每张卡片都绑定了完整的拖拽事件监听卡片一多就会卡。解决办法是用事件委托在容器上监听一次通过坐标计算判断拖的是哪张卡。另外卡片内的图片和头像要做懒加载不要一次性全加载。还有图表。仪表盘上如果同时放了五六个图表初始化时会有明显的白屏。我的做法是图表懒加载加骨架屏进入视口才初始化初始化前显示一个灰色占位块。这个改动让首屏可交互时间从四秒多降到了一秒出头。7. 几段踩坑之后才明白的经验最后说几条不太像方法论、但确实是我用真金白银的返工换来的体会。第一条不要在设计阶段就追求字段齐全。我第一个CRM项目光是线索详情页就设计了 47 个字段觉得业务可能需要。结果上线后使用率最高的只有 9 个其余全是空着。后来我改成先上 15 个核心字段剩下的通过自定义字段功能让业务自己加反而用得更顺。字段这件事永远是少了可以加多了很难删。第二条流程条上的节点名称要用业务的话不要用系统的词。我们内部把状态叫stage_2stage_3设计稿上直接写阶段二阶段三业务方一看就懵。后来改成已联系已报价待签约沟通成本立刻降下来。命名这件事看着小但它是设计和业务之间的翻译层翻不好后面全是误解。第三条一定要做一次真实的跟访。坐在销售旁边看他用一个小时系统比开十次需求评审会有用。我就是在跟访时发现销售在打电话的时候根本没法腾出手来点鼠标全靠键盘快捷键和语音输入。这个发现直接推动我们加了一套快捷键方案后续的满意度调研里快捷键是被提到最多的好评点。第四条留一个备注的万能出口。任何结构化的字段体系都不可能覆盖所有情况总有一些信息是临时的、非标的。在每个详情页底部留一个大文本备注框不限制格式让用户想写什么写什么。这个框看起来很不设计但它是用户安全感的来源也是你后续发现新字段需求的金矿——定期翻一遍备注内容你就知道下一个版本该加什么字段了。这套东西没有终点。业务在变销售的打法在变界面的重点也会跟着变。我现在做新项目第一件事还是去旁听电话而不是打开设计工具。毕竟界面是业务的影子影子画得再漂亮也得先有光。