前言“这个做不到，很难做，我没时间，改这个有什么意义？上次不是刚改的吗，问我干嘛去改变它？”“我从来没见过像你这样的设计师，不就是几个像素吗？有必要剪这么薄吗，能行就好了。还改？！我觉得这个已经很好看了，不过这样做很麻烦……”设计师们是不是已经开始不耐烦了，摩拳擦掌？上面这些场景，在向开发者索取需求和设计走查的时候经常会遇到，或者无奈，或者愤怒，但是开发者有无数的理由拒绝你。.说白了，这个问题一般会在你职业生涯的某个阶段遇到，迟早会遇到，虽然晚了，但一般不会缺席。想必很多设计者都踩过下面的坑……上线后，还原不到位，领导的责任就是“你这个怎么设计的，为什么这里设计成这样？”一副设计稿，一把辛酸的泪……你这是在为自己辩解，对不起，领导说：“我只看结果。”我问你生气了吗？你在生气吗？为什么开发拒绝了你？把剑收起来，我们先分析一下。这个问题不会随着技术的变化而变化，似乎methodology也没有固定的解题策略，但是在面试中经常遇到，比如“开发不配合，还原度不高怎么办”不高”。这足以说明很多公司都会有这个问题。说到底，还是人的问题。且看“当事人”怎么说。因为一些原因，做了很多开发，也请教了几个前端朋友。不管开发商口头拒绝的原因多么奇怪，总的来说，开发商对设计修复的反感或不愿意配合可以归纳为以下几个原因：1、业务紧，任务重。可能是项目急着上线，也可能是一堆需求。它尚未交付。当开发者有更重要的事情要处理时，他不能分心或使用额外的劳动来设计优化的内容。在很多情况下，给定的工作时间只是这些，更不用说是否与绩效挂钩了。我已经加班修复BUG，需要配合你们调动。你还有这种感觉吗？因此，设计师也应该关注项目的整个进度，尽量从宏观上把握项目的进度。能够理解或评估开发的工时。站在对方的角度考虑情况。此外，有必要确定走查结果的优先级。开发侧的用户体验因素，如性能和bug数量，应该优先于界面修复。毕竟，用户体验不等于界面的开发和实现。在bug还没有修复的时候，盯着几个像素去挑，显然是不合适的。完全可以先记录低优先级的问题，留着某个版本一起更新优化。2.有面向职业的前端方向，有一种可视化展示（动态可视化还原组件构建等），一种数据级（算法等）。通用性需要比较强的数据处理和逻辑能力。有些发展会很清楚自己的方向。比如对算法感兴趣的人，会认为专注于视觉还原这边是浪费时间，所以面对这样的需求，内心会有一定的排斥。他们通常不会专注于体验这些东西。其实恢复之类的东西都算是开发底层的基础能力。就像有的UI交互性强，有的UI视觉性强，但是交互性强的UI说不想画图标，这就没有意义了。归根结底，我的工作还是设计。3、层次不够设计界有句话叫“没有做不到的效果，只有不想做的开发”。不想做往往是态度问题，做不到是能力问题。但是技术不都是不知道的问题吗，大部分的还原问题都可以借助搜索引擎解决，只是权衡学习成本和收益的问题。如果不愿意做基础题，必要时可以找设计负责人和开发负责人反馈。4.价值观不一致。一些开发商不会赞成这种设计。你跟他说对齐亲昵，他说听不懂就得下班；他不想也不想接受或理解设计的作用，沉浸在自己的认知系统里，自然不会认同你。这种情况非常罕见。只能说公司招人马马虎虎。可以尝试多次沟通，如果还是没有结果，可以反馈给领导。以上是开发商不愿合作的常见原因。有的时候，由于客观条件的限制，确实很难解决，有时候可能会睁一只眼闭一只眼就过去了。那么还有哪些解决方案呢？设计师应该做什么？很多时候，作为设计师，我们没有办法介入开发本身的问题。作为设计师，我们应该从自身做起，解决问题。被掐指对接的开发项目不在少数。软硬兼施，用尽毕生所学与之抗衡。在耗尽力气之前，他们终于学会了一点心思与你商量。文末，所有用过的工具都结合收藏使用，希望对大家有所帮助。1、良好的沟通是前提。一切合作都建立在沟通的基础上，良好的沟通将直接决定结果。不要一听说开发不愿意做就急着打。友谊之舟，说到就翻。他们都是同事。如果没有意外，我们每天都会见面。这只会让你显得更加不专业，淡定从容……首先，要保持客观，关注问题。作为设计师，需要明确解决方案要解决的问题是什么，为什么要做这个方案，尽可能多地分析问题的根本原因，尝试连续问自己5个为什么问题。这样，在满足需求的时候，既能证明自己的方案是正确的，又能游刃有余地回答对方的问题。另一方面，在交流或设计评审中，可以广泛听取他人的建议。每个人的出发点和认知不同，也就意味着看问题的角度也会不同。多记录，多想想别人的观点，有助于你更加开阔思路，也有利于设计交接。说了这么多，这里介绍几个最常见的可以直接实施的实用方案：有条件的话，搬个凳子直接坐在开发商旁边磨（最好带点零食早点吊唁）stage.changeface，这一招通常管用），面对面的细节沟通是最有效率的。有的开发者根本不懂设计，连最基本的对齐都看不出来。不是他们不想做，而是他们真的看不出来。别笑，一把。这种方式虽然前期比较费时间，但不仅可以培养感情，而且比聊天式的交流更清晰高效。因为面对面的交流能感受到你的情绪和状态，所以有句话叫“线下相见，不如网聊千遍”。尽量与开发相结合。比如有球赛就一起去玩，有机会就一起吃饭，聚会就多玩聊天。熟悉之后再调整风格也不是分分钟的事。在解释你的计划时，你可以用“我解释清楚了吗”而不是“你明白我说的吗？”并从听众的角度来解释。2.如果你有一定的前端基础，经常识别烦恼，这里就不提怎么敲代码了。想必很多从事设计师的朋友，一部分原因是被代码说服了，选择了设计。不要求设计师会写代码，但理解一些常规的内容并不难。一方面提高了我们走查和还原的效率。同时，沟通可以更顺畅。熟悉主流UI框架，目前市面上主要有3种：移动H5上的Vant、PC上的Element和Ant。官网有组件库的源文件，导入sketch可以直接调用。对了，element是基于vue开发的，ant的主流是react，不过也有vue版本（https://2x.antdv.com/docs/vue/introduce-cn），所以一定要聊聊开始前到前端在进行设计之前确认使用哪个框架。尤其是B端，非大团队没有足够的人力物力从事源码开发。公司早期开发大多基于ant或Element，直接使用官方组件即可制作设计稿。Element在市场上的份额仍然更高。考虑到开发效率和成本，基本上都是根据框架来调整样式，所以遇到差距比较大的样式最好提前和前端确认一下。走查工具的应用在提到工具之前，建议大家了解一下“盒子模型”的概念。是还原前端设计布局设计稿的依据。还将使用下面要讨论的工具。空间有限。关于盒子模型内容就不展开了，有兴趣的可以自行搜索。不知道大家有没有遇到过这样的场景：开发上线后，发现实际效果和预想的有点出入。你可能想微调字体大小或者间距或者某种颜色，或者请开发高手调整，或者只是用软件调整自己试错也不是不可以，但是有一个更快的方式。下面提到的两个工具可以帮助你。浏览器审核定位，快速试错步骤一：键盘F12或右击“检查”调出代码界面如图。第二步：点击右上角的小箭头，然后移动到左侧页面，找到任何你想查看的元素，比如“UI设计_百度百科”。当你将鼠标向上移动时，你可以看到基本的元素属性。第三步：点击刚刚选中的元素“UI设计_百度百科”，对应的代码会自动定位到右侧。双击随便输入，回车立即生效。有时在测试文本的极限值时使用此方法，无需打开Sketch键入文本。第四步：元素定位，设计试错。重头戏来了，我们选择刚才的“UI设计_百度百科”为例，点击代码块右上角的“Computed”，很好，现在映入眼帘的大色块就是传说中的方框模型。简单理解就是在前端实现的时候，每一个元素都是按照类似盒子的模式一层层实现的。是的，你也可以理解为嵌套娃娃。将鼠标移动到相应的图层，可以在界面上看到每个图层对应的位置。比如这里的padding对应左侧界面绿色条的高度：10px。如何理解快速试错？比如我们要调整“UI设计_百度百科”上面的间距，点击底部的“过滤”，输入padding就可以看到这个值。点击箭头直接修改路径，双击修改直接生效。更改其他属性也是如此。这样就避免了向开发者寻求帮助，也省去了使用软件调整试错设计效果的过程。当然，这只是一个小例子。应用到各种场景之后，会有很多新的发现。比如一些网上设计的网址就可以使用这种方法获取原图。你可以自己试试。攻略神器：CSSPeeperCSSPeeper是一个Chrome浏览器插件。主要用于辅助走查。如果你看到代码就头疼，F12复习也帮不了你，那这绝对是你最好的良药。1.快速查看元素属性和间距。字号、行高、色值、字重、元素间距，你看不懂的地方，接受也可以这么容易。2.预览网页所有颜色值。只要有不合标准的地方，基本上就没什么好隐瞒的了。整站色值我给你挑，查色色，我是专业的。3、一键下载网站图片素材。图片、图标、横幅、任何素材都可以轻松下载，只要你是图片，我就下载。就问你好不香。以上两者都可以帮助我们快速接受并回归主题。这部分主要是讲了解前端的基础知识。其实主要是为了更好的交接。说到这里，顺便提一下设计交付的一些技巧：1。除了传递静态图像外，还带来交互式说明。比如基础字段限制值、图标悬停、禁用状态、适配方案等，这些不一定是产品考虑的。在设计执行过程中，可以另设一个画板并记下来，避免频繁开发。交流。此外，当涉及到难以实现或描述的微交互/样式时，可以使用现成的成品作为开发参考。直接调用代码，学习或修改可以提高他们的效率或增加他们做的意愿。毕竟说再多，见一面也好。动态效果比文案描述更容易理解。并不是所有的开发者只看静态图片就知道如何实现的。2.设计稿完成后，交付开发时必须有正式的交接，也可以拿来测试。我将简要说明设计稿的一些还原、交互难点和注意点。毕竟我还没有正式参与开发。处理。一般在开发和执行过程中会遇到小问题，到时候提供设计支持就可以了。3、注意标注平台设计稿的布局和分组。下面给大家领略一下常见的网络平台设计图，包括但不限于BlueLake、Muke、Codesign等，很多时候画布多了，设计稿都堆在一起了。即使设置了对齐，设置了间距，如果画布太多，还是很难定位。即使是产品自带的去中心化功能也解决不了。进来一点点发展，我是谁？我在哪里？我想指向哪里？图片太多，乱了难免会造成一定的不适感。那么有什么解决办法吗？这时候可以按类别/模块整理设计稿。一个模块的设计稿尽量不要超过10个。如果太多，请考虑创建一个子类别。此外，创建一个额外的绘图板用于分组。同时，也要利用平台的分组功能，设计稿的命名要准确，便于搜索定位。最后就是根据版本建立一个大文件夹，用来存放设计稿。不要将所有手稿放在一张画布上。如果太多了，不方便找。最难受的就是卡住要你砸屏幕。既然一直在讲经验，阅读稿件的开发就是我们的核心用户。良好的阅读体验可能会带来更高的代码效率。别小看这些细节，都是些小事，无非就是命名拖画板，耐心点几分钟就可以了。这些都是个人能力和敬业精神的体现。3.建立走查机制。上面说的是个人观点，但是走查机制的建立有点站在团队这边。将演练纳入整个产品设计过程的一部分。测试完成后，即可进入走查阶段。过程中需要记录并与开发沟通修改和还原问题。一来可以追溯??，防止被追责（你知道的），二来可以解决还原的问题，方便我们记录和回顾。像这样的表单模板，因为每个团队的规模和工作方式不一样，所以字段也会不一样，有的还有生产、设计、测试共同维护的表。可根据实际情况参照本模板适当增减。除了视觉上的，还可以通过走查过程中的交互式自查表做一些验证，查漏补缺。要特别注意的一件事是尽可能详细地编写演练反馈。比如截屏后，在图片上放一个箭头指向，同时在“问题描述”栏中填写文字，间距是否不良或错位等。如果颜色值不对，标记正确的颜色值。最后，即使是赶项目，也要有一个基本的设计底线。有些原则性的内容是不能随意改变的，比如通用的设计指南、一致性等，设计师需要根据实际情况来把握这个平衡点。过滤沉淀走查内容。4.提高设计在团队中的影响力。这里的“设计”不仅仅指设计师本人，还延伸到具体的设计产出、设计团队以及其他与设计相关的人和事。比如对设计团队（或个人）的项目做一些设计知识的分享、回顾和总结，让结果更专业。期间还可以介绍用户心声、用户研究结论、数据分析等，这些都是建立信任、增加影响力的方式，长期实施会带来很大的价值。5.培养开发的用户体验意识。开发的设计意识越高，设计起来就会越顺利。一方面，通过上面提到的技术分享，可以不断提高开发方的设计意识。另一方面，相关评估可以增加开发方用户体验因素的权重。比如稳定性，性能，系统资源占用和消耗，bug数量，bug解决率等等。同时，在招聘的时候也要适当的做一些筛选。再者，人们常说的界面还原程度、视觉效果、交互动态效果和优化程度等，都可以通过验收次数来量化。但要做到这一点是很难的，尤其是对于一个刚刚成立的小团队来说。这个过程涉及到多方协作，也依赖于开发方的认知和配合。需要建立以人为本，以现有工作流为基础的设计共识，所以还是需要一一分解。说到最后，以上都是在思考不合作开发、设计还原难等相关问题。经验有限，不一定能解决所有情况，具体实现因人而异。如果实在接受不了，也改变不了现状，实力允许的话可以改变。大团队的流程一定要更加规范和成熟。还遇到了一个很贴心的开发小哥，他甚至可以和你一起讨论解决方案，视觉还原等等都是基本的练习，你完全不用担心。这种发展只能说是凤毛麟角。遇到了一定要抓住，好好珍惜~
