图片已替换
做 B 端设计师，最痛苦的事情莫过于在项目中自己是个 “边缘人”，话语权比测试工程师还弱。
产品经理们开需求会不需要你参加，直接丢原型稿让你照着做，有什么问题别问，问就是看原型和文档（有时候文档还是手画拍照的）。
好不容易瞎子摸象，励精图治，把需求界面硬给画出来，还整了非常 “专业” 的设计规范、文档，把自己感动到快流泪。
等打包发给开发的时候，往往发现他界面已经实现一大半了，好像压根就不需要你的设计稿……或者，即使拿到你的设计、蓝湖，看都没怎么看，直接就是 CSV （Ctrl+C/V）一顿操作。
所以这不是设计了个寂寞嘛……
这种问题在目前的 B 端环境非常的普遍，是相关社群每天都要反复讨论和吐槽的话题。
下面，解析下产生这个问题的原因，再分享下解决的方法思路。作为 B 端设计师，是时候站起来了！
01、前端工程师的工作解析
要解决问题，就要先了解问题的来源，B 端前端开发为什么不像 C 端移动端开发一样会遵照设计稿来做。
一个 B 端项目最重要的价值，是实现产品的业务功能，即让它根据需求 “跑通”。理解这个思路，就要先了解下一个 B 端产品的主要结构。
在这个链条里，样式层显然是满足产品能被正常使用影响最小的一环，自然它的开发优先级也是最低的一级。
常规项目里，时间不够、人手不足是主旋律，配合离谱的需求、项目管理，开发环境就更恶劣。对于程序员来讲，“跑通” 产品肯定是核心 KPI，如果仅仅是满足最低条件的使用就筋疲力尽，那怎么会还有力气兼顾样式层。
你们可以想像如果你造个房子，地基、横梁、结构全都没完工，而且显然还是危楼，在交付期临近的场景下你有信息去兼顾建筑外表上的雕花还是玻璃材质嘛。
再者，为了开发效率，今天的前端普遍是用第三方的前端框架来开发项目的，Ant、Element、KeDesign、Angular 等等数不胜数。
里面有完整的样式包，组件库，交互事件，时间都不够了当然是拿来就用，很快就可以拼出一套完整的项目，这个过程甚至只需要对着原型搞拼素材就可以了。
用这些框架，当然也可以根据我们自己的需求修改前端样式。但是，只要看过对应的 CSS 源文件就会知道，修改起来也不是那么容易的。
所以，在进度压迫下，开发可能就直接照着原型，把第三方提供的组件套用进去，做些小修小补就完成样式层的开发了。
最后，就是开发工程师个人的职业素养了。优秀的开发是会关注细节，精益求精的，但是碰到懒散的或者一分钟班不加的新青年，想要让他们花更多精力投入到样式的调整上，是很困难的。
最常见的回复莫过于：
“这个又不是不能用，加这个样式有什么意义？”
“我这边打的 '>' 号和你用的右箭头图标有什么区别？”
“这个东西我看上去觉得挺好看的啊，为什么要改？”
“做 (Bu) 不 (Xiang) 了 (Zuo)……”
无论在产品、开发还是老板的角度，确实产品跑通的目标优先级最高，所以在开发资源不够的情况下肯定不会为设计师争取还原度的实现，这就是所谓的孤掌难鸣。
项目开发的正常轨迹，不是产品提交需求 - 设计完成交互视觉切图 - 前后端进行开发 - 测试并上线。而是：
所以， 面对这样的现状，B 端设计师应该怎么解决，给大家分享一些经验。
02、让设计落地的经验分享
1.正确的沟通和提问
设计师不是拿到产品需求一股脑就开始做设计的。而是要去理解一些基本的问题，通过和同事沟通来明确它们的答案。
必要的沟通包含下面这些要素：
- 和产品、开发确认，使用什么前端技术方案，或者使用哪套开源框架
- 确认项目周期，和开发确认他们的进度排期，留给样式层的时间有多少
- 和开发确认想要什么样的设计演示，标注、切图格式
- 让开发告诉你可以修改的样式有哪些，哪些元素不能修改
- 让开发告诉你在满足什么样的条件下愿意尽可能实现设计稿样式
我们必须要知道，设计稿还原度的落实，存在各种障碍阻力，而我们要做的就是把问题找出来，在后续的工作中去扫清这些障碍。
2.熟悉使用的框架规范
当运用了第三方的前端框架，也就意味着在样式上是不可能为所欲为的，我们接受了它的优点，就也要接受它的缺陷。
使用第三方库不是让设计师就完全不用动手了，而是肯定要根据你自己的项目、品牌做调整。
设计要落地，必然要贴合这套规范本来提供的样式和方向来创作，这样你设计出来的组件前端可以通过小改样式实现而不是重新开发一个样式库。
所以，设计师一开始就要了解这套框架的对应规范，在官网可以找到它们的设计说明、操作实例，确保你在设计前已经对这些内容有充分的认识，再开始动手。
3.提前审核设计方案
即使前面的信息获取得很充分，也不代表设计出来的界面就万无一失，不是你觉得能用就能用。而是要用最短的时间，设计出几个关键页面，并让产品和开发共同参与设计方案的评审。
尤其需要开发提出意见，哪些元素样式可以实现，哪些不可以，如果不可以，应该怎么做！
只有在实际做出来的页面中探讨，才可以更具体的规范出项目的设计思路，有了这些建议，后续的页面就可以快速进行推进直至落地了。
4.有效的标注和切图
界面全部做完以后，就要参照实际的项目环境、开发的接受程度，选择合理的标注工具。虽然 Figma 可以直接查看标注信息，但往往因为网络问题和操作习惯，开发接受不高。
当然，还可以选择其它更简单的工具，如摹客、蓝湖、像素大厨等。但因为付费因素，建议大家可以选择摹客来对项目进行标注的导出。
再然后，就是怎么提供切图的办法了，并不是所有开发都喜欢自己切图，我们的建议都是由设计师完成统一的切图文件导出。
同时，你要确保切图的文件和标注的边缘一致，包含相同的透明背景，以及使用合理的中文命名方便开发查找。
不要在标注和切图中使用大家看不懂的英文再写一长串的命名，开发要用的切图不管你怎么写的都会自己重新命名。
所以，标注和切图不是软件提供了功能设计师按功能怎么做，而是看接受方的习惯怎么使用最顺手，设计师怎么去处理。
5.有效的BUG提交方案
最后，就是在测试阶段，查找还原度的纰漏了。在实际的测试环节，测试版本能找出的问题一定是海量的，不仅是视觉样式上，肯定还有非常多逻辑、BUG、交互的问题。
开发改 Bug 一定会改得焦头烂额，这时候把所有样式问题一股脑提交给开发让他们还原，约等于让他们完成一个不可能完成的巨额工作，那肯定是要拒绝的。
所以设计师在这一阶段，要学会根据样式的优先级来提交有效的修改建议。关注对风格影响最大，且修改难度最低的细节点。
比如在我们社群中看到的这个案例，左侧是开发实现的，右侧是设计图：
如果我们提交的设计 ISSUS，是直接写和原设计稿不同，要 1：1 还原，这 “低情商“ 的表现。
”高情商“ 的做法是，布局问题不是太严重，但是配色影响较大改起来容易，前面 No.1 序号加起来也容易。所以提交的修改建议就是优先修改这两项，同时将色彩修改的数值完整给出。
这样开发只要照着你给的数值简单替换，添加下字符就可以快速完成修改，而不用自己回去慢慢看参数，对间距，花费几倍的时间做调整。
03、结语
完成上面这些工作，那么距离高还原度的设计也就不远了。设计的还原度落实是一个团队协作的成果，它不是可以简单甩锅给开发不靠谱的问题上。
需要具备同理心的设计才是团队协作的基础，强行要求开发在逻辑层没有完善下实现设计稿细节，约等于要求设计师还有几百个页面没做先去写一份超长的设计 PPT 或文档，和工作重心背道而驰。
优秀的设计师，做设计稿的目的不是就为了做个满足自己的 “好看的设计”，而是做 “解决问题的设计”。
