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


回到案例 , 项目前期阶段 , 设计师一边走查一发现有诸多先天的历史遗留逻辑问题 , 于是问道:“这么多坑 , 感觉根本执行不下去 , 能做吗??” , 我说“先不要过分担忧 , 先动起来 , 动起来就能发现问题和寻求到解决方案” 。
其实解决办法就是先接受和包容这些坑吧 , 尽量用优秀的设计解决方案降低历史问题对客户体验的影响 , 但同时也不是放着坑不管 , 过程中和产品以及业务相关人员商量后续如何彻底解决 , 就是项目继续推进 , 设计过程还有个职能就是暴露问题 , 问题暴露出来 , 所有的解决方案才能在项目推进中产生 。
还有个例子 , 对于包装客户业务场景的产品解决方案 , 目前产品团队要马上给出来确实很难 , 这是一个需要业务线和战略层共同参与并讨论才能决定的内容 , 怎么办呢??等着他们提供内容了再继续项目?不用
等 , 先按预设客户体验要求规划好内容结构示例 , 并形成设计解决方案 , 带着解决方案让老板们做选择题或填空永远比让老板自主命题完成整篇论文要靠谱 。
05
少即是多 , 学会接受用最简单的设计处理来解决业务需求中的复杂问题 , 不是设计改变越大价值就越大 。
少即是多这个理论在交互设计原则上有经常用 , 但在这个项目中体现的尤其突出 。
设计师在项目初期问我 , 这个需求会不会吃力不讨好 , 费老劲做了那么多基础工作 , 可能最后老板发现并没有太大的改变 , 也没做啥新的显性设计 。
我本来不想把这个点引进到文中 , 但这确实是一个经常会犯的原始的认知错误 , 和看程序员写了多少行代码来评判他的绩效如出一辙 , 其实to b产品的设计价值评价标准真的不一定是以数量来取胜 , 比如你要是能用最少的一套设计标准解决所有具有共性的中台业务线的前端展示层 , 那就真的是无上功德了 , 就像ant-design , 但这里更想表达的是设计背后支撑和依据是需要大量的前期基础研究和分析 , 设计输出只是最后的呈现状态 , 和无印良品的极简工业设计底层逻辑是一样的 。
06
虎头龙尾 , 第一个小迭代设计方案尽量完美 , 先让老板看到一个好的开始 , 你给老板希望 , 老板可能会帮你提高结果预期 。
这不算什么大的设计策略 , 就是切身体会到的一个细小妙招 , 你给了领导/老板一个好的开始 , 即便不是完美的结果 , 也会坚定他们的项目信心和结果预期、会给予更多的时间和资源的支持 , 给你扫平阻力 , 你会推进的更轻松 , 那么期结果必然会大于预期 。
因为领导开始委任给你这个项目的时候可能是一个相对选择项 , 只有你给他足够的信心之后 , 才会坚定他的绝对选择项 , 真正好的团队 , 不是一个独立造车 , 而是能把领导裹挟进你的项目中 , 为项目成功在上层力量上加持 , 因为颠覆性的项目过程中不可能一帆风顺 。
07
别忘了 , 每一个大项目的迭代都要做好结果预管理和价值评价标准 , 以方便最后做成果检验和复盘迭代 。
结果预期和评价标准是未来项目迭代调整的唯一依据 , 不然做项目就是拍脑袋 , 这在一个正经的to c项目中是最基本的标配了 , 但在to b产品中 , 因为数据样本可参考性和历史发展的差异大家都避而不谈 , 但数据有相对价值和绝对价值之分 , to b产品的用户行为数据虽然对营销没有那么大的决策性价值 , 但对用户潜在行为倾向性也有相对参照价值的 。
很幸运 , 该项目的设计负责人对项目数据埋点和上线后的数据结果统计意识非常强 , 也愿意直面自己的工作成果的真实用户数据反馈 , 此次升级是希望能将一个潜在的付费用户从进入官网平台 , 到注册免费用户 , 再到咨询商务 , 再到销售跟进到CRM系统 , 最后到正式使用服务并适时引导升级额外增值服务付费转化的完整用户漏斗 。
所以 , 你想让to b产品体验设计在价值之路上一路打怪升级 , 那么 , 你就要敢于承担真实的业务数据结果 , 敢于面对待质疑批判 , 学会对结果负责 , 是你做好用户体验价值设计所迈出的第一步 。


推荐阅读