很多公司的产品除了要挖掘和实现用户需求 ，还需要协调团队资源，推动项目的进展。尤其后期在跟技术的对接上，尤其需要花很多时间。
那产品设计师如何与技术协作更高效？
1、技术需要了解业务和用户；
很多技术（或公司管理层）觉得，技术只管实现功能就好，不需要了解业务。尤其很多公司发展到一定阶段，技术离业务越来越远，甚至说不清楚自己公司是做什么的。
这样导致的问题是，技术离用户很远，不知道产品有什么问题，需要为用户解决什么问题，而了解这些，就知道自己在开发的产品用户是谁，能为用户解决什么问题，哪些问题还未解决等。同时，也能减少协作的沟通成本，产品讲场景时，技术能瞬间get。
2、让技术参与需求评审；
让技术参与需求评审，参与讨论，一方面让技术同学脑海中有场景感，知道为什么要做这个需求，是解决谁的什么问题，而不是仅仅把一堆文档给他们，告诉他们开干，这样会让技术变成纯粹的执行机器；
另外，技术能站在他们的角度提出一些思路，看需求是否可行，是否有更合理的方案。
3、给技术提供详细的文档
一般情况下，产品都会准备PRD文档，也会同步给技术。但跟很多技术同学沟通过，普遍表示他们一般不会看prd文档，内容太多，效率太低。大多数情况下，他们需要这几个文档：
1）原型稿（最好是高保真原型）；
如果前期的需求评审阶段，技术已经对需求和场景理解的很好的话，一般提供了高保真原型，他们脑海中就知道该怎么做了，这是最好的情况；
另外，原型上的标注说明需要描述清楚，比如，对不同状态的解释，出现特殊情况（如操作出错或断网时）该如何提示等；
2）业务流程图；
流程图能清晰展现出场景的顺序和结果，在做产品设计甚至活动流程等地方都用的十分广泛。尤其对于任务型需求，涉及的情况分支太多，这时候，业务流程图就非常有必要了。
大致提一下绘制流程图几个关键点：
1 参与者：这个场景中，有哪些人（角色/系统）参与？比如一个杂志主编需要审核一个作者的投稿，那么参与者就是主编和作者；
2 事件：这些人做了一件什么事？接着上方案例，1是作者向杂志投稿，2是主编看到这篇稿子后对其进行了处理；
3 顺序：这些事情的前后顺序是怎样的？哪些任务是条件？比如，肯定是先有投稿，再有审稿；有人投稿是审稿的前置条件，如果都每日投稿，也就没办法审稿了；
4 输入（上游）：这些活动开始前需要有什么数据传达或者操作，比如主编要审稿，那作者需要投稿给他，并且最好系统能提醒主编去做这件事；
4 输出（下游）：这些活动结束后，会有什么反馈传达？比如，主编审稿之后，如何让作者知道这件事儿？
6 标准化：每个流程有开始和结束，每个符号代表什么意义；
以上是产品设计师跟技术gg协作最基本的流程。对新人来说，经常会在某个环节出现一些问题，但不要着急，慢慢跟技术磨合，经历各种互相撕逼、一个又一个项目后，就能达到比较和谐的状态。
另外还有几个非常值得注意的点，都是经历汗水总结出来的经验：
1、 尽可能考虑周到
在给技术文档时，一定要把所有情况考虑到，不要等技术来找你。
比如：
1）每个流程是否有完整的开始、结束，是不是每个可点击的按钮都有交互反馈，
2）错误提示、网络环境有问题时如何处理、空状态、各类弹层是不是有考虑；
3）新老版本之间如何兼容；
4）数据埋点怎么埋，提前沟通；
2、尽可能的不要改需求
产品最常见被技术『砍死』的最大原因之一：临时改需求。
因为产品没考虑清楚，突然让技术改东西，但牵一发动全身，你以为改动小，但对技术来说可能就是半天或者几天的工作量，这种情况出现多了，不被喷死都是技术仁慈了。
所以事前想清楚，提交开发之后就不要轻易改需求了。
3、产品功能和逻辑比炫酷的视觉更重要
对产品新人来说，总是希望自己做出来的产品一看就很炫酷高逼格。但实际情况是，过分追求视觉上的炫酷不仅需要耗费太长时间，拖慢项目进度，而且会忽略产品本身的功能和逻辑，得不偿失。
与其看上去酷，不如把功能设计的更简单易用。
当然，每个产品新人都需要经历各种项目、各种磨合，才能慢慢修炼的老道。每一次犯错，都是成长。
