到底什么是产品设计师？用一个案例让你学会！

最近看《破茧2》有点启发，突然觉着可以还不错的解答一下之前有铁汁提过的问题了：啥是产品设计师？和体验设计师有啥区别？我们又要转型了嘛？

前情提要

在讲“产品设计师”这个概念之前，我们先再科普下现在大圈子里对“体验设计师”、“UI”、“交互”的定义都是个啥。

大家疯狂听到的UX（“油茶”-体验设计师），其实市面上大部分的应用还是从交互到UI的“技能合成师”，虽然实际工作中不会真的要求他们既画原型图又出GUI，只是要求他们互通对2个方向都有所了解，实际工作中还是会有一定偏向的。具体应用的大厂比如阿里/滴滴等（都是阿里系的）的社招（2年工作经验起步），基本你去他们的内推系统或者boss上只会搜到ux这个职位，没有“UI”，也没有“交互”。

但是这并不代表着所有的大厂都是这样的，很多大厂比如网易、腾讯等，依然还是细分交互和UI，只是对于职级资深以上的设计师会有更多的横向全栈要求（懂业务、懂产品、懂设计闭环流程中上下游的各种知识点）。

这么看来的话，其实全栈设计师是对高阶设计师的一种趋势需求，全栈不代表你啥都要做，只是可以利用你了解的知识和业务背景去更好的进行设计决策。那么产品设计师这个概念其实可以理解为设计师的综合能力升级到一定程度对自己能力的一种定位诠释和标签。具体什么样可以把自己定位成“产品设计师”呢？下面给大家讲个通俗易懂、生动活泼、一波三折、精彩绝伦的案例。

先说下业务背景

年初因为疫情原因，催生了大量的视频会议、面试的市场需求，因此某个做招聘的公司下达了紧急的业务线0-1需求：抢在所有招聘平台之前做一个视频面试工具出来。在视频面试工具1.0急速开发上线之后，半年间平台服务不断增加，功能不断新增，流程不断耦合，原来的设计框架及语言明显已不能很好的支持未来短期内的业务拓展了。

于是UED侧自驱提出了改版2.0的提案及改版框架，希望通过体验流程和视觉语言的优化迭代形成更有价值的驱动。然鹅整体体验翻新这件事儿对于上下游来说并不是什么美差，让我们来康康他们的心理活动：

1. 产品经理：

由UED主导的改版对体验流程的框架改动太大，我们要配合他们把PRD全部重写一遍，还只是费力不讨好的凑一个支援的名义。虽然改版后确实体验会更好，拓展性更强，但也不能保证对我们的KPI有多么大的帮助，就保持个中立的心态吧。

2. 技术：

天呢（第一反应），这么大的改动先劝劝他们别着急改了吧，UED主导的需求占用这么多资源不合理不合理，让我先想想拿什么理由反对比较合适....有了：1.资源不足，当前业务线占用人力太多。2.改动太大，很多框架需要重写，无法保证改版数据的提升就无法体现性价比

3. 运营 ：

emm（hin仔细的看框架和流程，思考1分钟），好像体验是好了不少，但是吧有个担心改动有点大，客户一时半会接受不了咋办，要不然别这么一次性全改了，一点点迭代吧还是保险一点。

所以如何自驱一个让大家都相对认可的有价值的2.0体验改版，并在上下游不同的配合意愿下推动整个项目的发起和落地呢？

思考用户到底需要什么

体验改版的出发点一般基于2个维度：用户诉求+产品目标，这个我觉得铁汁们都懂，之前也写过很多相关的文章。比如：

产品目标我们通过业务方、产品经理就可以获得了解，他们希望沉淀客户数据（资产积累、C端引流等）、形成竞对差异（品牌塑造）。

而用户诉求收集的方式很多，这次的案例通过和运营专员合作，一起进行客户电话访谈和社群问卷投放，通过调研可以模拟出完整的用户体验地图，类似于：

这个时候通常针对用户的情绪低点进行相对的设计策略制定是可以直接解决对应问题的。比如用户觉得简历导入麻烦，我们就把流程路径优化，让ta少导入几次。但仅解决眼前的问题仅是单线条的设计思路（稍显单薄），如果从闭环设计流程出发，我们就需要先归纳总结调研出来的问题分几类，为什么会有这样的问题，用户的潜在需求是什么？也就是用户到底需要什么？

《破茧2》里有个栗子我印象很深，觉得可以帮助大家更好理解“用户的潜在需求”这个概念：

在马车时代，老亨利·福特说过，如果你问你的顾客需要什么，他们只会说需要一辆更快的马车。

同理应用到我们本次的案例中，用户只会说ta想要更快导入简历，更便捷的面试流程，但洞察用户的潜在需求你就会发现，他们的诉求在于一套“更懂你”的服务，一套可以大面积覆盖AI智能的服务去解放他们的双手，质变提升他们的办公效率。

结合产品本身的核心AI功能与技术就可以顺利定制出2.0的设计改版主题：SMART更懂你的服务体验。基于用户潜在需求的设计既可以更大空间的提升对应的业务核心指标（面试场次、面试率），也可以很好的与停留在单线条设计方案的竞对拉开品牌体验上的巨大差异，这样一来也可以给PM小伙伴多一点改版的信心与动力了。

实现最小成本试错

一个大型自驱项目想要实现落地兑现，除了考虑满足各方的业务价值，还需要从产品生命周期角度考虑ROI（投入回报比），因为不同生命周期的策略重心是不同的，试错成本也是不同的。

比如一个探索期和成熟期的项目改版（如果没有构建固定组件库的前提下）虽然技术上的成本没有太大的差异，但用户成本就会有较大的差异，因为探索期的用户量很少，改动对于新用户的体验有所改善，对于少量老用户也没有过多影响。但成熟期进行一个大改版，就需要考虑大量用户的接受度了。

这里给大家举个栗子：基本每次苹果系统大更新，或者iPhone物理外形更新都会被一些用户吐槽，很多时候并不是因为大家真的觉得有多丑多不好用，只是大家用惯了之前的不适应新的而已。

那么如果验证用户会不会因为这个”不适应“放弃产品而成为流失用户呢？

这里需要引入MVP（最小化可行产品）的概念（有不懂的术语可以参看之前的《覆盖超广的UX全链路专业/业务术语（中英对照+注释）》）：

在资源缩减的互联网下半场，精益化设计思维显得更加重要，可以帮助我们在项目落地的过程中使用最小成本完成有效测试与覆盖。

实现MVP的方式很多，根据具体案例情况，我们这里采用灰度发布的方式保障新版本在成长期用户间的平滑过渡，通过灰度下的业务指标验证改版的价值。至于灰度发布具体是个什么操作，大家可以回忆一下是不是有时候一些app你的界面和你朋友的界面忽然长的不一样了，那也许不是因为你没有更新，而是出于灰度用户中，让你先尝尝新版本的滋味，康康你们的路径和点击有什么变化。

基于MVP的精益化设计，可以很好的安抚运营同学的顾虑，同时也为技术所需求的实际价值与性价比提供了快速验证方式。

总结一下

其实业内对于产品设计师的定义还是很模糊的，就像当初的体验设计师一样。初阶的铁汁接触起这些来也许会觉得吃力，没有关系，思维是慢慢建立的，职业生涯的要点也是慢慢递进的。

总结来说，如果未来哪一天你能够在整个项目的流程思考中，具备中下游分析能力、用户潜在需求洞察力和精益化设计思维，那么就基本匹配了一个产品设计师的定义。

欢迎关注作者的微信公众号：「Nana的设计锦囊」