事实上，迭代设计将应用于许多领域。对于互联网来说，这也是一个新的实验。网站是一个实验领域，一个在错误中成长，在错误中变得越来越强大的实验领域。这决定了互联网产品的增长路线，必须是一条反复修正和迭代的曲线。

　　对于产品设计，大部分属于“时机问题”当初那些产品设计面临的很多环境都不成熟。究其错误，我觉得大部分都太过分了。“激进”在互联网的世界里，如果你想从一开始就彻底创新，基本上没有成功的可能。我们怎样才能做出好的产品呢？

　　对于早期的设计来说，可能会带来无尽的“返工”和低质量的设计。往往是前一个。“阶段”细节错误会导致下一阶段的完全崩溃。我们从目录网站到内容网站，再到今天的社区，网站本身的下降和反复修改变得越来越快。“阶段性”流程方式不可能“多团队同时合作”，效率低下，越来越突出。对于一些需求，我们可以尝试改进产品。不同的阶段有不同的主要核心和要求。但对于整个产品过程，产品团队是核心。

　　产品团队启动项目，进行初步的整体研究和评估，确定产品的定位、方向和大型产品概念设计。在此基础上，大致划分用户组，总结不同用户组的需求。对于表现层和底层的相对分离，对于研发，产品的输出是数据。产品架构是他的底层数据结构，业务逻辑是他的数据逻辑。产品架构将演变为网站的信息架构（专栏、布局、导航等），业务逻辑是未来交互设计的基础。

　　研发前端接口与设计前端开发相结合。有些人可能找不到这样做的原因，事实上，当我们做产品时，业务发展到一定时间，当底层需要升级或改进时，性能层不能改变；如果性能层的设计需要“改版”底层不能改变；只有当产品方向发生变化或业务逻辑发生变化时，底层和表现层才会同时发生变化+研发，或单看产品+设计，每个从上到下的过程都必须分阶段进行，后一个过程决定了下一个过程的一般范围，下一个过程影响并补充了上一个过程的详细内容。没有大的产品框架，就没有具体的信息架构。在具体的信息架构设计过程中，将对整个产品框架进行修改和补充。另一个例子是，没有需求分析，就没有具体的内容设计。在具体的内容设计过程中，需求将得到细化，需求可以合并或拆分。

　　在网站的设计和功能安排上，要注意它们之间的质量联系。对于一些设计好的用户界面，我们可以看到网站在可用性上存在一些差距。现在很多好的设计师其实都听取了可用性专家的意见，遵循了那些写作的标准；而其他团队的设计师很差，没有做任何可用性工作，或者干脆对那些研究成果视而不见，用自己编造的标准来指导实践。结果有些网站设计好，但是可用性有点欠缺。

　　对于一些团队来说，比其他团队更注重用户体验的质量，这只是个人体验的问题。对于网站的可用性，一般来说，如果一个网站，如果调查显示可用性分数范围为0%至100%，分数越高，可用性越强，满分并不意味着网站具有美的可用性。分数只能说明网站在我们现有技术条件下的所有可用性评估项目中都得了满分。

　　对于可用性，针对不同的问题，可用性质量水平之间没有联系。如果用相关性来计算它们之间的相关性，很多相关性接近0，完全微不足道。也就是说，如果一个设计团队在可用性的某个方面表现良好，其他方面的优缺点是完全未知的。

　　导航和信息架构的质量和可用性也是另一种关系。一些网站正试图提高可用性的核心要素：用户如何使用网站，他们会找到什么内容，以及他们可以提供的功能特性。这种现象很好，因为这些都是非常重要的问题。一些团队对可用性的核心领域有很多了解，而另一些团队似乎是Dreamweaver随意拼凑，建立一些随机组织、信息少的无用网站。

　　这样，事实上，即使是可用性的核心要素，它们之间的关系也不那么强烈。因此，在某一方面，并不意味着大多数其他核心问题已经得到解决。