111 lines
12 KiB
Markdown
111 lines
12 KiB
Markdown
# 24 | 如何搭建发挥产品设计价值的流程架构？
|
||
|
||
你好，我是相辉。
|
||
|
||
到这里，我们就基本上说完了产品体验设计的基本方法，现在你知道了如何洞察用户场景需求、打造沉浸体验、提炼服务的生活主张，也了解了互联网产品的交互设计和界面设计的基本流程和判别标准。
|
||
|
||
那么和场景服务设计模块一样，我们还是要再谈一下互联网产品的组织体系搭建方法和发展趋势。因为一个良好的团队组织，是设计一个产品好体验的关键。
|
||
|
||
随着互联网产品的更迭和发展，人们总是在不断地迭代产品和服务，却忘记要迭代组织。就像我在[第5讲](https://time.geekbang.org/column/article/284484)中所说的，我们现在很多的团队，还仍然在用十五六年前的流程来生产互联网产品。现在的产品早已日新月异，如果我们还不改进体验设计的流程组织和架构，如何能设计出适应时代的产品，以及令人心动的用户体验呢？
|
||
|
||
所以今天，我就带你一起探索可以发挥产品设计价值的流程架构的搭建方法，我们一起讨论清楚产品、设计、运营、品牌的组织生产流程，并给你几个互联网产品体验设计的组织建设的建议，以此让你能够迭代自己的互联网产品体验的团队架构。
|
||
|
||
## 第一，要产品体验设计一体化
|
||
|
||
所谓的体验设计一体化，就是**在职能认知上，我们要逐渐地将产品经理、交互设计师、视觉设计师尽量地整合在一起**。因为一旦这几个职能在工作上有所分裂，你就会发现，产品的产出结果往往和最开始的策划相差甚远。
|
||
|
||
我举个例子。最早百度在2007年的时候，采用的是大PM的产品生产设计方式。也就是由一个产品经理来管理整个产品的整个链条，从需求的撰写到页面的设计，再到研发和测试，以及市场的营销推广，都由一个PM来整体抓。
|
||
|
||
当时可以采用这样的运作模式实际上取决于三个关键：一是因为早期的产品场景和功能足够简单，二是各个职能的专业性还没有那么深，三是百度早期的产品团队也是真的很强。这就造成了一个有超级话语权的产品团队，很强势，大家也都配合产品团队的工作。
|
||
|
||
所以在这个模式下，面对相对简单的场景搜索相关的产品，不但设计效率高，而且最终的产出跟产品经理所要的效果是非常一致的，而且也是逻辑自洽的。
|
||
|
||
但是后来，因为移动互联网时代的到来和产品场景与功能越来越复杂的情况，一个大产品经理对于体验的管理就变得非常难了。
|
||
|
||
虽然这时候，移动互联网也发展了几年时间，但它依然算是比较新的东西，而且因为比最初的版本更加复杂了一些，大家都在学习。于是在2010年的时候，就出现了移动互联网的交互、用户研究、图形设计、营销设计等等部门的设置分工。
|
||
|
||
不过这么做也有优缺点：**这样的分工虽然让产品的每个职能都变得更专业，但也导致了产品的割裂。**
|
||
|
||
我经常就碰到，有的产品经理设想了一个功能体验，交付给了交互和视觉设计师完成后，就变成了另外的样子。而交互和视觉因为太专注于图形的表达和体验的顺滑，有时候甚至忘了产品的商业目标。另外，运营也会经常和产品无效PK，比如说运营为了增长而大幅度地增加广告位置，让产品体验受到了很大的破坏。
|
||
|
||
**所以说，我们要看到问题的一体两面，当一个产品的职能为了更具专业性，过于分化，反而不利于产品整体的交付。**
|
||
|
||
令人比较欣慰的是，如今在一些互联网公司，已经开始有所调整了。这是因为移动互联网发展到今天，很多与产品界面和体验相关的工作已经被工具化和控件化了，所以有越来越多的公司开始去**整合和调配产品 - 交互 - 视觉这三者的关系**了。
|
||
|
||
比如，2010年小米在研发产品的时候，就要求产品和交互要由产品经理来管理和维系运作流程，即产品经理要设想好最终交付的样子，直接给图形设计师，而不仅仅是写功能列表。
|
||
|
||
再比如滴滴，他们最近开始把交互和视觉合并为了一个职位，目的是让前端体验的交付一体化，促使每个交互设计师在开始做交互设计的时候，就要利用视觉表达的方式来进行图形界面的通盘考虑。
|
||
|
||
也有的一些公司，则会做产品和运营一体化的考虑，要求产品的职位更加偏向商业，把所有用户端的交付，全部都给到交互设计师，而交互设计师也会演化为体验产品经理。
|
||
|
||
这些都是目前我见到的企业所努力作出的改变，他们都有一个共性，即重新分配产品体验设计的工作职能，合并同类项，简化组织。
|
||
|
||
我想，这是目前所有的企业在产品设计流程上，都应该做的事情。
|
||
|
||
## 第二，要体验设计团队数据平权
|
||
|
||
相对来说，体验设计的发展最初是从人的主观感受出发，而到了今天，逐渐发展成了用数字来量化体验。
|
||
|
||
所以这就意味着，我们仍然有大量的产品体验设计师对数据工具是陌生的，这就大大妨碍了设计师发展出自己的决策能力。而且这也意味着，整个企业在产品体验表达端，缺乏数据能力的支持。
|
||
|
||
而那些善于使用数据的团队，因为能够不断地用数字能力证明自己产品或商业的设计策略，所以在企业内部也可以持续地获得话语权。
|
||
|
||
于是，这就意味着，类似于运营、产品经理这样的团队会拥有更强的话语权。久而久之，就会陷入一个强者更强、弱者更弱的状态。团队话语权的不平衡，久而久之还会伤及企业的发展，因为这等于是让企业某一大块的数据视角缺失了。
|
||
|
||
我经常看到那些交易数据很好的团队，明明已经出现巨大的体验问题而不自知，最后摔了大跟头。我也经常见到一个好的设计，在没有数据证明的情况下，被无情地拿掉。
|
||
|
||
所以，我一般到了一个设计团队，就会开始要求一件事，就是**数据平权**。即在**不影响数据机密的情况下，产品、设计、运营、品牌应该共同享有一份数据资料，大家依据一个数据现实去做基于自己职能角度的判断**。如果大家对数据的理解不统一、不一致，甚至连数据的知情权都是不同的，那么实在谈不上可以进行高效的沟通。
|
||
|
||
那么，数据平权应该包含哪些内容呢？我认为主要有四点：
|
||
|
||
* **知情权**：也就是团队中产品和业务的数据是大家可以共同使用的。
|
||
* **统一性**：也就是大家都可以在某一个地方找到统一迭代更新的数据，而且没有时间差。
|
||
* **理解能力**：也就是大家都拥有基础的数据素养，而不是拿到数据却不会用。
|
||
* **资源权**：也就是每个团队都有给研发团队提数据提取和研发需求的权利，并有资源支撑。
|
||
|
||
这样，有了基础的数据权利，你就能发现团队之间的沟通效率会大大提升，因为信息不对等的问题，从大家对基础工具的使用上就给消除了。如果一个体验设计团队不会使用数据来证明自己的设计策略的效果，那真的很难说自己是在一个维度上与运营、产品做配合。手持大刀的跟现代化的部队一起出去打仗，那前者一定是炮灰。成为炮灰可能没什么，但受损的是企业。
|
||
|
||
所以，体验设计团队需要能数据平权，并要求设计师能用量化的和从宏观到微观的角度，来看待体验设计的问题。这样，有了这个工具以后，我们才算真正地赶上了其它团队。
|
||
|
||
## 第三，把体验团队的设计流程溶解进企业
|
||
|
||
在探讨这个组织设计方法之前，我想先给你分享一个体验设计团队的两难问题，因为这个问题直接会引出体验设计团队在企业的关键定位。
|
||
|
||
如果一个设计团队不去主动思考企业的商业策略和用户目标的话，就会很容易成为产品和业务团队的设计工具，这是非常不健康的团队协作模式，它会导致设计团队失去创新的动力。而且，如果设计团队的专业性无法让其他职能部门理解，久而久之，就会造成产品的体验设计质量下降。
|
||
|
||
所以，有的设计团队就会去想办法改变这个状态，于是就开始去做产品和运营团队的工作，去自己制定业务方向。这当然也是有问题的，因为体验设计团队的知识结构并不是为了做商业架构而存在的。所以这样就很容易出现问题，也会造成团队协作之间的不和谐。
|
||
|
||
那么，体验设计团队的两难就出现了。**我们到底要不要听产品的？我们到底要不要有自己的独立思考？**很多团队就在这两极里沉沦了。我曾经也一度很困惑，我们到底要如何在企业里发挥产品设计的价值？
|
||
|
||
后来经过多年的思考，我找到了解法。那就是设计团队既不应该代替业务去做商业决策，也不应该只做其它团队的工具。**我们的任务是翻译，也就是把产品的商业决策和功能决策，翻译成用户需要的产品，而翻译的技能，就要求我们既能理解商业，又能理解用户，我们是企业内部最好的转译器。**
|
||
|
||
这个定位清晰了，我们很多工作的做法和边界就好开展了。
|
||
|
||
体验团队最重要的任务，就是在企业内部尽早地进入商业决策流程，了解到企业对于一个业务的商业判断是什么，从而指导自己资源使用的边界。然后要将自己融入到互联网产品设计交付的流程里，以确保自己的设计成果可以更好地落地。我们的核心工作，就是要能把这些信息很好地整合在一起，交付出设计方案。
|
||
|
||
我在滴滴、蔚来采用的都是类似这种的组织设计方法，这样做的好处是，设计师一早就知道了自己设计的最大目标是什么，从而也学会了如何将商业目标拆解、转化为设计目标。而没有做到此流程的团队，最终就会像我刚才说的，在两个极端里面打转。
|
||
|
||
所以，溶解流程、收集信息、整合设计、确保交付，就是体验设计团队和企业结合的完整流程架构。
|
||
|
||
## 课程小结
|
||
|
||
今天我们一起讨论和确定了互联网产品体验设计组织迭代的三个方向：
|
||
|
||
* **整合体验**：即将产品、运营、交互、设计、品牌按照自己的业务领域和业务需求进行整合，提升设计效率。
|
||
* **数据平权**：即建立所有职能共享的数据权利，并要让体验设计团队能够很好地应用数据。
|
||
* **溶解流程**：即要明确体验设计团队在企业内部的定位是翻译，而溶解进入企业流程当中，是翻译正确交付的必要手段。
|
||
|
||
这三个改进方向呢，都是我最近5年在顾问工作中，感受到产品体验团队一旦做了就立刻有效果的事情。但很遗憾的是，我看到更多的企业的体验设计团队，都在商业增长的压力之下，找不到自己的定位和发展方向，非常迷茫。
|
||
|
||
所以，在搭建发挥产品设计价值的流程架构的时候，我们首先要知道，任何一个团队都有自己在企业生命周期中最重要的时刻，然后我们也要清楚，并不是所有的时候都会顺风顺水。
|
||
|
||
但只要我们理解了这个组织体系的架构规律，就会在顺利的时候不自大，在有压力的时候不气馁，一步一步地用自己的能力，来帮助企业完成好业务的发展目标。
|
||
|
||
|
||
|
||
## 一课一思
|
||
|
||
基于今天所讲的三点关于搭建体验组织体系的建议，你觉得，自己所在企业的体验团队，该如何更新组织迭代方向呢？欢迎留言给我，我们一起讨论。
|
||
|
||
如果你觉得有收获，也非常欢迎你把今天的内容分享给更多的朋友。感谢阅读，我们下一讲再见。
|
||
|