“一入 B 端深似海”…就这一句来开始话题吧，希望跟大家分享一篇小心得：「在 B 端产品设计中踩过的坑+趟过的泪之如何快速融入业务」，希望对想要往 B 端发展的同学有所帮助，毕竟你越了解业务，业务越需要你。
刚入职的前 1-2 周，是很好的业务熟悉阶段，在这个阶段不会有迭代项目的设计压力，也不会有产品/开发/测试同学来沟通 UI 问题…但我狠狠的错过了这个好时机，所以挥泪总结如下：
1. 一定要拥有一个最全的测试账号（测试环境+线上环境）
B 端产品用户往往是兼具多种身份角色的，「员工 A」、「管理员 A」、「管理员 B」、「管理员 C」等等身份，这些身份权限既可能交差，也可能毫不触及。所以拥有一个兼顾所有功能模块的测试账号，是了解业务的第一步。
2. 带着角色身份，有目的性地操作
前期在使用系统的时候，千万别站在一个旁观者的角度，去审视这款产品。既没有把自己当做「员工」去体验整个实施过程，也没有作为「管理员」去创建管理项目，在业务前期迭代设计中只起到了美化原型图的作用。
当然这种「没目的性的操作」还会带来另一个非常不好的点就是：对功能的记忆点很模糊，一顿猛操作后自我感觉良好，认为已经搞懂了业务逻辑…却没有去思考为什么当时要这样设计（是只为了满足业务的被动需求还是设计方案的局限，又或是基础技术方案的限制，站在不同的角色场景中，体验是否顺畅合理，是否还有其他更优化的设计方案）。这些「思考点」其实都可以简单的记录下来，到项目迭代中有涉及到这些点的时候，可以再去深挖。
这个阶段需要输出设计方案的思考点，立足用户场景，满足业务需求，与产品经理密切沟通需求与设计方案。
1. 本次迭代涉及到了哪些模块，是否在前期都有线上的实操体验？
如果前期没有操作体验过，那咱就在了解「需求」想要解决的用户场景后，带入角色的去体验模块。
2. 是全新功能设计还是既有优化？
这可以初步的判断一下时间排期，设计的优先顺序，是否需要用到「体验画布」去拟定方案，是否需要参考「竞品分析」等各种辅助设计工具（这些都是需要花时间的，紧张的迭代周期不可能满足所有需求都应用到这些）
3. 沟通（产品经理、测试、其他业务线的设计同学）
在需求分析阶段最需要紧密联系的人就是产品经理，了解他们在业务设计阶段的方案，去参考其他竞品是否有利于我们的产品设计。但产品经理站的角度往往仅是满足被动的业务需求（功能层面上）。在满足功能的同时是否有更好更顺畅的体验设计（体验角色是偏「学员」身份多一些，还是满足「管理员」身份多一些），这是我们需要跟产品经理沟通–梳理–拟定方案的。
充分「利用」好测试同学，因为他们其实才是最了解功能模块的人，每天不计其数的操作，让他们甚至比产品经理更加熟悉模块。产品需求是否设计合理，测试其实更有主动权。
如果你所在的公司拥有多业务线，其实在一些共性的功能模块上，还可以多多与其他业务线的设计同学们联系，视觉+交互上是可以借鉴，既能满足公司品牌调性一致，也能多一项设计参考，共同进步嘛…
4. 形成自己的需求清单
我之前用的方法是直接把产品的需求文档打印出来，在上面做笔记，但后来发现这种方式不仅费纸，效率也不高。现在直接在 sketch 文档里专门建立一页，把「业务背景」、「目标」、「产品解决方案」、「设计方案思路」「…」都罗列出来，随时都可以跟踪记录下每一次讨论的结果。在后续的画图中，是否画着画着就偏离了「目标」，也可以随时检查。
你是不是也会遇到视觉走查不完整的情况，有些模块细节点会被遗漏。因为走查阶段是在开发功能都提测以后，但最充裕的时间可能都没有 2 周（中途还有开发调整修改的时间、有些功能点还需要反复去看）所以时间很紧。如何才能保障至少走查两轮呢。
之前一直都是在现有的测试项目上根据迭代的功能测试，走查的界面特别零散，很容易遗漏。但如果一开始我们就创建了「专属账号」，在熟悉整个流程的情况下，对新迭代的需求进行复核，操作就会是连贯的，步骤是紧密的，就会把很多细碎的点串联起来了。
希望大家别只顾着卷，被工作节奏打乱了自己的脚步…文章写得有点幼稚，但希望能对小白菜们带来些帮助启发，大家一起进步。
B端浪潮下设计师的「尴尬」供应链资源整合是企业发展态势。
阅读文章 >本篇来源：优设网
原文地址：https://www.uisdc.com/b-end-business
广告
