一台F1赛车由发动机、变速器、变速器换档杆、消声器、后车翼、后轮毂支驾、轮毂、油箱、车手座椅、方向盘、后视镜、刹车盘、悬架三角支架、轮胎、底盘、散热器、前轮毂支架、安全螺母、前车翼等配件组成，在一个赛季的比赛中，这些配件不断的损耗、被替换，伴随车手完成赛季比赛。
我觉得产品上线运营就像赛车一个赛季，在赛前我们要做好充分的准备，在比赛中，要不断的超越对手才能取得胜利。
如果一台F1赛车在比赛前就漏洞百出，那在开赛后它只能是一台老爷车，在维修站呆上再长的时间，它也追不上呼啸而过的其他赛车。（当然无论多好的车子在比赛中也会出状况，在维修站里花最少的时间，抢先1秒，就会离胜利更近一些。）
开赛前的准备和测试，让赛车配备了最好、最合适的配件来达到最高的效率。那产品在上线前，它是否已经有了最好的配备？或者说它在配置过程中，是否已经有了损耗，这个损耗能否降到最低？
来看看我们的产品在上线前的流程吧。
产品经理需求调研、制作BRD——BRD评审——项目启动会——featurelist、DEMO——featurelist评审——交互、视觉设计——产品经理制作PRD——PRD评审——前端HTML——HTML评审——技术开发——预发布——上线运营——改进
在这个流程中，损耗肯定存在，因为过程中不同的同事经手，产品经理往往注重需求是否被满足、页面大体效果及交互过程有没出现逻辑问题，可是真正涉及到页面中的布局、结构、视觉表现、对比、对齐、重复、亲密性等细节往往需要视觉设计师与前端设计师的紧密配合。
比如：
1、该模块在视觉稿中，默认2行显示，前端也实现了2行，同时在行间距、字体颜色都做到了和视觉稿的一致性。 可是真正到上线运营后，2行并不能够满足运营的需求。（这个情况我们该怎么办？ 对，很简单，做字数限制，超出的做截断，可是要改这个需要走一遍流程，而在这之前没人晓得这里会放多少文字，以为2行都有多了）
2、列表页也同样存在这样的问题，上线前产品经理到交互再到视觉，已经把标题长度留的够长了，结果上线后用户写的标题长度超出，导致标题2行显示，其他用户反映看着就觉得特别累。（该问题在于上线前我们没有考虑在这里做字数截断，类似这种问题很常见。）另外，在上线前，HTML给到技术部。技术部忙完，测试忙完，上线了。怎么背景的灰色没了，用户大喊白背景下看我们的列表眼睛很辛苦。（技术拿着前端稿子开工的时候，把背景色遗漏了，结果技术没发现。视觉设计师根本不晓得这页面啥时候就已经在线上了。）
3、页面中任何模块的存在，其实都是有对齐的，我觉得可以理解为，X轴和Y轴注定了这个模块的坐标。1个地方没对齐都会让页面变的错乱。前端在制作HTML过程中，有时候并不知道视觉设计师在考虑位置时是依据哪个模块做的对齐，结果HTML出了问题，但是前端并没看出来。（我觉得前端HTML出来后，视觉设计师还是非常有必要跟进每一个细节）
4、产品经理拿着HTML，到技术那边，突然发现漏了个啥小东西，技术一加，其他模块一套，产品经理手一挥，完事了。上线后设计师要哭了，连对齐都没有了。
……
各种情况都有可能发生，页面从视觉稿到线上的效果，就在这个过程中慢慢损耗了，所以视觉稿往往比线上效果好很多。
以上提到的问题有的已经改进，有的已经有了更好的解决方案。
写这篇文章并不是想把责任归给谁，而是让大家反思如何提高团队的默契度，降低损耗，让我们的F1离胜利更近一些呢？
很酷的F1!
顶土豆
确实很多时候经常会发生这些惨剧。。经常东西上线后和原来的稿子天差地别，囧
需要沟通需要沟通
前排阅读。
汗，需要检查并反馈
认真看完后，受益匪浅。
沟通太重要了，之前遇到过个小专题其中有些大标题我以为是定死的就+了效果。设计完成后需求方却跟前端说这些标题也可编辑…结果上线后，我欲哭无泪
图片用了外链，貌似不太稳定。如没显示图片请猛按F5
好文，收藏至20ju.com
我们也经常遇到这样的问题
的确有这样的情况，不过，还有另外的情况就是原始视觉稿不合理的地方的修改。不过本文里的视觉设计稿的内容都合理的。建议设计师一定要写设计说明，这样可能会好一些。
这种事件太常见了，一般情况我都会事先让相关人员先制作相关数据或者虚拟数据，然后根据数据进行设计，所有的设计都是基于数据可视化这样才有意义。不过现在大多公司里面各方都会强加思想上来，只能期望整体团队水平提高，从高到低的意识要到位。唉~
最好的方式是：PSD到HTML都由设计师一人来做，本应该如此。视觉设计师必须具备前端开发能力。
昨晚刚看了5星级邮箱的打造，对其中ui来布置页面的感触最深，虽然多了一个工作和必须的学习，但缩短了之前与技术频繁沟通的过程，而且可以更加方便的随时调整来更加适配产品的功能需求
it works,,,,,, it lools,,,,,,
前端完成后，在做各浏览器间的兼容性测试时，把页面截屏。将截屏与图稿放进PS环境里，半透明层叠起来看差别。
尽可能的做到与图稿效果一致，技术上很难解决的差异问题，需要找视觉设计师确认协商。并在设计文档中做以说明/标注。
——–
同样的，后端技术将前端交付整合到程序中时，也需要在测试后与前端和视觉设计做最终确认。
以上，仅是图形视觉上的损耗控制，至于功能，交互方式，描述性文字，经常会出于各种目的做了一些修改，那么就需要在交付交与相关环节负责人进行确认。
===================
综上的方法适合小型团队，沟通成本较低，相对灵活一些。
至于中大型团队的开发模式，还是用严格规范的文档传递一做沟通比较好。
相差很大哦
不错 很幽默