2018年1月7日，UXRen北京分舵举办了《来自网易的用研经验和设计总结》的分享活动，本文基于嘉宾网易电商B端和数据类产品的项目负责人文宇的现场分享整理而成。
文宇老师这次的分享主要分为4部分进行阐述：
- 正确 X 正确
- 做正确的事
- 正确地做事
- 可能遇到的问题
1、正确 X 正确
b端产品特点：
此类产品大都属于工具型的，用于提升工作效率、节省成本，这类产品使用起来要高效、易用、界面上简洁明了。此类产品竞品少、门槛高，业务逻辑相当复杂、梳理起来费时费力、非常成本高，且开发人员往往长期处于紧缺状态，决定了设计的难度和高度。此类产品的用户厌恶迭代，产品的每一次改版升级意味着界面和原有产品逻辑的改变，重新学习的成本非常高。B端产品要求一次将功能做到八九不离十，甚至到极致。
做B端产品，我们可以得到什么？
专业深度，从事B端产品的设计能让我们在短时间内快速提高我们的设计水平，长期从事这类产品的设计会培养我们严谨的逻辑思维、工匠精神、在应付多角色或者大型产品的时候会更加从心应手，再去做C端产品就不再有难度。好的产品，这会让你获得很好的满足感和成就感，这证明了你设计知识具备了较高的广度和深度，更加了解产品的核心运作机制以及各类商业变现的手法。
比如：我之前在百度负责凤巢的设计，就深刻了解商业变现手法，CPC、CPM、二次变现等，广告主怎么样出价能达到一个性价比最高，那种广告样式、怎样的话术点击率高，用什么样的方式能薅到广告主更多的羊毛
2、做正确的事
问卷系统：业务用户就是产品开发人员，客户用户就是购买此服务的客户，当然可以免费使用如：问卷星、腾讯问卷等，就是广大的用研同学，在此平台上主要是创建问卷、投放问卷、回收数据、统计分析等等）、终端用户即回答问卷者。不是所有的B端产品都有终端用户，如：友盟（第三方全域数据服务商）、APM应用性能分析平台、百度云、京东云、阿里云、腾讯云等等。
有完整链条的产品有：问卷系统、糯米B商户端、凤巢等等。拿到一个产品需求后，我们设计师要将此需求拆解为业务、客户、终端这三类用户各有什么的需求，然后归纳总结得到我们的设计需求。
如：糯米商户端，针对一个连锁店客户就包含三类角色：总店店长、分店店长、服务员三级，如果是金拱门那级别就得更多了。处在服务员这一级别的就有：多个服务员、配菜员、厨师、收银员。如果就一个小店，店长一个角色就能满足他的需求。
超管嘛、自己人，在设计时间不足的情况下，可以做的毛一点，坑也是坑我们自己人，影响面不大，忍受力是杠杠的，大不了就改数据库。
为什么说要考虑终端用户的需求，你们可能会有疑问，譬如：我们创建的问卷在投放之前，自己会不会回答几次，看有没有问题，各题目之间的逻辑跳转是不是正确的，可能还会设置奖励机制鼓励用户回答我的问卷。
糯米商家端，我上一份团单，会事先考虑该团单对用户的吸引力？用户看到该团单会不会冲动并促使他们产生购买。凤巢，用户看到我投放的广告会不会点击，带来的转化率高不高，我还要不要继续优化样式或者提高广告词的出价。所以我们B端产品在有终端用户的时候一定要考虑终端用户的需求和感受，他们的需求会融入到客户用户的需求中。
为什么管理员功能权限不一定全部覆盖普通角色的权限呢？譬如：最小一级店长的权限就不能覆盖收银员的权限。
重点考虑：涉及角色、功能逻辑；如果时间充裕的情况下，重要性和时间分布就不用考虑。
但大部分情况，项目的迭代时间是偏紧张的，给予设计师的时间往往不足，所以就要求设计师抓大放小，不要在不重要的功能点上浪费太多时间，优先将核心功能设计好。
3、正确地做事
在进行具体设计前先思考功能的历史、功能之间的关联关系以及耦合关系，优先解决此类问题，然后再考虑设计的秩序、一致性以及灵活性。
3.1 设计整体体验：秩序、设计一致性、灵活性
秩序
为产品功能创建一个合适的秩序，是交互设计师的一项核心能力，此是构建产品的灵魂和框架所在，对产品的用户体验起决定性作用。
设计一致性
设计组件库和规范文档。
灵活性
随着产品的不断演进和发展，需求会不断的扩充且变得越来越复杂，单一的设计方案往往很难满足不同使用场景的和企业的定制需求，所以B端的设计方案需尽量灵活一些，尽量确保方案的可延展性。
举个例子
多选控件应用到不同的使用场景，如：
- 设计师想统计特定路径用户点击的转化情况，看AB两版方案 那个效果更好
- 外推运营产品经理需要对比同一物料在各渠道之间推广效果的好坏，以此来决定后续各渠道的推广费用
- 销售需要统计各地区的交易额，以此来决定下一个季度重点攻坚的城市
在同一设计组件下，兼容不同的使用场景：在选择路径时，为普通的多选结构+预览路径按钮，在对比渠道时，增加了颗粒度的选择，并针对每个二三级渠道表示出所在的上级渠道，方便用户理解；在对比地区时，增加了全部添加和全部移除的功能，方便用户快捷操作。在设计上充分体现了对不同需求满足时方案的灵活性，同时也降低了前端的开发难度以及维护了设计的一致性和特殊性。
3.2 在产品的大环境中考虑：平行关系、耦合关系、历史逻辑
平行关系
1、功能模块间相互独立，彼此之间不互通、不相互影响，但又从属于同一模块下
2、在平级角色条件下，多用户在同一时间使用一个模块，彼此之间独立且不相互影响
耦合关系
1、耦合分高耦合和低耦合。高耦合即各个功能模块彼此结合的越紧密，耦合性越强，独立性越差，在设计时要尽量避免这种情况发生，尽量做到每个模块之间的联系是简单的，即低耦合；如果实在没法做到这一点，就将其打包设计成一个高内聚的独立模块
2、在平级角色条件下，多用户在同一时间使用一个模块，彼此之间会相互影响，如：数据结构变化或丢失等，很容易造成其它用户在使用上的不方便
高耦合意味着功能模块之间有各种复杂的逻辑关系，很容易让人迷糊，造成使用上的苦难，易用性差
高内聚使得人更容易总结出单个模块的特征，适当降低产品的复杂性
在设计问卷时，是不是经常使用批量添加选项的功能？并对选项设置选项分值，方便自己对题目进行量化数据的统计？（选项进行量化数据导出，譬如：选择A得1分，选择B得2分）
大家有没有遇到这种情况，当问卷已经入回收中的状态，针对某一个设置了选项分值的问题你还想对其修改。
历史逻辑
用户回答完问卷后都会有一个问卷提交成功页面，来告知用户，第一版的方案采用通用的解决方式，适用所有的场景（pc、h5、手游内嵌）。
但是我们的游戏客户很不乐意了，抱怨不断，说此样式与我们的整个游戏风格不搭，天天反馈，说旧版的问卷系统他们能自定义用户答题完成的样式，为什么新版就干掉了，搞得我们业务方相当被动。
3.3 整体案例（多用户共享一个账号来看问卷的数据）
问卷的主要为产品服务，一个产品对应的用研、交互、视觉、产品、运营、开发等等干系人，一个产品在生命周期内需要投放很多问卷来进行调研，所以不是腾讯问卷和TIM多人聊天的方式来实现。
制作问卷的往往是用研同学，且一个用研同学很有可能服务多个产品，所以有道云协作QQ群形式的太重，会加重用研的负担，最后我们选择微信群这种方式。
4、可能遇到的问题
- 不了解用户
- 排期紧张
- 相互扯皮
- 线上与设计反差大
1、B端难以实地进行用户访谈，但此类用户群体忠诚度高，可以建立QQ群、泡泡群等方式，提供用户及时反馈的渠道，这样他们能及时帮我们找出很多实际问题；或者使用问卷调查等用研方法
2、拜访用户，在项目上线初期，可以拜访产品的使用者，这样能够快速了解对方在产品使用过程中的方向与思路，从而更好的进行方案设计。
3、多使用产品和竞品，让自己成为此产品的重度用户群体，这样能加深对产品的理解能力以及业务的熟悉程度
不了解用户
客户用户更换产品的难度大 ，他们的忠诚度非常高。
B端难以实地进行用户访谈，但此类用户群体忠诚度高，可以建立QQ群、泡泡群等方式，提供用户及时反馈的渠道，这样他们能及时帮我们找出很多实际问题；或者使用问卷调查等用研方法；
拜访用户，在项目上线初期，可以拜访产品的使用者，这样能够快速了解对方在产品使用过程中的方向与思路，从而更好的进行方案设计；
多使用产品和竞品，让自己成为此产品的重度用户群体，这样能加深对产品的理解能力以及业务的熟悉程度。
排期紧张
此类问题出现的可能情况：产品想在规定的时间节点上线，往往会根据上线日期倒推测试、开发、设计、产品各个环节的时间节点，此时的心态往往是急于求成，人心浮躁。
解决方案：针对产品的需求，在开始做之前和产品经理先核对功能的重要程度，在设计时不要眉毛胡子一把抓，抓大放小，沉住气来优先确保重要功能的体验，其它的小问题可以在后续修修补补
相互扯皮
此类问题出现的可能情况：
- 产品经理对需求把握不够，没有深入了解使用该功能的用户群
- 设计师错误理解了产品需求，且其他干系人对需求把控不严格
- 流程混乱
解决方案：设计师要做到比产品经理更加熟悉产品和理解用户，对产品经理不合理的需求在需求评审阶段就及时指出并给予正确的解决方案。
实现效果与设计反差大
此类问题出现的可能情况：
- 交互设计完成后，没有进行交互评审，设计方案可能实现难度大
- 排期相当紧张，功能优先于体验，先上线再说
- 项目进入开发阶段后，设计答疑与跟进没有做到位
解决方案：
- 及时评审；
- 在项目进入设计之初就对该版本的周期了然于胸，在设计时抓大放小，优先保证核心体验；
- 及时与前后端进行沟通，针对特殊情况，及时出备用的设计解决方案；
- 视觉设计尽量简洁、少样式，方便前端快速实现为主
5、写在最后
B端产品千万别想着改版，小修小改可以，尽量一次性成型。用写议论文的方法做B端产品设计，先想清楚重点和逻辑，胸有成竹，再动手画稿。
若有收获，就点个赞吧
0 人点赞
