■真实案例:To B产品体验设计师,如何承接并驱动项目?

笔者作为用户体验设计中心的成员 , 在接到了“带动业务持续运转和商业价值的稳步提升”的任务后 , 与团队一起承接了绝大部分以往大家所认为的产品或运营职能 , 对核心产品的平台侧和业务侧做一次运营和体验优化升级 。
■真实案例:To B产品体验设计师,如何承接并驱动项目?
文章图片

文章图片

入正题 , 设计有两种价值输出方式:一种是售卖设计本身(外包公司、设计全案公司、咨询公司)、另一种是用设计思维售卖万物(稿定设计、爱彼迎、苹果) , 这是两种截然不同的思维方式和价值形态 , 一个极度垂直 , 一个高度整合 , 同时也会将设计从业者带向不同的职业发展之路 , 这篇实例文章将会围绕它们之间的差异来展开 。
一、案例
还是延续之前的叙事穿插方式:
最近公司核心业务事业线的产品和开发团队变动非常大 , 资源变得异常短缺 , 我的老板(leader)突然找我 , 说:用户体验中心在特殊时期必须进能带动业务持续运转和商业价值的稳步提升 , 退能找准自己的专业定位 , 持续输出专业价值和协助业务目标达成……
如此云云 , 口吻没毛病吧 , 很官方很老板对不对??
但我隐约觉察到用户体验中心充当“填坑办”的任务要来了 , 那种感受就像捉奸一样又兴奋又忐忑 。
庆幸的是我的团队大部分设计师并不太排斥这种协作方式 , 毕竟互联网行业属于价值驱动型而非职能驱动型 。忐忑的是切实能感受到前面的暗坑和不确定性很多 。
这个世界有一部分人总能光鲜上场 , 长枪短炮、马肥粮足的条件出征 , 另外有一部分人注定就是在缺兵少粮、困阻重重中负重前行(哈哈 , 我希望我的老板永远看不到这片文章) 。
果不其然 , 接下来在很长一段时间内 , 设计需要承接绝大部分以往大家所认为的产品或运营职能 , 对核心产品的平台侧和业务侧做一次运营和体验优化升级 , 该事业线没有业务产品经理(目前国内大部分to b公司产品经理都是以技术产品经理为主 , 业务产品经理更多是销售担当了)、也没有用户运营岗 , 用户体验中心这个冠以建立与用户沟通通道为天职的团队 , 似乎理应承担点什么 。
事实也是如此 , 接下来团队必须从需求承接方转变为需求方 , 从专业支撑岗位转变为项目驱动岗位 。
也就是说 , 用户体验中心需要深入业务 , 在产品和技术的支持和协助下 , 结合市场和竞品研究分析 , 自己梳理业务流程并确定预期目标 , 进而发现问题和优化提升点 , 形成系统产品需求执行方案 , 然后拉项目组立项并驱动交互、UI、开发、测试上线 , 最后验证目标和效果达成 。
当然 , 以往类似这种项目流程在头部平台的to c项目中比较常见 , 但在业务的行业壁垒森严和业务逻辑异常复杂的to b项目中的确非常罕见 , 因为一个设计类的专业岗位确实很难对to b业务认知和理解上做到全穿透 , 不是能力不行 , 而是信息的不对称和权限的不对称 。
即便可以做到 , 但因为职业偏见 , 业务部门也不敢委以重任 , 毕竟平庸胜于风险 。
以往我们团队确实有过独立发起并驱动项目的经历 , 但都只限于现有产品业务逻辑基本不变 , 也不会有新的功能逻辑产生的情形下单纯对交互、视觉和品牌体验的提升 , 其结果的衡量标准也是以定性评判为主 , 行为数据变化衡量为辅 , 毕竟互联网产品体验设计很难摆脱业务 , 形成自己独立的商业价值评价体系 。
因为这篇文章不是定位为设计方法论 , 加上项目太细很容易被猜到东家是谁 , 会有打广告之嫌 , 所以整个项目背景这里就不做细节赘述和配图 , 简单描述就是:
一个以往以销售驱动产品研发来满足客户需求 , 且销售为主动 , 产品研发为被动的传统SASS业务模式将要面临一次重大的商业模式升级 , 变成销售和产品相互协同的双驱动模式 , 但在现有业务体系下要达到以上目标 , 具体需要完成以下事项:


推荐阅读