原创： Kevin改变世界的点滴 Kevin改变世界的点滴 昨天
今天在公司回到家后，看到产品朋友们在讨论一个有趣的话题：
UI定稿前，产品经理的你会陪着她吗？
我在【Kevin和他的产品朋友社群】中发起了这个话题，产品朋友与设计师都出了一些自己的看法。
我之前也没有想过这类问题会是问题。我所带的产品团队中，我与设计师的沟通常在于满足的产品功能性需求、业务需求即可。至于美、与丑的问题，我认为可以通过批注、元素沟通解决，若不能达到100分满意，70分的美即可上线优先验证产品业务模型。
反复沟通后若还不能给出满意的答案，到底是继续开发中还是选择优先上线，选择前者去验证产品的设计方案后再考虑二期如何迭代。迭代期间是来自mvp产品的落地反馈，我们就很难发现再讨论到UI的问题。类似说：“这个icon你应该给我放xx”
功能性需求与UI稿
产品经理在需求调研后，产品经理给一套产品设计方案。在经过与业务方确认方案的可行性后，就会开始准备开发与设计阶段。如下是我们输出的产品设计方案：原型
原型中后，我们常用的方式是给予PRD或在PRD同时的时候交给设计师并行设计。注意原型一定要以页面的方式进行展示，方便设计师对每个设计页面理解。拒绝用页面交互的形式表达。容易导致忘记页面与页面之间的关联理解
以上就是我在带领团队落地产品功能性需求进入到设计稿的步骤
什么是设计节点
我们在工作中都要有效的执行“节点”沟通话术，越是强调节点话术的同事你会发现往往是工作中比较优秀或在团队中担任重任的。节点的概念同样应该存在于产品研发流程中，原型页面给到设计师评估设计所需时间、第一次验收修改时间点、第二次验收修改时间点、终稿时间。
回到上面的话题：“你会陪着设计师出稿吗？”
假设你是一个产品经理陪着设计师完成第一次验收的问题、第二次验收的问题，我很难想象这样的团队会在开发中出现多少弯路。
举个常见的例子，因为页面的关联性，可能后面的设计出现问题后产品经理甚至会尝试推翻之前的设计页面。但之前的页面却是已在开发过程中，最终导致开发吐槽说：“这个产品经理是不够格？”
导致设计师做无效的工作，开发同样也面临这样的问题，最终项目不断dealy，或疯狂的开启了加班模式。
比较验证产品的好坏绝对不是一个UI“美与丑”所能决定的，反而是产品所解决的问题
以验收为节点
既然不应陪着设计做UI，那正确的流程应该是什么呢？
类似上面举例：以验收为节点，若验收中出现功能性、字段、文案遗漏或理解错误，则要求修正对应内容，准备第二次验收。
以验收为节点，把设计环节交给设计师，并且设计布局定下来后我们其实还有发挥的可能，比如让前端添加一行、增加某个字端，即可。
好啦，今天的原创就在这里，我会每周更新2篇产品案例
网友评论