前端项目优化方案本文来自于woshipm.com，本文内容不(7)

动效。有些公司有专门的交互设计师，动效的实质是用户体验的提升。但是也要好好进行分析，有时候过犹不及；也有时候会对开发有影响。比如你是APP，要明白产品技术框架，很多app是原生+H5的模式，原生部分处理有些动效不需要很高的性能，但是使用H5时则会要求较高的性能。而性能会体现在使用的流畅度。可以在“人人都是产品经理”网站上搜“不想被开发一句话呛回？你得知道这3个最基础的APP技术框架”这里的解释非常全面。

与UI结合。公司不同，工作流程可能不同。有些公司在这时就需要UI设计页面，为产品上肤色。有些公司会在真正开发的时候才需要UI参与。如果你注重用户体验，注重页面美观度的话，越早让UI参与，你可能会得到更好的结果。

产品这一行，有一句常用语“少即是多”。在具体设计时，你可能会灵感爆发，有很多想法，不妨都写出来，回归上面需求分析再进行梳理。有些想法，可能暂时你找不出来优点和缺点，或者优缺点并不明显，又或者难以确定，这时，不做比做好，或者先放下、或者放在数据埋点进行数据分析、调查问卷、或者下方的测试验证中进行一些A/B测试。有些东西是平衡的，让用户感觉简单，可能就需要你考虑的更复杂；你做的东西越多，可能用户用起来就会复杂。

然后，将这一切写在产品需求文档中（PRD），将你的功能意义、流程图、脑图、大小规则、异常情况、产品原型等写在上面，将所有能考虑到的问题都写清楚，后面其他人的工作都会围绕PRD开展，切记不要出现模棱两可的歧义。写PRD要多写，详细到队友能明白，否则队友会认为你是猪；也要少写，一句话能明白的东西就别两句话，毕竟PRD中文字还是比较多的，谁都不想看，你再啰嗦，就更不想看了。总之，写清楚写明白。可以使用一些模板，网上随便搜一下，大体都差不多。

测试验证

上面做的说到底都是我们认为对的，我们的用户认为对么？为此，我们要进行验证。通过验证用数据来说话。

你设计的功能，不可避免的会站在你自己的立场上，会进入一些盲区，或者没有考虑那么全面，就算真的对，你总需要什么来支撑你的观点的。这时通过一些测试进行验证。

这部分，不同公司有不同要求。有些大公司，在需求评审时，就会拿出一些数据为佐证，来说服队友、上司。当然你也是有经历，有资金进行测试验证。有些公司会先进行需求评审，然后确定哪些地方需要进行验证，然后给你钱或者时间去验证。

验证方法有：A/B测试、用户调研等方法。

由于我没经历过测试验证这样的阶段，所以这方面我无法多说，以后用到学到了再补充。

需求评审

我们多少都是站在自己的立场上进行设计，可能由于知识面、能力、牛角尖、盲区等原因，这些设计存在这样或那样的问题，甚至于这些问题无法让团队的其他人认同，为此我们要进行需求评审，充分发挥公司里每个人的能力，来评审产品需求。然后改正问题。

为什么进行需求评审？

以各自的立场，去看待这件事，尽量找出所有问题，来解决它，否则留着问题到用户手里，你的产品会失去信用。

达成统一意见。这点非常重要。我们无法保证每一个人的意见都能被采纳，也无法保证所有的看法都能最终保持一致，实际上经常会遇到谁也无法说服谁的情况。如果保留分歧去执行，结果可想而知。

需要怎么做？

形成统一的意见很重要！

跟产品有关的所有人员都要参与。

最怕撕太淋漓尽致，更怕别人都不撕。

撕逼的时候，你抛出你的观点，若你有上一步测试验证的数据作为论据，只要你测试手段合理，试问还有谁能撕的动你？还有谁？

在需求评审大会之前，你一定要进行很多小范围内的需求评审和商议，每个环节的同事都要涉及到。和上司、和技术团队、设计、运营、销售等等进行很多接触。那些大的分歧一定要提前就解决，否则开大会时会浪费很多时间。也就是说开大会之前要让大多数人觉得这个功能有必要，并就功能的规则进行通气；至于具体的按钮啊、布局、流程可放在大会上进行探讨。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-62913-7.html