产品经理与UI设计师分工：原型、需求和评审谁负责

更新时间： 2026年09月12日

产品经理与UI设计师的分工，不是一个负责想功能、一个负责美化。产品经理通常牵头目标、范围和业务规则，设计师通常牵头交互体验、视觉表达与组件；用户研究、原型和评审存在交叉，需要按项目约定负责人。

正在协作改版的团队，可以在墨刀原型里先建一条共同评审的流程，把业务规则和页面评论放在对应位置。需要精细视觉稿和组件规范时，再由设计师使用墨刀设计推进，避免两边各维护一份不同的“最终方案”。

同样是画原型，两个人要解决的问题不同

以会员订阅改版为例，产品经理要确认用户为什么升级、套餐提供哪些权益、老用户如何续费；设计师要让用户看懂套餐差别，找到合适入口，并理解付款与生效状态。这些问题互相影响，不适合等需求全部写完后才交给设计师。

产品经理画的原型可以重点表达页面关系和规则，例如从权益页进入套餐页、选择后进入订单确认。设计师接手后不应只是替换颜色，而要检查比较方式是否清楚、费用表达是否容易误解、状态转换是否顺畅。若发现当前套餐划分无法解释，应回到需求讨论，而不是强行用排版解决。

产品经理的工作首先是厘清问题：这次订阅改版是让权益更易理解，还是补齐团队采购流程？若两者都要做，需要确定首版范围与先后。用户反馈、业务约束和研发成本应共同影响取舍，不能把个人偏好的功能清单当成已经成立的需求。

随后整理关键规则。套餐按月还是按年、什么时候生效、已有权益如何处理、价格在哪里维护，都需要明确来源与负责人。涉及收费、退订和协议的内容应由相应业务及法务负责人确认；设计师可以发现表达问题，但不应被要求代替这些岗位决定政策。

产品经理还应维护需求变化：记录改了什么、为什么改、影响哪些用户和页面，协调研发排期与上线范围。更完整的岗位说明可查看产品经理的职责；项目中则应把抽象职责落实到具体决定与交付物。

设计师会把业务要求变成用户能理解的界面结构。在订阅页上，最重要的未必是做出更强的促销氛围，而是让用户区分套餐适用对象、权益差异、计费周期与当前选择。信息层级不清时，增加按钮尺寸也未必能解决犹豫。

设计职责还包括交互状态、布局、文案表达与组件一致性。选择套餐、提交订单、支付处理中、支付失败和权益生效，应有可区分的反馈。视觉规范要说明主次按钮、文本层级和状态颜色如何使用，而不是只交出一张正常状态的页面。

用户研究通常也是协作任务。产品经理更关注问题与价值，设计师可以参与访谈、观察用户操作并分析理解障碍，两者并非固定分成“业务研究”和“视觉研究”。Nielsen Norman Group的产品与UX协作资料也将两类角色视为需要相互配合的伙伴，而非顺次交件的上下游。

下面是一种小团队的分配示例，不是统一岗位标准。每项工作设一个牵头人负责收敛结论，其他角色仍能提出意见；真正需要业务、法务或技术负责人批准的事项，另行明确批准人，避免把“牵头”误解为独自决定。

团队没有专职交互设计师时，可以由UI设计师或产品经理兼任，但要把结果讲清：交付的是流程草图、交互原型还是视觉稿，哪些状态还没画。分工最怕的不是一个人兼多岗，而是每个人都以为另一个人已经处理了异常流程。

产品经理把套餐选择到权益生效的页面串起来，标出已确认规则和待确认问题。设计师在同一评审范围内调整信息与交互，需要重构时说明影响，不另起一套未经同步的流程。需要AI起稿可以用墨刀AI先表达页面，但AI生成的权益、价格和承诺必须替换为项目确认内容。

“这里再高级一点”无法直接处理；“年付金额下方缺少计费周期，用户可能误以为是月费”则能落到对象、原因和动作。通过页面评论集中讨论，记录谁处理以及怎样关闭问题；涉及业务决定的结论还应同步需求记录，不能只藏在一条已解决评论里。

设计师将套餐卡片、权益条目和状态提示整理成可复用组件。颜色、间距或主题需要统一维护时，可进一步了解设计变量的用法。改动组件前确认影响范围，避免为了订阅页的特殊样式改变其他页面。评审材料写清需求版本与原型版本，研发接手时就能知道哪些页面属于本次范围。

如果上线前新增“企业统一购买后分配成员”，这不是多一个按钮：它会影响购买角色、席位分配、成员接受与权益生效。产品经理先确认是否纳入本期，设计师列出新增页面和体验影响，研发评估权限及数据关系，再决定修改范围或拆分版本。

最终交接时，核对套餐选择、处理中、失败重试和生效后的入口，让每种状态都有负责人。只在这一条流程上把职责与材料对应清楚，就比一份覆盖所有岗位却无人维护的分工图更实用。