厦门网站设计中的迭代设计

很多领域其实都会有应用到迭代设计，对于互联网，这也是一个新的实验，网站就是一块试验田，一块在错误中成长、在错误中变强变大的试验田。这决定了互联网产品的成长路线，一定是一个反复修正和迭代的曲线。对于产品设计，大多数都属于“时机问题”，当初那些产品设计，面临的很多环境并不成熟。究其错误，我认为大多数都属于过于“激进”，在互联网这个世界，如果你要从一开始就做彻彻底底的去创新，基本没有成功的可能。而这个成功，我们怎么才能做一个好的产品呢？

　　对于早期的设计来说，很多可能就是带来了无尽的“返工”和低质量设计。往往前一个“阶段”的细节失误，就能导致后一个阶段的彻底垮工。而我们从目录网站走到内容网站，又走到了今天的社区，网站本身的跌代性和反复修改变得越来越快。“阶段性”的流程方式无法“多团队同时协作”，导致的低效率，越来越凸显。而针对一些需求，我们可以尝试对产品进行改进。不同阶段有不同的主要核心和要求。但是对整个产品过程，产品团队是核心。产品团队发起项目，做前期的整体调研和评估，确定产品的定位、方向，以及大的产品概念设计。在这个基础上将所面向的用户群进行大致划分，对不同用户群体的需求进行概要分析和总结。而对于表现层和底层相对分离，对于研发来说，产品的产出物都是数据。产品架构就是他的底层数据结构，业务逻辑就是他的数据逻辑。产品架构将演变成网站的信息架构（栏目、布局、导航等），业务逻辑是未来交互设计的依据。最后，研发的前端的接口和设计的前端开发相结合。有些人可能找不到这样做的原因，其实我们在做产品的时候，业务发展到一定时候，当底层需要升级或者改进，表现层可以不用变化；如果表现层的设计需要“改版”，底层可以不用变化；只有当产品方向有变，或者业务逻辑发生变化，才会牵扯到底层和表现层同时变化。单看产品+研发，或单看产品+设计，每一个从上至下的过程都必须具备先后的阶段性，上一个的过程决定了下一个过程的大致范围，下一个过程影响并补充了上一个过程的详细内容。但是，没有大的产品框架就没有具体的信息架构，在具体的信息架构设计过程中，又会修正并补充整体的产品框架。再比如，没有需求分析，就不能有具体的内容设计，在具体的内容设计过程中，又会细化需求并有可能合并或者拆分已经修改需求。

　　最重要的就是用户调研，上述的一些都是一些理论层面，但是结合到用户才是最重要的。用户调研应该贯穿于设计的任何一个环节，在整个设计过程中既起到“引导”的作用，又起到“校验”的功效。加入了对用户的研究以后，整个“迭代的设计过程”才会变得完整和丰满。