更新时间：2026年10月09日

B 端 UI 作品集要让读者看见业务问题怎样变成界面决策。选一个能讲完整的流程，交代角色与权限，展示关键分支和方案取舍，再用真实材料说明验证结果及个人职责；不要只放仪表盘大图。可沿用UI 作品集的项目表达结构，把一个 B 端案例讲透，而不是把所有工作截图塞进去。

案例范围越具体，越容易证明设计能力

“优化采购平台体验”太宽，难以看出你到底解决了什么。可以收窄为“申请人提交采购单，审批人处理异常明细，采购员接手已通过订单”。这样角色、输入、动作与交付边界都能落到页面上。

若采用练习项目，开头标明项目性质，后面仍可认真展示业务假设、设计过程和待验证问题；不要给它编造真实客户、上线收益或访谈记录。真实项目则写清团队规模中的个人职责，例如负责订单详情与审批反馈，流程规则由产品经理和业务方共同确认。

第一页最好让读者迅速知道：谁遇到什么问题、你负责哪一段、交付了什么。长篇公司背景和工具清单可以压缩，给后面的决策留空间。

先交代角色，不要让一张大流程图承担所有解释

案例中的采购申请人需要填写并跟进申请；审批人需要判断是否通过；采购员需要处理已批准采购。三种角色看到的信息和可执行动作不同，这比使用了哪种渐变色更能说明 B 端工作的复杂性。

正文先用短流程说明主线，再把驳回、撤回、过期等关键分支接入相应节点。不要把所有错误状态画成一张密集蜘蛛网；只展开真正改变设计方案的分支，让读者看出为什么需要那张页面。

以审批详情为例，最初方案 A 把明细、附件和审批记录分别放进三个页签；方案 B 在主体显示采购明细，右侧保留审批摘要与决定区，附件按行关联。两者不是“旧版难看、新版好看”，而是承担不同的信息查看成本。

如果审批人必须反复对照附件与某一行采购项目，方案 A 会增加来回切换；方案 B 让对应关系更近，但会占用横向空间。作品集应展示你如何根据实际内容量、屏幕条件和角色任务选择，而不是用绿色勾号宣布某方案全面胜出。

可以保留一张被放弃方案，并标注促成决策的材料：一次业务讨论中的具体问题、实际字段长度、已有工单反馈或经过记录的任务观察。没有这些材料时，就写为设计推演与待验证假设，不把团队讨论包装成用户研究结论。

B 端设计常在信息密度与可操作性之间取舍。采购明细表不需要展示所有列，但应解释哪些列直接支持审批、哪些信息移入详情、长名称如何显示、横向空间不足时保留什么。用一行真实长度的内容说明，比一整页“简洁高效”的宣言更有说服力。

选择两三处与你贡献最相关的细节放大说明，不必把几十个状态缩成看不清的缩略图。把状态画板放进同一 Pixso 文件，保持页码、组件和说明的对应关系，读者才能从结论回到具体设计。

有上线数据时，写清指标定义、时间范围、样本与同期变化。例如“完成审批所需时间”需要说明从哪里开始、到哪里结束，不能把后台处理耗时与人的操作时间混算。仅凭上线前后两张数字，不足以把全部变化归因于你的界面调整。

没有可披露数据，就展示其他真实证据：交付覆盖了哪些原本缺失的状态；研发如何依据设计说明实现；实际观察暴露了什么问题并如何调整；哪些假设仍未验证。这些材料证明工作完成到哪一步，不替代业务增长结论。

把“方案”“已经验证的发现”“仍待验证的问题”分开。练习项目也可以有清晰的推理和下一步计划，不需要借用别家案例的增长数字才能成立。

先确认项目材料的对外展示授权。需要脱敏时，同时检查客户名、联系人、单号、价格、内部链接、账号头像和评论。只盖住公司 Logo，仍可能通过订单内容识别客户。

可以把业务名称与数据改为一致的替代内容，但要保持计算关系、文本长度和状态约束。例如修改数量及单价后，合计与审批阈值也必须对应调整；若删去某个条件会改变设计原因，就用概括说明保留因果关系，而不是留下矛盾画面。

快速阅读路径是：问题与职责—关键流程—主要取舍—结果与边界；深入阅读路径再进入角色权限、异常状态与细节说明。正文与图注彼此补充，不在每张图下重复标题。

准备一版投递材料与一版面试讲解。投递材料无需口头解释就能读懂；面试版可以保留更多推演过程，回答为什么没选另一个方案。需要整理在线文件和导出材料时，可继续查看作品集文件制作与分享方法。最终让人记住的应是你如何处理业务限制，而不仅是做过多少张页面。