编辑导语： 对于B端设计来说，哪些因素会对设计落地产生影响呢？本文作者从需求内容、功能流程、数据信息、设计执行力四个方面对此作出了分析，一起来看一下吧。
最近看到一些关于B端设计的一些作品集，引发了心里的一些对B端设计内容的想法，从B端设计的一些影响因素和和各位讨论下设计落地的观点。
首先对于B端设计而言，个人观点它是有门槛的，这个门槛其一是对项目业务的了解；其二是B端设计是很商业行为（老话长谈）；其三目前来看B端设计没那么高的视觉美观度；其四设计师个人能否接受不好看的设计页面。
B端设计还是需要落地的设计，落地影响要素大体分为以下几种：
也很希望设计师能把自己的设计内容当成一个产品来看，不要极度完善美化它，溺爱终究不能茁壮成长，必然经过跌跌撞撞前行。
需求主体：需求主体来源是产品经理其次是市场部门再次是甲方客户（设计基本接触不到）。
一个成熟的需求必然是有一个成熟经验丰富的产品经理，来应对多变的需求诉求，设计师的任务就是将产品需求（产品会将用户需求整理成产品需求的）转化为设计需求（设计将产品需求落地，整理成设计执行需要的需求），为己所用。
个人经历来看设计推进是个循环往复的过程，这个时期可能是重复否定的过程，否定的原因有设计侧、产品侧、开发侧，共同的原因是来自需求的变动，要重复调整设计内容，具体到页面的布局，以及考虑基本的优先级等等。
同时这个短板过程也是因为对项目了解不够深入，考虑不够周全，可能会有“怎么会有这个问题”、“原来可以这么个设计方式”等等此类疑问。由此不断丰富自己，完善内容过程。
这里更多是设计和产品的“博弈”，关于设计内容的“性价比”的讨论。产品经理要求的是短平快，1+1+1模式，而设计师容易陷入做细做深的死角0.5+0.5+0.5+0.5+0.5+0.5，完善中间步骤。比如说异常提示，警示提醒等，这就是放大了用户操作范围。而产品经理是直接控制操作范围，直接为目标服务。
这里更多的是在提功能的操作方式、操作流程。多变的主体是对需求的理解不够，对甲方的需求没理解到位。因为操作对象是有专业技能的甲方B端用户，即便他们有着常规的操作方式。实际工作中经历多次功能操作的变化，变化的缘由是甲方觉得操作不顺手，但又不清楚如何做的明确方式。
产品与设计是站在两个不同角度对需求的理解，所以设计的提案可能会出现功能复杂，操作难度大，学习成本高等问题。在没有标准答案的情况下，设计需要坚持自己的价值吗？我给的答案是不需要，听从产品经理坚持的价值！不要杠。
产品经理对用户的理解会比设计高的。
设计师设计出来的设计图，是静态，且数据信息是理想状态下的样例，不能作为唯一标准，标准应是动态变化的。数据变动大体会在以下几种情况常出现：
1）字段长度极值
即字段长度约束，常应用于表格表内的字段长度约束，考虑因素可能出现单个字段占领过多的可视区域。超出长度常采用隐藏展开方式。同样包括标题、段落摘要、按钮字段、选择器等内容。标签可能不在考虑范围，有些标签是比较专业性的词，短不了。
2）内容加载
表格加载，分批加载数据，以页码或是滑动鼠标梯次加载数据（查看更多文本作为标记），大片段落分批加载不常有。
3）表单输入
数据输入格式可能有文本、数值、金额、百分比等，类型变化，赋予相应的默认提示文本。
4）网络
文件上传（上传文件类型不同）常出现的断网、空数据、网络慢数据不完整、加载失败等。
快速且准确，明确展示需求信息，快速反馈产品需求的准确度，不要美化粉饰，一切添油加醋只会阻碍业务发展。草稿上即听即画，较快的将需求页面呈现出来，且能找到问题所在。
说到这里，可以再次回到开头设计门槛的讨论，业务了解的加持，能较快的缩小需求理解周期，后边的功能操作流程、具体的细节数据动态变化都能比较好的应对和改善。甚至可在细节处做到预判，帮助产品经理完善细节。
本文由 @Ychen（啊呜計） 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。