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