B端UI设计公司怎么选？重点看这8种能力而不是视觉风格

B端UI作品集很容易看起来相似：深色Dashboard、数据卡片、渐变图表、复杂表格和大屏。它们能说明设计师有视觉能力，却不能证明团队理解业务流程、角色权限、异常状态和长期迭代。很多“界面问题”其实是业务规则和数据结构没有被说清。

筛选B端UI设计公司时，应要求对方展示思考过程，并用一个真实任务验证8项能力。不要只问“做过哪个行业”，而要看它能否把陌生业务快速建模、识别高风险流程、设计高密度信息、建立可扩展组件并与开发共同验收。

01 为什么漂亮界面不足以证明B端能力

B端用户通常带着明确任务进入系统，例如审批、查找、配置、录入、分析和异常处理。界面是否成功，取决于用户能否快速理解当前状态、下一步动作、数据来源和操作后果。SAP Fiori强调角色导向、自适应、简洁和一致，其中角色导向意味着不同工作角色看到适合其任务的信息。

• 截图看不到角色权限、字段规则、错误恢复、批量操作和长时间任务。
• Mockup看不到需求变化后组件是否还能复用、开发是否能维护。
• 大屏看不到日常操作效率、键盘使用、文字缩放和真实数据长度。
• 最终稿看不到团队如何从业务混乱走到方案。

02 能力1：业务抽象与领域理解

专业团队不需要一开始就熟悉全部行业术语，但必须有方法把业务拆成对象、角色、任务、规则、状态和事件。它会区分用户说的页面需求和真正业务目标，并通过流程、对象模型或规则表验证理解。

• 要求证据：业务流程图、对象关系、规则清单、关键术语和风险假设。
• 直接追问：请用自己的话解释这个业务，指出三个最容易出错的环节。
• 红旗：只讨论配色版式；把客户PRD原样转成页面；不愿挑战矛盾需求。

03 能力2：角色、权限与信息边界

04 能力3：复杂流程、状态和异常

B端流程往往不是单向下一步，可能包含退回、撤回、转交、加签、超时、并行审批、重复提交和外部系统失败。设计师需要先画状态机和异常矩阵，再决定页面和交互。

05 能力4：数据表格、筛选和批量操作

表格是很多B端系统的核心工作区。Carbon Design System指出，数据表格可以包含排序、展开、选择、批量操作、工具栏和分页，但不应把表格当成电子表格的简单替代。设计团队需要根据任务决定列、密度、操作、筛选和详情。

• 列优先级：哪些必须首屏看到，哪些可展开或进入详情。
• 查找与筛选：关键词、快速筛选、高级筛选、已保存视图和重置。
• 批量操作：选择范围、影响提示、权限、进度、失败项和撤销。
• 长数据：截断、换行、固定列、横向滚动和详情预览。
• 可访问性：排序状态、表格名称、键盘操作、焦点和读屏信息。

06 能力5：信息密度与视觉层级

B端界面不是越空越高级，也不是越密越专业。密度应服务于任务频率、屏幕距离、数据比较和操作速度。高频用户可以接受更高密度，但扫描路径、危险操作和状态表达必须稳定。

07 能力6：设计系统与可扩展性

B端系统通常长期迭代。没有组件、Token、模式和治理规则，页面越多越难保持一致。评估供应商时，应查看组件状态、变量、命名、文档和设计开发同步，而不是只看一张组件库截图。

08 能力7：可访问性、键盘与多终端

企业软件中常有长时间使用、键盘高频操作、远程桌面、低分辨率设备和辅助技术用户。供应商应说明焦点顺序、快捷键、文字缩放、对比度和响应式策略。

• 所有主要操作能否通过键盘完成。
• 焦点是否可见，弹窗关闭后焦点是否正确恢复。
• 文字放大和窗口变窄时，内容是否重排而不是被截断。
• 表格、图表和状态是否有可被辅助技术理解的名称。
• PC、平板和移动端是否真的需要同等功能。

09 能力8：开发协作与验收

B端UI最终质量取决于实现。团队需要把组件、状态、响应式、权限、规则和数据边界交给开发，并在关键节点走查。能够理解前端组件、API、数据结构和开发限制的设计团队，更容易发现不可执行的方案。

10 一场60分钟的实战测试

与其要求候选团队免费完成完整页面，不如提供一个匿名核心流程，观察它如何提问和建模。测试可以采用付费工作坊，也可以在能力访谈中完成，不要求交付可直接使用的设计。

11 100分评分表

12 典型审批系统案例

某企业审批系统有申请人、部门负责人、财务和管理员四类角色。旧版最大问题不是视觉陈旧，而是审批状态和责任人不清、退回后修改范围不明确、批量审批缺少风险提示。候选A直接重画Dashboard；候选B先建立角色权限矩阵和状态机，再决定首页只展示待办、异常与超时。这个合成案例说明，B端改版应先重构任务和规则，再进入视觉。

13 常见红旗

• 作品集中只有大屏和Dashboard，没有流程、表单、权限和异常。
• 任何行业都使用相同信息架构和视觉模板。
• 把懂B端理解为颜色克制、卡片多和数据密度高。
• 无法说明如何与产品和开发解决规则冲突。
• 组件库只有视觉样式，没有状态、交互、可访问性和版本治理。
• 不愿使用真实数据测试，所有界面依赖整齐的占位文案。

14 常见问题

设计公司必须做过同一行业吗？

不一定。高门槛行业经验有价值，但更重要的是业务建模方法、提问能力和处理复杂规则的证据。

B端系统需要视觉创新吗？

需要，但创新应服务于任务效率、信息理解和品牌，不能牺牲一致性和学习成本。

旧系统能不能只换皮？

若结构、流程和权限合理，可以局部视觉升级；若问题来自业务和信息架构，只换皮不会解决。

如何判断设计能否开发落地？

要求展示组件映射、状态说明、真实数据、响应式规则和开发走查记录。

结语

B端设计的难点不是把后台做得更科技，而是把角色、业务规则、数据、权限和异常整理成用户能理解、开发能实现、组织能维护的系统。最能证明能力的不是一张最终截图，而是团队如何分析和减少复杂度。

正式评审应加入真实工作样本：让候选团队拆解一个核心流程，展示状态、权限、表格、错误和组件规则。能把复杂问题讲清楚的团队，通常比只展示视觉风格的团队更适合长期B端项目。