我们做设计的工作方式真的合理么 ？
这段时间在做质量保障平台的支持设计，一直在想怎么可以更高效优质的完成支持设计。
前提是：专业门槛比较高的产品。
把设计工作完全外包给不熟悉业务的设计师真的对吗？
实际的工作流程：
需求方写了很复杂的需求文档（不是设计师想要的，需求方写的也很累）－反复沟通确认
设计师提供方案（需求方发现有些业务逻辑不对，需要修改）－反复修改方案但是更多的不是方案本身问题）
设计师做决策（然而设计师并不100%掌握业务，一些设计师不可预知因素只有需求方了解）－需求方在较长时间后会发现问题
需求方做决策（需求方如果只了解业务知识，很容易做出影响用户体验的选择）
我更倾向于这样的流程：
需求方带着设计思维提出需求，设计师提供具体方案 ，和设计师一起选择最合适的业务实际情况的方案，需求方做决策。
结论是：
设计师确实需要学习业务知识。
但更多的是让让设计师教给需求方设计思维。
更具体的看下工作流程：
前期 ：
接到排期计划－沟通大致需求－细化需求（增删改）－ 前期调研－明确的需求文档及细化排期－用户调研／访谈
中期：
梳理流程和信息框架－初稿－初稿沟通－ 方案细化－方案沟通－交互稿优化－交互稿沟通确认
后期
交互稿提交－反馈调整－后续跟进
在这个工作流程中，至少60%的阶段都是在与需求方或者主要用户的沟通确认中度过的，如果是线上交流，沟通成本加倍。
所以最大问题在于沟通成本
比如一个创建任务流程的需求，需求方会先直接告诉我：“我要先出现用例列表，再选择机器”
当然不能直接就这么画出来线框图
于是我需要花大量的时间去了解他们创建任务的具体用户场景，业务流程。但首先总要让他们理解用户场景是什么吧。
那么或许我们的沟通技巧有问题么？
确实，可以用更高的技巧提高效率，但远远不够。
在这个创建任务流程的需求中，如果先告诉需求方，设计一套流程的思路是怎么样，他可能就不会一开始就直接告诉我页面上要出现什么。
有些需求，设计师知道怎么问，但是涉及专业门槛很高的产品，设计师未必知道自己漏了什么没问到。
不只是提需求阶段，在方案决策阶段，如果需求方能结合设计思维和业务知识，结合设计师的方案，会尽早的发现方案问题，和设计师共同做出更合适的决策。
所以这也是我不愿意去设计公司的原因吧。
这是我目前想到的解决方案，会在这次的工作中用到，然后再去发现其他问题继续优化吧路还长。
下次可以写一篇关于怎么让需求方了解更多设计思维的思考。。。。。。不停歇的叛逆思考
