1.验收目标
减少上线稿件与设计稿之间前端还原的落差
2.结果对比
- 安卓端由于排期问题 还存在部分内容没有来得及更改。MD原生组件规范导致状态栏只能采用原来的蓝色，不能跟设计稿统一，视觉分裂感较强
- iOS端由于验收和修改的时间较为充裕，上线之后与设计稿几乎无出入，但是验收过程占用时间和精力较多，且部分设计稿效果无法100%还原
- h5还原得比较好，验收也没有占用多少时间
3.原因分析
-
时间紧张
排期时未注明【投标页】为重设计页面，导致前端算错了档期，工作较紧急
-
框架原因
设计稿使用的是375pt宽度的尺寸，而安卓和iOS开发使用的是360和320的尺寸，导致部分情况下前端容易造成误操作(比如用375的设计稿下的字体大小直接输入到320尺寸的开发框架中)
-
沟通不到位
设计的时候对前端框架理解不到位，设计了不能完全还原的卡片投影形式，而前端工具做不到像设计工具那样呈现组件，导致卡片组件需要重新设计和尺寸上的沟通，浪费了一些时间;
前端遇到问题并没有主动找设计师去沟通，导致问题只能在验收中被发现;
将设计稿上传至蓝湖后，并没有跟前端进行设计思路的说明，前端拿到设计稿就开始还原，过程中缺少必要的沟通，这也是思维模式的区别，设计师和前端开发者工作类型不同，使用的工具不同，思考的模式必然存在着差异性
4. 总结规律
- 如果是页面改版的话，交付设计稿时要标记出改动的部分，方便前端估算用时和排期
- 交付设计稿之后，在旁边附加上一个简单的设计规范，注明通用组件的尺寸和要注意的地方，减少因为沟通不到位导致的设计稿偏差
- 验收时多跟开发交流，不能仅局限在钉钉的交流上，返还验收结果时可以坐到前端旁边，这样可以及时又效率的了解前端还原设计稿的方式以及他们的还原思路，避免一些无法落地的设计(本次已实行，验证了有效性)
- 对齐规则和间距直接标注在设计稿上，提高还原效率
- 如果是重要/大规模改动的设计稿，在前端着手还原之前，可以开一个简短的设计稿讲解会议，这样更有效率，前端的疑惑可以直接提出直接解答，不需要同一个问题回答三遍给三方前端
- to 上条补充：也可以把前端小哥哥小姐姐拉进同一个群 有什么问题群里问群里回答，这样也能减少对接三方的耗时
网友评论