https://www.yuque.com/frost/ux/yav79c
相信很多传统UI设计师在接到后台设计需求的时候，内心是抗拒的：表单为主的界面让我们空有一腔视觉技法无处发挥，而后就是懵逼的，prd里写的到底是什么鬼，每个字虽然都认识，但是为什么连在一起就看不懂？
在传统设计师擅长的表现、体验层上，业务方意识里并不看重，立项评审都没有邀约设计师的习惯；在设计师不熟悉的业务逻辑上，错综复杂，牵一发动全身：对此我们简直不敢多说话。
弱小、可怜、又无助可以形容B端设计师的被动局面了。毕竟，如果不看重视觉、也不看重用户体验，产品和开发两个人其实也可以商量着把活儿干了，方便、快捷还省事儿…
设计师如何在B端产品中获得更多话语权，从而发挥更大价值？
下面我会分别从战略层、框架层、交互层、视觉层分享设计师在工作中如何通过打破职能限制，化被动为主动，推行设计想法落地，为产品创造出可量化的价值的过程。
战略层——明确目标，以终为始
牢记自己的目标/使命，确信日常所作所为并未与之南辕北撤，并且每天都向着这个目标努力。”——《高效能人士的七个习惯》
无论是To B还是To C ，开始动手设计之前，都应该去“找到”产品的目标，因为我们和团队成员所有的努力与沟通都是围绕“目标”来进行的，在设计之前如果弄不明白产品整体的目标，只拘泥于自己的专业领域，为了1像素还是2像素而纠结，无异于井底之蛙、管中窥豹。
- B端产品的目标是什么？
之前看过很多有关B端设计的文章，发现都会强调B端设计目标是“提升效率”，看完我就笑了，难道所有员工都是流水线上记件结算的工人吗？把做完一件工作的时间从5分钟缩减到4分钟就都那么重要？这种一言以概之的认知未免也太狭隘了！
以自如配置的产品优化举例，整体产品设计的主要功能目标其实有三个：品质管理、成本控制、效率提升，由于公司“做超越用户期待产品”的“北极星”目标的要求，目前优化都是围绕“监管线下工作，提升出房品质”来做的，效率和成本反而成了次要考虑的部分。
如何去发现到这些目标呢？我们可以从季度总结、邮件、讲话中知道公司的战略。除此之外，我们还可以通过深度参与项目，切身的去洞察，从一个需求的“接收者”转变为“参与者”再转变为“制定者”。
所以，深度参与到项目，应该关注并输出哪些东西？
- 设计师参与用研时到底在研究什么？
一、通过和产品经理一起梳理业务流程、拆分大的业务、流程、操作、目标、用户反馈到“原子级别”
设计是解决问题的过程，当设计师在面对一团乱麻的时候，首先面对的其实是解决什么问题的问题，而拆分大问题到小问题，使无秩序的客观世界变为有秩序可理解的理性映射，就是尤其重要的第一步。
结构化思维，就是我们解决问题的第一把钥匙。而且是最关键的一把钥匙，它可以使你有条不紊、忙而不乱地去应付任何问题，去寻找其他的钥匙，而不论这个问题你是否有经验。——《解决问题的钥匙》
以我所优化的自如配置app举例，这个项目其实有个1.0版本，但是在接手的时候，大家都没有关于这个产品的第一手信息，业务流程线繁杂，牵扯很多数据、部门以及其他业务线：在我们面前的是一个错综复杂的大线团。于是我们发起了一次针对“家装一线人员”的用户调研。
在这个过程中，作为设计师的我与产品经理、用户研究员一起了解并拆解了以下5点：
1、拆解了业务方的工作流程
2、拆解了业务工作流程中的阶段性任务
3、拆解了完成阶段任务需要做的操作点
4、拆解了用户意见到具体操作点
5、拆解了阶段任务的阶段目标/评价标准
二、收集使用意见、了解、拆分使用的场景（5WH）
完成前期的梳理工作之后，对于业务框架、以及阶段性目标就有了大致的了解和明确。
之后我们还通过”问卷定量收集“使用者”优化呼声 ——邀约使用者深度访谈定性了解详细情况——线下走访使用场景“三步调研法了解以下3个信息。
1、“使用者”的用户画像（who）
2、“使用者”的使用场景(when\where\what)
3、“使用者”不按照设计路径操作后替代方案(how)
通过分析（why why 分析法），我们得到“使用者”不使用我们原有设计的原因，以及这样会对业务目标造成的后果，为之后的产品优化提供设计方向与理论依据。
三、明确B端真正的用户是谁？
为什么我会把使用app的人称为“使用者”而不是“主要用户”呢？这又可以引出一个小问题：B端产品真正主要的用户是谁？
在B端产品众多角色对于产品的众多意见中，当出现矛盾的时候，应该以谁的意见为主？
很明显，在这点上，B端和C端的侧重点是不同的。
以自如配置app为例，整个产品波及的角色大概有下面几种，除了“配置专员”之外，其他角色都不会使用它，但是也会毫无疑问受到产品的影响，或者影响产品的设计。
之上的角色都是用户，我们需要考虑他们的意见，得到他们的支持，但却并非我们的“主要用户”。
判断“主要用户”的标准也很简单，可以从三个角度去判断：“需求、规则、目标”。
所以，这个B端产品的“主要用户”是“业务方”，因为业务方对其他角色用户提出了需求（高效率、低成本、高品质），需要各个角色遵守规则（管理手段让其他角色的愉悦、恐惧），去达到业务目标（多快好省盈利）。
如果是C端产品，使用者很大可能也是“主要用户”，因为产品需要通过去解决他们的需求（如购物、看新闻、社交等），设计需要遵守这些使用者的规则如：用户习惯、人性弱点、心理等（如果我们不遵守这些规律，他们就会抛弃我们的产品，从而让我们恐惧、不爽），去达到目标（购买成功、看到最新的新闻、点赞评论），C端通过产品达成用户的目标来达成业务的目标。
经过在战略层的一番探索，我们有如下几个收获：
1、团队成员一起梳理了业务原有流程 ，团队成员对产品的认知统一了
2、通过调研，了解了“终端使用者”的使用场景，通过why\why分析法收集和发现了目前存在的问题
3、在汇报交流的过程中明确了业务方的目标，并拆解了目标到具体操作点
4、通过业务方当前的重点目标明确了优先要解决的具体问题
框架层——建立一条不漏水的水渠
明确了方向，找到优化线索之后，就可以开始着手于具体的优化，在优化的思路上，B端和C端也具有明显的区别。
在我看来，B端的设计方式就像是修建“人工水渠”，是先得把“水渠”修建好，保证方向正确，不漏水，我们再往里放“水”（使用者）。
而C端的设计方式是对“水”的引导，河流是本来就有的，所以我们需要了解目标”水流“的方向、走势、弱点才能引导他们到我们希望的地方去。
所以, 我们首先要建立一个不漏水的“水渠”。
在具体的产品设计上，每个需要管理的角色在使用中的“开始”、“过程”、“结束”都设计了相应的记录/绩效压力。
但是需要注意的是，以管理（恐惧驱动）为主，但也需要适当的愉悦激励才能事半功倍，在激励方面可以通过开展pk活动，每日推送工作数据，设立目标、奖项、排名等方式激励员工积极工作。
交互层—— “堵”不如“疏”，一场清除淤泥的运动
建好了边界，但是“淤泥”太多，或者“坡度”太高，不符合“水”流动的特性，“水”也无法按照我们希望它流动的方向灌满水渠，所以，我们还需要对使用者引导，减少他们使用的阻力。
没有最好的交互方式，只有最适合的。
用配置app举例，之前整改操作的交互方式采用“线性流程”的方式，这种交互方式的优势是每个页面的内容少，操作清晰，但是缺点也显而易见，就是一个操作流程跳转页面数过多。当时我们的整改标准多达50多项，每一项都需要跳转3次才能到达具体的整改项，会让整个任务显得冗长，这也是前期调研中，我们分析的用户反应说操作很繁琐的一个原因 。
原来“线性工作流程”交互方式
_
B端的设计是基于角色的，但是在角色之外，我们不应该忽略的是：他们也是实实在在的人，并不是机器，他们拥有着普通用户的用户习惯，如果操作成本过大，也会造成用户想出对策来不按照业务规定操作，从而影响最后的目标达成。
经过讨论之后，我和产品确定了多面板布局的交互方式，这种页面布局最大的好处是单页面可以展示更多的信息量，操作效率高，减少了页面的硬跳转，符合业务整改项目多，信息多的情况。
改版后改用“多面板布局”
但是这种布局的缺点也很明显，即一个页面承载的信息和层级都较多，识别和认知难度相比较之前会难一些。所以，当时也有争论和纠结这两种交互方式的取舍，但是后来基于两个原因，我们认为多面板的交互方式是更适合我们产品的方式。
第一个原因：基于调研，我们知道我们的产品使用者其实都非常年轻（25岁左右一、二线城市年轻人）、大学本科学历，所以他们具有一定的认知和学习能力。
第二个原因：多面板布局与一二线城市年轻人常用的外卖点餐使用的布局交互一致，从某种程度上来说，其他产品已经帮助我们教育了用户。
即使是这样，并不表示这种交互就是完美的无阻力的，我们也需要采取一些措施去尽量减少它给用户达到目标带来的阻力。
一方面我们可以通过UI设计让层级更加分明，降低视觉信息上的识别、学习难度。
另一方面，在容易误操作的地方（比如业务是要求用户得按照每个房间去检查，并提交信息保存的，这种限制性的操作和C端常规的交互方式有所不同）。所以，我们会另外给予文字信息、颜色区别（未检查为灰色、通过为绿色、不通过为红色）、toast状态提示，尽量减少用户的犯错机会，即使出现了误操作（例如；检查了房间，但是没有提交，就跳到下一个房间了）也会替用户保留数据，用户很容易从错误中恢复过来，并不会出现误操作导致数据丢失的破坏性后果。
在设计中，同样的功能通常可以通过不同的控件、组件去实施。（我的朋友，在阿里做交互设计师的season曾经告诉我，交互其实就是在思考三个问题：1、功能该使用何种控件实现。2、界面内如何布局。 3、界面间如何串联），但是我还是想要再补充一下，交互控件、布局、串联方式的选择标准应该是以前期调研或者洞察出的用户模型和用户场景为基础的：没有放诸四海都适用的，最好的交互方式，只有最适合的。
视觉层——制造适合的场景氛围
大家是不是有过这种感觉：在自习室/图书馆的时候效率奇高，一回到家里看见沙发、床就只想平躺，或者东走走西走走，效率变得奇低。
其实我们每个人完成任务的时候都需要一个场景（无论这个任务是购买、转发、点赞、或者专心学习），所以我们才需要在视觉上给予特定的任务特定的场景氛围，作为一个触发器（triger）触发用户的情绪，刺激用户更好的完成任务。
视觉层是直接面向于使用者的，它通常会决定使用者在看到这个产品后的第一印象，所以产品的视觉层并非独立于上面的“交互层”、“框架层”、“战略层”，而是应该是以上三层的支撑后的外在体现，就好像人的外表是基于内部的骨骼、血液、组织支撑后外在表现一样，它为使用者能更好的感知到产品功能、使用产品而服务。
以配置后台为例，前期的调研发现使用者多是以男性为主的，接受过大学教育，年龄在25岁左右的年轻人，使用手机的场景是嘈杂的室内。而B端本质上属于工具型产品，过度的视觉设计会干扰使用者对产品的使用。
所以从用户模型、使用场景、产品类型三个角度为抓手，我们可以得出这个产品大概的视觉方向：
- 设计原则
2、颜色规范：颜色色值克制、对比明确、不暧昧
3、字号层级：字号大小对比拉开，突出重点信息，克制辅助信息
4、间距层级：层级以5pt为基数，视觉元素亲密性有律可循
5、图标规范：使用功能性图标，扁平化、颜色造型简洁克制
后设计时期——上线不是设计的终结而是开始
在产品优化时，我们按照框架层、交互层、视觉层对产品进行了改版，但是说白了，这些都是基于前期了解和经验的猜想而已，并没有经过实际的验证会有好的效果，贸然一次性做到完美，会耗费很多的成本和资源，尤其是像自如这样有大量线下业务的互联网+企业，没有经过验证的方案要一次性在线下推广运用，确实难以取得预期效果。
当在开发资源、时间有限的情况下，成本最低的方式就是分步上线，从最近的、信任度最高的地区（北京地区）开始测试，通过前期确定的指标数据反馈来指导下一步的优化方向，而不是盲目执念于最初的设计猜想。
但是，这个时候需要产品经理/运营配合，将上线后的数据以周报的形式发送到每一个项目团队成员，设计师也需要了解到每一步的过程信息，从而共同分析原因，并参与讨论相应的下一步优化方向。
所以，对于设计师来说，产品优化上线只是设计初步猜想的落地，完美的设计往往不是一次性最好的方案，而是在猜想——修正——猜想——验证中不断精进的那个。
若有收获，就点个赞吧
0 人点赞
