测试成果整理好后，我们可以更进一步地阐发，整理出一份DangerList文档，这个文档是专门提供给交互/视觉设计师们的。在这个文档中，我们要把测试中高风险级的点，转换成通俗易懂的文字提供给设计师们，奉告他们避免使用哪些设计元素，建议如何去做。

例如："设计师、工程师要注意避免disable（不成用控件）的呈现。如果要实现某一个控件不成用，建议使用图片的体例暗示，或爽性隐藏它。"

该阶段的交付功能：

测试成果原始表格

测试成果阐发和总结 – 视觉/交互指导方案

第3阶段：常规前端开辟流程

这个阶段没什么好说的。就是基于上一步的研究根本，进行页面的前端开辟。关于Mobile WEB的前端开辟规范和手艺文档，可以参考OMA、W3C Mobile WEB 最佳实践以及Developer’s Home的根本教程等等。这个步调的交付物就是传说中的DEMO。

如果该项目涉及到前端架构级别的更改（例如年夜改版之类的项目），那么你需要更新网站的前端架构体系，并且记得在最后一个阶段进行规范DPL的更新。

第4阶段：DEMO测试

在这个阶段傍边，我们做的是对页面以及研究功能，进行最终确认。需要注意，这里的测试性质和之前的兼容性测试性质完全不合。这个步调只需挑选几台最重要的机型、阅读器打开我们的DEMO页面进行目测比对，查看是否达到预期效果。如果真的发现了问题，就要先定位问题所在，并返回上一步进行BugFix；如果该问题是由于兼容性测试遗漏的问题，那么可以马上将这一点记实在案，并在下一次更新测试套装。

如果没发现问题，则转入最后一个阶段。

第5阶段：总结整理

这最后一个阶段，往往也是最能体现我们研究价值的一个阶段。我们务必静下心来，把之前所有阶段的研究过程、成果重新梳理和总结，分门别类地归类，一般可能会有如下几方面：

规范（DPL）更新（如果涉及到规范变动的话）

交互、视觉规范

前端规范

知识沉淀和总结 – 可以测验测验成立一个知识库或WIKI

分享

当然，这些只是小我的一些建议。其实还有很多有意义的沉淀体例期待着我们去测验测验。

5.其它

如果你对峙看到这里，佩服你的意志力。

通过以上所有这些流程的描述，我们也许还可以发现以下几个需要注意的处所：

资料搜集的流程，看似简单，但实际上却是最繁琐也是最重要的一个步调。它是整个研发流程的最原始根本。如果这个步调没做好或做偏了，那么就会影响到整个研发成果的质量和价值。

兼容性研究，它是最主要的一个步调，是整个流程的核心所在。

整个流程所破费的时间？依照我之前的经验，守旧估计也至少要1个月以上的时间。

整个流程是基于只有一名Mobile WEB前端工程师的情况来做的。如果有多名工程师，那么研究流程其实不需要周期的设定，也有很多毒手的细节问题都可以取得解决。

最后一点题外话，关于Mobile WEB的前端人力资源，我感觉最佳的组合是两小我。其中一小我主导兼容性研究标的目的，另外一小我主导日常和项目开辟标的目的。两小我也可以周期性地互换岗亭。这样可以做到研究和开辟齐头并进，可以很好的达到最佳状态并阐扬出最年夜价值。当然，这也要首先看公司层面是否有如此高的兼容性需求，并是否愿意投入这个本钱。

文章来历：dotoking