感谢大家对黑马家族的支持，今天给大家分享 B 端体验设计的设计资产，希望可以带给大家更多 B 端设计经验。
正文
很多刚入门的B端体验设计师（UXD）是从C端转过来，或者原先从事UI设计，由于某些原因开始做B端产品的设计，迫切地想要找到入门方法，而一份完整的设计资产无疑是快速入门的良好药剂，那么B端体验设计需要出哪些设计资产？根据产品的阶段，我把设计资产分为设计前资产、设计中资产以及设计后资产。
1、设计前
产品设计前，设计师需要先做一些准备性工作，便于在后续业务中开展工作。
1.1、竞品分析文档
初步了解产品信息后，去寻找几个市场上比较成熟的竞品，选择一些相似市场、相似用户以及相似功能的竞品，做设计视角的分析。设计的竞品分析可以从以下几方面分析：需求场景、业务流程、交互体验、页面UI等。
1.2、用户调研文档
根据5W1H模型（What、Why、Who、Where、When、How），了解你设计的产品将要面对的用户，总结一句话就是：你的用户，为什么在这个时间、这个场景下，通过这种方式来做这个事情。
1.3、设计方向文档
为什么要把它列为设计前的工作，因为它是一个探索过程，在投入到具体方案设计前，设计方向是开放式的，需要经过和产品经理、前端工程师、项目经理甚至真实用户进行探讨和评估，包括UI框架选型、设计风格、设计原则、功能架构等，只有先把这些影响全局的框架定好，后续才能减少扯皮。
2、设计中
有了之前的设计前准备后就可以大胆开干，下面我罗列了相关的设计产物。
2.1、设计规范
设计规范稿在一些独立网页或者很小规模的设计中可能用不到，因为做一套设计规范本身就是不小的工作量，但是系统化的产品中，还是很有必要的。通常设计规范稿会先于功能页面产生，用于约束后续的设计，避免设计失控。一般做设计规范会先和前端讨论出产品使用的前端UI框架，是用 Ant Design 还是 Element，是用 Ant Design of React 还是 Ant Design of Angular，是用 2.x 版本还是 3.x 版本，都直接影响着设计规范的制定和落地效果，也为前端提供了参考标准，降低沟通成本。为了方便，通常设计师会直接从官网下载组件库资源用于改造和深化，组件库也会在业务的不断增加中同步升级完善，如一些沉淀下来的业务组件。另外一个点，也能以全局的视角解决具体绘制设计稿过程中，一些冗余的设计表述，如按钮各种状态样式（常态、悬停、点击、禁用、忙碌等）在设计稿中就没必要一一画出，否则设计师会累死，前端工程师也会眼花。
2.2、交互设计稿
交互设计稿是交互设计师最能体现设计水准的产物，考验了设计师对业务的理解、对通用设计的应用、对逻辑能力的展示、以及对细节的把控，我做的交互设计稿中一般包含以下几个点：
2.2.1、布局说明
产品的设计离不开布局，容器是固定宽高，还是自适应宽高，元素的定位是绝对位置还是相对位置，都要表达清楚，不要以为你懂了前端也懂，绝大部分前端都是对细节没什么追求的，如果你不表达明白，他们会瞎做一通，到走查的时候你就知道多痛苦了。
2.2.2、逻辑编排
作为交互设计师，页面中的每个元素你都要知道它是干嘛用的，是否能点击还是悬停有效果，点完是唤出弹窗还是抽屉或者直接跳转，跳转是当前页跳转还是新开浏览器页签，抑或是关闭弹窗，再弹出全局提示等等，不仅要知道怎么用，还要知道为什么，防止设计宣讲的时候被人问倒闹笑话。
2.2.3、业务逻辑
页面是静止的，但业务是动态的，因此设计表达的时候还要充分考虑业务场景的切换。举个例子，列表中有三种不同状态的数据，分别对应了不同的操作按钮，当做了某个操作后触发状态的变更，这时候你要知道触发条件是什么，虽然这个和产品经理的责任有些挂钩，但是一旦你不能同步了解，很容易跟不上产品经理的思路，这就叫做“业务逻辑”，也可以理解为业务场景和设计的关系。
2.2.4、组件状态
B端产品页面的构成基本都是由组件搭建而成，设计师需要了解每一个组件的属性，这样在使用的时候才能告诉开发当前组件处于什么状态，举个例子，表单中出现单行文本输入框，那么你就要写清楚，该输入框的占位提示语/是否必填/是否有校验/是否支持清空等等，否则你糊涂，开发也跟着糊涂。
2.2.5、极端情况说明
作为交互设计师，一定要带有一颗测试人员的心，你做的东西不仅要在设计稿上完美展示，还得考虑不同设备，不同浏览器，不同数据量等各种场景的兼容问题，也叫做“极端思维”。
2.3、UI设计稿
B端其实很少招专门的UI设计，大部分都是基于组件库来堆积木似地组装页面，对视觉的要求没有C端那么苛刻，而且设计师本身也具备这方面的美感，因此通常交互设计师可以一起完成，省去很多成本，同时由于视觉和交互是紧密关联的，一个人完成也有利于设计表达的统一和连贯性。UI稿的绘制需要注意4个点：
2.3.1、统一基准分辨率
一套设计稿原则上只采用一套基准分辨率，PC端目前市面上主流分辨率有4种，1280x800px、1366x768px、1440x900px、1920x1080px，高度随着页面内容可以无限向下撑开。我习惯用1440尺寸，视觉效果相对好些，且向上向下适配都不会太突兀，当然做页面的时候就要时刻注意页面的自适应情况。还有一些智能化设备有各种尺寸，另当别论。还有一个细节要注意，就是页面在真实浏览器应用的时候还要考虑浏览器的头部（100-130px之间，不同浏览器也不太一样），电脑自带的底部工具栏等占用屏幕高度（win一般默认60左右，可调整）。
2.3.2、命名规范清晰
清晰的命名规范，有助于自己梳理设计稿，以及交代页面之间的交互情况，也有利于前端对照设计稿开发页面时候不会那么乱。
2.3.3、稿件完整
当无法用语言表述清楚你的设计时，最好直接上图，有时候穷举的办法是最简单有效的。举个列表操作列宽度和按钮关系规则的例子。
该例子如果直接用语言表述就是一个公式：操作列宽度=（间距12+图标宽度14）*图标最大个数n+右间距12，其中图标个数最多不超过6个，另当图标最大个数=1时比较特殊。
2.3.4、备注
备注一般包含7种信息：设计稿名称、设计稿编号（一般是同一批设计稿的建议排序，引导开发顺序）、设计人（便于设计追踪）、项目信息（项目名称、产品经理等信息）、迭代、需求名称、设计发布时间（如果有多次迭代也方便找到最新版本）、备注信息等。当然也视情况而定。
2.4、切图
切图是设计交付内容中很重要的一环，相当于一个机器的零部件。通常切图分为三种：图标、背景、插图。输送切图素材一般采用直接切图和上传云上给前端2种方式。图标我习惯导出svg或者png格式，svg可以上传到iconfont图标库，前端会直接引用，可以灵活调整颜色和大小，当然仅限单色图标，彩色图标不支持变色。png可以直接打包给前端。背景给前端的时候注意提前压缩大小，我比较喜欢采用熊猫压缩工具，可以无损压缩。插图也可以算是一种图标，通常比较复杂，可以用AI绘制成矢量图，导出svg或者png给前端。所有的切图素材最好做好命名规范，有利于后期维护。
2.5、标注图
早些年还没有比较智能的标注工具，一般是手动标注，通常用markman（马克鳗），pxcook（像素大厨）这种，但是每次修改都麻烦得要死，后面蓝湖、sketchmeasure等工具出现后开始采用智能化标注，不需要手动标尺寸，直接采用网页上查看，自动测量尺寸间距。
2.6、设计走查结果
这个环节通常是前端提测后才有的产物，也是研发过程中设计师把关的最后一环，需要提前设立好走查颗粒度，以及提缺陷的方式，最好能够灵活管理，目前很多devops管理工具都支持提缺陷，如禅道、ones、worktile、TAPD等。这里会涉及到一个问题，就是和前端的恩怨情仇，设计走查往往是很细致的问题，有时候一个页面会出现n多样式问题，如果全部列成独立bug，前端会疯掉的，如果打包成1个问题，则有的问题解决有的暂时没法解决，有的还有可能另外指派解决人，就会比较麻烦。因此需要考虑一条bug包含什么范围的内容。我在协同的时候都是“先礼后兵”，先采用协同文档（我一般用钉钉文档或企微文档）记录问题明细表，先和前端沟通修改，并且实时同步进度，在上线前多久需要修改完整，如果未修改再提交到正式的缺陷列表进行跟踪，一来减少了前端的bug数量，对他们来说是很友好的，同时还能兼顾你提出的问题不会没人跟踪，当然也会牺牲你的一部分时间精力，换取的是你和前端的关系，孰轻孰重自己掂量。
3、设计后
一款实体产品上市后需要售后、收集反馈、更新迭代，软件产品也是一样，在产品上线后设计师的工作并没有结束，而是进入到“设计后”环节，这个环节的目的通常有以下几点：查看使用情况是否理想、是否有因为设计导致的使用问题、是否有更好的解决方案等，为后续产品迭代提供依据。一般会通过几种方式来达到目的：1、做埋点，收集用户使用数据验证设计；2、调研问卷，收集用户主观使用感受和反馈；3、竞品分析，对比同类竞品的同类功能孰优孰劣，取长补短。
4、总结
设计是一个介于客观理性（严谨性、逻辑性）和主观感性（创新性、美感）之间的工作，作为B端体验设计，目标就是设计出能让用户觉得有用、好用、易用的产品，因此在创作过程中就需要不断以用户角度去思考设计的合理性，并且能够让开发根据你的设计高度还原产品（设计的表达以及和上下游的有效协作）。只有当你思考的足够多，你的产出才更有价值，而你则会更值钱。（最后附上平时产出的一张交互设计稿仅供参考）
本文来自微信公众号“黑马家族”（ID：heimauiued）。大作社经授权转载，该文观点仅代表作者本人，大作社平台仅提供信息存储空间服务。
