在 B 端项目中，经常会出现这样的问题：一个新项目/新功能作为开发人员，他会优先考虑产品功能，而会忽视对于最终页面呈现的还原度，也就是大家经常提起的“功能优先”，设计稿经常不还原。当我们遇到这样的情况时，究竟应该如何处理?
我相信很多 B 端设计师都会在工作当中遇到这类问题，因此咱们就来聊聊当项目本身不重视设计，应该怎么办?
重视自己
我见过同学都会抱怨设计页面还原很糟糕，导致他不情愿将自己更多的精力花在的设计页面上，进而在公司常常无所事事(mo yu)
首先给大家讲的就是自己重视自己，因为很多设计师遇到这类情况就会自暴自弃，对于页面细节的验收也不会太过于上心(设计师会说：提出来他们也不改，后面也不想再提了)导致的结果就是随着日积月累，一个页面缺少 20%的设计细节，十个页面、五十个页面?或许就会是一个灾难
因此在设计不受重视时，首先要做的就是自己重视自己。在工作产出上做到用心、负责，对于需求、设计验收都认真对待，因为只有自己做好了，这样才能够要求团队的其他成员进行协助
比如一个版本结束后，将设计细节当中的不同问题指派给不同的前端工程师，将页面上各类设计细节进行明确的标注，这样都能够让研发同事知道你对待工作的态度。一个项目团队，肯定不会讨厌一个认真负责的人。
提出问题
出现上述的问题，其实本质上是“项目赶工”所导致的。我曾经和很多开发都深入聊过这类问题，他们也不是想要刁难咱们，更多是因为项目功能的开发时间都不够，更别提设计细节
而目前大多数团队的项目开发方式还是采取 “敏捷开发” (与之相背离的是瀑布流开发，如果不了解的同学可以进行百度)，因此在每一个迭代的初期，都可以和项目负责人进行沟通，明确出设计细节还原的具体时间以及设计细节还原要求
这样能够在项目刚开始，就和大家明确项目设计要求，比如这一期因为对于功能来说，确实是比较复杂，这样作为设计师也知道项目整体情况，对于要求进行适当的放宽，那究竟如何放宽，就需要有一个页面还原相对量化的标准
页面还原的标准
设定一个页面还原的基础标准，本质上是在帮助对开发同学，在理解设计细节上有更深的认识。很多时候你会发现是，一些很明显的错误他们其实是不知道的，比如一个浅灰色和白色，对于他们而言感官上都比较类似，而一些很小的细节作为开发人员很难观察到，而通过一个标准，他可以对自己的页面进行检查，看看是否有问题，比如：
基础阶段：
页面布局形式、颜色色值、字体大小、控件使用、关键元素缺失
中级阶段：
描边的粗细、细节背景颜色上的区分、设计资源的模糊
高级阶段：
控件动效、页面内容文案、提示信息…
当然在这里只是一个简单举例，指定页面还原标准的最终目的是能够让开发有量化的标准进而能有更好态度对待设计师、设计细节。并且标准的确定，能够帮助你在会议上明确迭代标准，进一步提高团队间的协作效率。而人总是会犯错的，比如我写文章也会偶尔出现错别字，因此在严苛过后也要互相理解
当然除了标准，Design Token 也能够帮助前端快速理解基础样式，之后有时间可以单独来讲
明确后续迭代时间
当我们首先做好自己，接提出问题，然后确定好还原标准后，最主要的就是需要在一个版本后知道剩余的问题究竟应该在何时进行完善
通常解决时间存在两种不同的情况：
- 在后续 1 – 2 个版本进行迭代，将之前的问题进行解决
- 将问题汇总，后续进行一次体验上的大版本更新
这两种方法本身并没有什么好坏之分，对于我们而言，就需要将设计细节上的各类问题进行汇总，也会要求设计师需要有一个属于自己的设计体验需求池：
通常这类需求池会包括以下几类问题：
- 问题描述、问题图片、负责前端、以及后续迭代时间等等…
- 这样等问题出现过后，就能够确定相应问题对应的开发人员以及后续的时间。毕竟表格是项目管理当中最好用的工具
真诚沟通
当你在团队当中遇到问题时，更应该多和团队成员协商沟通。因为都是同事，沟通解决问题才是成年人做事的风格。比如吃一顿饭聊聊问题，大家下楼抽抽烟一起聊聊，偶尔买杯奶茶犒劳为页面辛苦还原的前端同学，有时候紧张的氛围往往因为一两句玩笑就能够得到舒缓。希望大家都能够在工作当中顺顺利利，少一些烦心事(下一期，安利几款插件，让页面验收嗖嗖嗖~)
在评论区说说实际项目当中，遇到过哪些奇葩事?
