复杂产品的响应式设计流程

响应式框架确定了页面结构和响应模式，模块设计这个过程开始完善所有信息排版和交互形式，这是交互设计师最熟练也是最耗时的工作。这个过程与传统流程没太大区别，只是心里要不断提醒自己，这个模块不是只为这个设备设计，它在其它设备下会出问题吗?

交互确定页面模块细节后可以抽取出产品用到的控件、组件和公共模块，现在视觉和前端开始做一件有别于传统流程的事情。视觉根据前期定义的风格设计控组件和公共模块的视觉效果，把它们拼成一个模拟的页面，我们称之为风格拼贴稿。前端再把风格拼贴稿里的控组件和公共模块实现出来，统一维护一套组件规范代码。

传统的做法往往是页面视觉定稿后设计师开始整理视觉规范标注给前端。风格拼贴稿是将这个工作尽可能提前，并变成一个设计协作利器。它的好处是：

1、一个页面的视觉效果实际上是由一堆控组件和公共模块组成，用真实的控组件和公共模块拼贴的模拟页面已经可以呈现出产品的视觉风格。把一个产品10多个页面的视觉稿全部完成定稿是非常费时费力的事情，产出一份风格拼贴稿则轻松得多。所以它是一个高效的设计工具。

2、复杂产品总是涉及多个设计师和前端并行工作，尽早地把控组件和公共模块抽取出来统一管理，是保证视觉风格一致性的有效方法。避免不同设计师同时设计同一个控组件或公共模块，减少重复开发造成的浪费。也大大降低后期更新和维护页面的成本，比如当需要修改“关注”按钮时只需改一个就能全站生效。

Step5：响应式模块设计

PC端页面模块细节和风格拼贴稿完成后，剩下工作是拓展出平板和手机端的完整设计稿，前端产出全部响应式页面代码。进行响应式模块设计时最需要关注的仍然是让操作符合设备习惯，充分利用设备特性。

至此，一个全站响应式产品的页面就陆续出来了。很多人认为响应式设计维护成本高的理由是一个页面要同时设计多套设计稿。玩客这次经验告诉我们，确定一套设计稿和栅格系统后再拓展出其它设备下的设计方案，工作量远比想象中的低。

Step6：测试&讨论&优化，提交开发

离大功告成还差最后一步，在真实设备下测试页面效果，项目团队讨论并持续优化。

在提交开发之前需要尽早明确服务端响应(RESS)的策略。服务端与客户端结合是目前解决响应式页面性能问题的最合理方案。哪些大图片在移动设备下只需输出小尺寸图片?哪些内容在什么设备下是不需要开发输出的?哪些可以减少输出的数据数量?与开发团队协作的响应式可以有效控制页面文件大小，避免页面成为移动设备上烧用户流量的罪魁祸首。

测试通过后提交页面进入开发环节。我们从可用性和可访问性两方面总结了一份响应式页面测试checklist，测试要点包括但不限于以下内容。欢迎补充。

结语

以上流程是我们团队做完一个全站响应式项目后集体总结得出，不管你是对响应式感兴趣、正在做响应式，还是即将开始做响应式，希望对你有所帮助。

注：相关网站建设技巧阅读请移步到建站教程频道。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!