业务软件的难处，经常藏在一条记录后面。页面上看是一处物业，实际上还关联客户、合同、负责人和下一次跟进。今天兰亭妙微分享 Ridwan Soleh 关于 Deal Mate 的近期设计文章，借这个房产业务后台话题聊聊桌面端界面设计。已取得的原作配图主要展示房源卡片和移动端画面，因此文中的交易表格及合同详情是单独标注的AI应用示意，不把它们当成原作已经具备的功能。
原作主视觉中，房源图片占据了较大面积，左侧同时出现房源、请求和人员信息。这样的画面适合观察项目之间的视觉差别。但业务人员如果想找出本周需要补材料的交易，照片就不是唯一的比较依据，阶段、负责人和日期可能更重要。
原文配图：Deal Mate 主视觉以房源卡片和侧边辅助信息为主，非本文后续AI交易表格示例。
这提醒我们，在讨论卡片还是表格之前，先明确当前任务。浏览新房源、比较交易进度、确认即将到期的合同，读取信息的方式不同。可以沿用同一套基础数据，给不同工作安排合适的视图，而不是让一张很漂亮的总览承担所有问题。
评审时不妨给每张页面写一个具体问题，例如“今天先跟进哪三条记录”。如果需要靠打开很多详情才能回答，就说明当前视图缺少比较线索。此时增加一个常用字段，或允许切换为列表，可能比再加一张汇总图更直接。
一处物业可能对应多份合同，同一位客户也可能同时查看多个对象。界面如果只显示好看的名称，很容易把这些关系藏起来。详情页中的编号、对象名称、所属客户和负责人的位置，应当有相对稳定的组织方式，帮助人核对正在处理哪条记录。
原文配图：Deal Mate 的移动端组合展示，用于观察同一业务在不同屏幕中的信息安排。
这里可以用一个假设例子来讨论：客户同时咨询两处位置相近的物业，其中一处进入签署，另一处仍在沟通。工作人员从消息跳转到详情时，需要同时看见客户和具体对象，而不是只看见一个熟悉姓名。页面之间的链接应指向明确记录，返回后也应保留原先的查看范围。
响应式设计也要考虑这种关系。桌面并排展示的内容放到手机上后，信息会变成先后顺序；重要标识不能因为侧栏收起就消失。设计师可以把关键路径单独走一遍，检查使用者在较窄页面上是否仍能核对对象，而不是只检查排版有没有超出边界。
对于合并或拆分后的记录，还应说明新旧编号怎样对应。假设一份交易从两个对象调整为一个，历史附件仍然可能使用旧名称；界面可以保留可追溯关系，帮助后来查看的人理解变化。对象关系并不只影响数据表，也会影响搜索结果、通知标题和导出文件中的名称。
交易阶段的作用，不只是为列表增加几个彩色标签。使用者需要知道当前在哪里，为什么停在这里，以及接下来能做什么。阶段可以代表共同流程，但下一次跟进通常和具体记录有关，所以两类信息放在一起时，要保留清楚的区别。
AI概念示意：假设的交易队列，用于讨论阶段与下一次跟进，不是Deal Mate原作截图或已上线项目。
比如同样处于资料核对，两条记录可能分别在等待客户补文件和等待内部确认。示意图中的列表给阶段与下一动作各留一列，就是为了把共同状态与具体任务分开。真实项目是否采用这种布局，仍需根据数据量、权限及使用频率确定，不能把概念图当成通用答案。
阶段变化还可能牵涉回退、暂停或取消。设计稿可以选一条典型记录，把正常推进和一次回退放在一起讨论，记录哪些资料保留、谁能修改、历史如何呈现。当这些问题在设计阶段被看见，开发才不必从一张静态进度条猜出完整业务规则。
详情页常常比总览更能检验设计是否理解业务。一个“等待签署”标签旁边，可能还需要当前版本、负责团队和最近动作。信息不必全部默认展开，但重要变化应当能被找到，否则使用者只能再去聊天记录或邮件里拼出经过。
AI概念示意：假设的合同详情与阶段记录，展示对象、责任和变更线索，非原作已有页面。
在假设合同示例中，详情保留对象、客户、日期和附件，再用活动记录说明更新。若阶段变化来自外部系统，也应该用适当文字交代来源。它与用户主动修改是不同性质的事件，不宜都混在一个没有说明的更新时间里。
交付时可以用同一条样例记录串起队列、详情、修改和返回，并把会变化的字段单独注明。这样一来，组件尺寸、页面衔接和业务状态都有了共同参照。团队讨论的重心也能从“这块是不是太空”，慢慢转到信息是否足以支持真实操作。
另一项实用检查是权限变化。假设主管把记录转交给其他团队，原处理者再次打开时，应该知道自己还能看什么、哪些动作需要新负责人执行。不要让同一个按钮有时可用、有时消失，却没有任何解释。把角色和状态一起核对，详情页与列表页才更容易保持一致。
看业务后台案例时，值得积累的不只是密集排版，还有对象之间怎样关联、阶段怎样被理解、变化怎样被追溯。这些线索清楚了，页面的视觉层级才更容易围绕工作展开。
