视觉设计师如何上手B端产品

从实习到转正的期间经手了4个B端项目（CRM、SAAS等，有完整跟随产品生命周期的，也有半路接手做后续需求设计的），作为一名视觉设计师，一来就接触B端产品是件很头痛的事情，做B端就不单单是做界面设计，更多的是要去分析业务流程、梳理业务逻辑在很多时候不知何从下手，在了解业务逻辑和转变设计思维走了很多弯路，就整理下算是自己工作的总结，供各位大佬参考，不参考也行。

前言

一个好的项目，是需要不同职能人员共同协作，视觉设计师要是想要快速成长最好就是完整的参与整个产品的生命周期，包括但不限于前期用户调研、需求分析、后期设计评审和设计交付，这不仅能对业务有更深的了解，也能更顺畅的与PM、前端沟通。所以文章就分为用户调研、交互/视觉设计、设计交付三部分来详细叙述作为视觉设计师如何上手B端项目。

用户调研

用户调研（下文简称用研）可分为两个方向，一是对于新开发产品，用研是作为明确用户需求点，帮助选定产品的设计方向；而对于已经上线的产品，用研则是发现现有产品问题，帮助改版设计。在工作期间和交互设计师有对公司内部Borrow CRM（下文简称BCRM）系统改版进行过一次用研，主要分为三个步骤。

1.前期准备——了解产品

用户是谁？他们做什么？为什么这么做？这都是在前期你需要去了解的。同时也需要更宏观和全面的了解产品信息和开发难度，确保视角清晰全面。避免很多在用户体验层面上你能提出很多更优方案，但因项目开发前期遗留问题、业务方向调整等客观因素，没办法修正，只能维持原状的尴尬。

（1）首先自己走一遍业务流程，最好让测试给你一个管理员账号，按照不同的角色把所有的业务流程自己走一遍，根据业务流程把问题归纳到该流程中，整理成表，不用很美观，能方便后期增改就行。

（2）查看该项目历史文件，包括但不限于该项目的Wiki目录中会记录历史版本的需求文档、上线之后的项目总结、季度总结、以及和业务方对接的PJM手中的培训材料和使用手册，这一部分是很枯燥，但是也无法省去的部分。

如果看了历史文件之后在对照之前列的问题表，就可以相应标出因客观原因而造成的问题，做好标记。

（3）与PM和项目核心成员沟通，改版如果是设计驱动的话，PM是相对较被动，所以在要和PM沟通之前就自己熟悉下业务，在沟通中主动抛出问题并了解现阶段的产品问题是历史原因还是可优化的点。

此次沟通中可以就问题列表的内容向项目成员沟通，探讨是否有优化的空间（在和开发沟通时，最好和资深设计师了解下开发难度，有时候开发会因为麻烦而直接拒绝说这个需求不能做）

2.根据项目和用户选用最有效的调研方式

用户调研中不同目的、产品周期、产品阶段都对应不同的研究方法（《用户调研》这本书有系统的介绍用研方法），但一般可以从两个维度来区分，一个是定性（关注用户背后的原因，如用户访谈）到定量（关注数据的变化，如问卷调查），另一个是态度（访问用户觉得怎么样，如用户访谈）到行为（观看用户怎么操作，如现场观察）。

当时我们所针对的BCRM的主要用户群体是门店客服，而他们的主要工作就是使用BCRM系统对每一笔贷款进行资料录入及流程的跟踪。BCRM系统在后期功能越来越臃肿，在用户体验和系统稳定性上都有很大的问题，造成了他们工作效率的低下。所以在考虑到客服使用BCRM时都是一个闭环操作，加上客服为非专业相关人员，很难说出真实和隐性需求，最后采用现场观察和用户访问交叉使用。

在现场观察中，最好自己上手完整操作一次，且对于客服关于系统优化方案的问题，最好采用开放式问题，再一步步深入。

3.分析整理

这一部分是直接能决定你前面工作的部分是否能有效转化的关键点，最好做一个完整的文件报告，便于向项目成员讲解，也可以作为总结分享给设计内部。

报告中先展示用户对功能使用情况、用户在不同使用场景下使用情况、用户在工作流程中每个流程所要花费的时间，这样有助于项目成员了解用户的具体使用情况。之后针对功能模块、业务需求、流程模块、性能模块、视觉模块分类列出问题优化建议及优先级。再大致估算出优化建议实施后客服走完一个完整流程所需的时间，以及每个流程能节约的时间。

下图展示了几个分析和改进模版，篇幅原因就其他部分就不展示了。

交互/视觉设计

虽然个人是视觉出身，但不想把自己仅局限在视觉设计师的框架内。因为个人认为交互和视觉是相辅相成的，交互设计思路清晰考虑全面，帮助视觉设计发挥精准；视觉设计进一步的创新，帮助交互设计在核心场景、功能特点等场景找到突破口。特别是在B端项目中，不考虑交互合理性而做的视觉图是没有意义的，而且可能伴随着很多次的改稿。所以就我浅薄的经验来谈交互几个重要的点。

1.思考深度

在B端项目中，不同角色思考的角度不同，PM可能重功能上线和如期上线、业务方Leader需要系统功能偏向往业务方向、用户可能需要系统流畅高效符合他们的工作习惯，交互就是需要倾听各方意见，思考业务本身并寻得一个平衡点。这就要求做B端的交互需要一定的思考深度，吃透业务逻辑，再根据产品本身发展方向和各方需求提出合理化的方案。

2.专业广度

不论个人的职业规划是什么，优秀的设计师都应该拥有足够的专业深度和专业广度，专业广度会帮助你对产品的把握更精准、更有力，全方面的思考过程可以帮助单个环节设计输出更贴合产品也更具有竞争力。曾经和一位超资深交互设计师一起做过一个B端项目，感受就是这人是全能，从产品规划、用研、交互、视觉、开发到测试，几乎都懂，所以在做项目的时候基本上没反复改功能需求，也没被开发忽悠说效果不能做。进程如此顺利都是资深交互师项目经验足够丰富，能在现有资源下产出最好的方案。

3.沟通

以上两点算是交互过程，但合理把方案输出就需要一定的沟通能力，在做大的项目时，每个人都有自己的考虑，很难做到统一，就需要交互最大化的输入自己的设计价值，让众人信服。

视觉设计方面虽是自己本行，但要注意的很多就不细说，就列需要注意的地方供大家参考下。

1.栅格系统

栅格系统大家都很熟悉了，在后台系统中用好栅格系统是能提高界面的一致性，在后期交接设计师和交付前端都能省不少事。栅格系统分为很多种，在后台系统中推荐8点栅格，也就是以8为步进单位，来调整元素的间距和尺寸，也就是说元素的padding、margin、控件元素sizing都是8的倍数。且Sketch可以设置单元格尺寸，能提升设计效率和方便设计走查。

2.建立控件库

一个完备的控件库一是能解放设计师，在一些重复界面中能直接使用控件去搭建界面不用重复出图；二是能便利开发，若有多个B端产品，可以给前端提供一套控件库和Guideline开发成前端内部可调用的控件库，方便后续统一修改调整，减少了前端还原界面的时间。

如何建立后台系统的控件库完全可以另起一篇文章，这儿就不多说。

3.信息的层级

个人认为在做UI对于信息层级的展示是很重要的一个方面，特别是对于B端产品中满屏充斥着信息和功能入口，要更好的处理信息去引导用户进行下一步流程。其中可以使用格式塔原理中的相似性原则和接近性原则来处理表格和feeds流信息，再利用字体的字重和色号来区不同信息的主次，以表现出信息的层级。

4.Dashboard

Dashboard是视觉设计师可以发挥处之一，但是也很容易过度设计，视觉伙伴们要时刻记得“视觉服从于功能”的原则，在做界面时把握好视觉权重。Dashboard是由图表构成，图表又是由数据构成，那如何在一堆数据中组合有效数据并将其可视化表达。

（1）分析需求

设计师并不只是用图表装饰数据，而是在数据和用户之间做个调和者，让数据分析更加清晰更加易读，让用户工作负担降低。所以在拿到需求时，就需要弄清楚要解决什么问题，能获取什么数据，要分析什么关系，展示什么指标。

 · 理解数据和指标

 · 提炼关键信息、分析数据关系

这些在需求评审环节中都可以提出来了解。在此提一句，设计师还是尽可能的参加产品的需求评审和例会，可以得到一手的需求信息，并第一时间和开发沟通设计可行性，节省了后期沟通成本。因为不同图表表现出来的侧重点和分析维度不同，明确需求之后是正确图表的选择前提。

（2）选择合适的图表

在明确能得到的数据之后，就需要转化表达在图表上，且现有很多图表工具，对于后台系统比较实用的ECharts、AntV，这两个网站基本囊括了大多数的图表，如何在这茫茫多的图表中精准的进行表达也是需要注意。具体可以参考Andrew Abela整理的图表分析指南，从比较、联系、分布、构成四个维度来分别分析相对应的图表。

（3）细节

 · 背景

看到很酷炫的Dashboard概念图做参考设计时，要考虑信息识别性和开发的难易程度，比如深色背景适用于大屏设备，不会刺眼也会减少屏幕拖尾，浅色背景就适用于电脑端，特别是后台系统信息承载量大，浅色识别性上更优，手机端则是什么颜色都可以，但要注意深色和彩色适用于较少的数据信息，用于烘托气氛。所以在做后台系统上尽量用浅色作为背景。

 · 空白数据

界面有空白页，图表也应该有。而且很多人都会忽视图表的空白页，如果没有统一的表现方式，用户是无法分辨出是系统数据出bug还是本身就是为0的数据。

其中空白数据可分为两种，一是指因为系统原因或其他客观原因没有显示到界面上，整个Dashboard的图表都是空白数值，我称之为空数据（名字若不妥不要介意，只为了方便比较）；二是系统和数据都正常，但在X、Y轴某个数值为0，其他数值都为正数，我称之为无数据。这两种空白数据情况不同，在处理上同样要注意区分。空数据可以直接标明暂无数据，无数据中如柱状图就算为空数据，也要用灰色预留一定的高度展示，不然很容易让用户觉得系统出bug，没有显示完全。

 · XY轴标签信息

图表有可能有不同的时间维度需要展现，有可能周统计图表标签间距合适，月统计图表如果每个月都展示就稍显拥挤，这时除了调整标签字符，可以分析用户对于这个图表是要查看趋势信息还是具体某天的数据，根据需求来调整标签。如是查看一个月的趋势信息，可以按照7天或者用户的工作日周期来进行调整标签信息。

设计交付

才开始做B端项目的小伙伴的在第一次做UI校对时，应该大部分都是崩溃的，和效果图差的不是一点点。在做了不同项目，遇到了不同的前端兄弟后，发现前端还原程度低，也有可能是我们沟通和标注没到位。在设计评审之后可以和前端兄弟把Guideline和Icon的切图方式统一沟通下，如需要统一的和前端实现较困难的地方，在前期就沟通协调好。

其中Guideline最好是出一个完整的文档，至少要包括字体用色、按钮、输入框、选择框、导航栏、弹出框等常用的控件系统。控件作为搭建界面的基本元素，建议在标注上多费心，尽量在Guideline中就进行细节性的标注。建议把最底层和最常用的元素分类编号，如字号、颜色、按钮按英文首字母+数字进行编号，这样在之后的输入框等控件直接用编号显示字号及颜色，对于前端来说这些编号能帮助他们更完整的还原控件，也便于他们建立自己的控件库，在后续搭建界面直接调用之前样式代码，这样是能极大的提高前端界面还原的效果，也能提高前端效果自查和设计走查的效率。

设计稿标注和导出也用过好几款标注工具，简单说一下使用体验。

Sketch Measure：优点—免费、数据保存在本地、方便项目文件打包存档；缺点—不能同步后续设计修改、自动导出的assets需要先手动选择格式、仅支持Sketch。

Zeplin：优点—标注科学，自动生成Styleguide，版本覆盖管理（更新修改的设计稿，也可以对设计稿进行文件夹式分类命名排序）、项目人员管理（项目所有者可以通过邮件邀请项目成员，并对成员权限设置）、添加备注、Mac和Windows、PS和Sketch都支持；缺点—设计稿需上传到网上，对于此较敏感谨慎使用、一个账号只能免费建一个项目，付费能建3个项目、国外服务器不稳定，可能突然就挂了不能登陆。

蓝湖：国内版Zeplin，优点—免费、可免费建多个项目、标注科学、版本覆盖管理、项目人员管理、添加备注、交互连线、加载比Zeplin快、Mac和Windows、PS和Sketch；缺点—在细节上交互有所欠缺，使用感不流畅，但好在是国内团队做的，也一直也更新迭代，有很多使用上的问题也在慢慢改善。

总的来说蓝湖是使用感比较好的，性价比较高的协作工具。

总结

唐纳德·A·诺曼提出设计分为三个维度：本能层次、行为层次、反思层次，我在未深入接触B端项目时，妥妥的处于本能层次的设计，也就是只关注视觉层面的设计；但是在和B端产品360度无死角亲密接触后，会慢慢转变思维去思考背后的功能和需求，从而上升到行为层次，也就是不拘泥于视觉层次的调整而是系统的看待问题，反推需求，辨别需求真伪；而反思层次是让用户在枯燥的重复工作中有情感上的满足，把工作转化为一种责任，对于设计师来说就是在带着C端思维去设计B端产品。EICO创始人Rokey就曾提出 “ 那些成功的 ToB 型产品，往往也是在产品 ToC 化中理解非常深刻的企业。” 这一步很难但也是最能体现设计价值。

所以在B端产品的路漫漫其修远，视觉设计师在有机会做B端项目时可以勇于尝试，扩宽专业的广度，能让你转变设计思维，思考的过程也让你拥有全局观。