2023年一个案例告诉你什么是产品设计师

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

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

大家疯狂听到的UX（“油茶”-体验设计师），其实市面上大部分的应用还是从交互到UI的“技能合成师”；虽然实际工作中不会真的要求他们既画原型图又出GUI，只是要求他们互通对2个方向都有所了解，实际工作中还是会有肯定偏向的。

详细应用的大厂比如阿里/滴滴等（都是阿里系的）的社招（2年工作阅历起步），基本你去他们的内推系统或者boss上只会搜到UX这个职位，没有“UI”，也没有“交互”。

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

这么看来的话，其实全栈设计师是对高阶设计师的一种趋势需求，全栈不代表你啥都要做，只是可以利用你了解的学问和业务背景去更好的进行设计决策。

那么产品设计师这个概念其实可以理解为设计师的综合力量升级到肯定程度对自己力量的一种定位诠释和标签。

详细什么样可以把自己定位成“产品设计师”呢？下面给大家讲个通俗易懂、生动活泼、一波三折、精彩绝伦的案例。

一、先说下业务背景

年初由于疫情缘由，催生了大量的视频会议、面试的市场需求，因此某个做聘请的公司下达了紧急的业务线0-1需求：抢在全部聘请平台之前做一个视频面试工具出来。

在视频面试工具1.0急速开发上线之后，半年间平台服务不断增加，功能不断新增，流程不断耦合，原来的设计框架及语言明显已不能很好的支持将来短期内的业务拓展了。

于是UED侧自驱提出了改版2.0的提案及改版框架，盼望通过体验流程和视觉语言的优化迭代形成更有价值的驱动。

然而整体体验翻新这件事儿对于上下游来说并不是什么美差，让我们来看看他们的心理活动：

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

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

运营：emm（很认真的看框架和流程，思索1分钟），似乎体验是好了不少，但是吧有个担忧改动有点大，客户一时半会接受不了咋办；要不然别这么一次性全改了，一点点迭代吧还是保险一点。

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

二、思索用户究竟需要什么

体验改版的动身点一般基于2个维度：用户诉求+产品目标。

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

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

这个时候通常针对用户的心情低点进行相对的设计策略制定是可以直接解决对应问题的；比如用户觉得简历导入麻烦，我们就把流程路径优化，让ta少导入几次。

但仅解决眼前的问题仅是单线条的设计思路（稍显单薄），假如从闭环设计流程动身，我们就需要先归纳总结调研出来的问题分几类，为什么会有这样的问题？用户的潜在需求是什么？也就是用户究竟需要什么？

《破茧2》里有个栗子我印象很深，觉得可以关心大家更好理解“用户的潜在需求”这个概念：在马车时代，老亨利·福特说过，假如你问你的顾客需要什么，他们只会说需要一辆更快的马车。

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

结合产品本身的核心AI功能与技术就可以顺当定制出2.0的设计改版主题：SMART更懂你的服务体验。

基于用户潜在需求的设计既可以更大空间的提升对应的业务核心指标（面试场次、面试率），也可以很好的与停留在单线条设计方案的竞对拉开品牌体验上的巨大差异，这样一来也可以给PM小伙伴多一点改版的信念与动力了。

三、实现最小成本试错

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

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

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

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

这里需要引入MVP（最小化可行产品）的概念，在资源缩减的互联网下半场，精益化设计思维显得更加重要，可以关心我们在项目落地的过程中使用最小成本完成有效测试与掩盖。

实现MVP的方式许多，依据详细案例状况，我们这里采纳灰度发布的方式保障新版本在成长期用户间的平滑过渡，通过灰度下的业务指标验证改版的价值。

至于灰度发布详细是个什么操作，大家可以回忆一下是不是有时候一些app你的界面和你伴侣的界面突然长的不一样了；那或许不是由于你没有更新，而是出于灰度用户中，让你先尝尝新版本的味道，康康你们的路径和点击有什么变化。

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

五、总结一下

其实业内对于产品设计师的定义还是很模糊的，就像当时的体验