前几天，球哥给我分享了一篇关于网易云阅读【iPhone2.0】交互设计回顾的文章，发现我们的产品的开发进度情况跟网易云阅读一些地方非常相似，再版本不断迭代中不断加入新的功能，当产品做到一定阶段后，现有的产品框架不再能满足新增加的功能和需求，并且在快速迭代中只是注重了功能的实现，没有过多的考虑交互设计及用户体验，因此一周前团队决定对产品框架及UI等重新设计。在那篇文章的启发下，横向对比一下彼此产品产品过程中的不同，来回顾及总结这次产品版本改进过程中一些问题，不会涉及到产品具体细节上，更多的是“纸上谈兵”。

（一）收集需求

收集需求的方式很多，总结下来主要来自这几个方面：1.可用性测试；2.用户反馈；3.竞品分析；4.项目内部人员；5.来自老板的需求。

1.可用性测试一般都是放在产品开发完成后去做的，如果不是功能驱动的产品，用产品用例一条条测试就可以了，很多小团队都是采用这种方式。没有想到网易的团队会在收集需求阶段做简单的可用性测试。按照我的理解是他们在原有产品用例的基础上做测试，主要的目的是为了删掉一些需求，而不是发现新需求。我们的产品在这次改版中根据需求权重也是去掉了很多功能，具体说这是什么方法更确切的说完全凭“感觉”。因此，网易这样的做法可以在产品大版本迭代中去使用，效果比凭“感觉”要好的多。因此，要完善现有产品的用例，为下一版本的更新做准备。

2.我们的产品相对来说属于小众产品，第一个版本开发完成上线一段时间后，并没有收到太多的用户的反馈，或者说没有系统性的去收集这些反馈意见，并不是产品没有什么问题，而是用户基数太少。在本次版本迭代中，没有太多的用户反馈可以拿来做参考。这么至关重要的事情，却在工作的疏忽了。因此，本次版本迭代上去一定要记录用户的反馈意见，并且要去试着建立一个完善的用户反馈系统，即使用户基数再少也要去做。以前总是在忙着用怎么样的方式实现什么样的功能，却忽略实现的功能用户反馈是什么样的。我想以后要花一定的时间去收集整理用户的反馈，甚至多抽出一些时间去接触用户。

3.由于产品的一个特殊的玩法，使得产品很难在市面上找到相似的产品出来，当然抛开那个特殊的玩法，大部分功能上或者提供的服务上有很多同类的产品。而且我们的产品部分功能还是借鉴了同类的产品。所以单独拿出一个产品或者几个产品跟我们的产品做竞品分析都不合适，另一方面互联网金融也是刚刚发展并且团队也刚刚成立没多久，另一方面，金融市场足够大 ，大家的关系并不是“竞争者”更多的是“探索者”，研究了几家互联网金融的产品，发现彼此之间都在相互借鉴。因此，我个人的理解是通过竞品分析去找功能上的差异性进而跟进他人的产品功能，不如把重心放在市场和用户身上去挖掘或者发现新的需求。

4.现在产品的需求主要来自老板（毕竟是对业务最熟悉的人），还有一部分来自项目内部人员（主要是运营人员）。我相信大多数的创业公司都是这样的方式，虽然这样的方式有很多弊端，但是保证了创业公司的产品研发效率，而不像大公司为了一个原型图都要几个产品经理能一两个月。不过想要改变这样的方式，只能是伴随着产品经理的业务能力的提升以及用户反馈系统的建立而逐步改变。

本次产品迭代过程中，跟UI设计又发生了争执，一方面是自己表达方式的问题，而一方面或者说更主要的是自己过于追求产品界面上的细节，让自己陷入到一种对“产品质感”的自我意淫中去了。现在反过来看产品的需求收集，你发现自己偏离了的工作重心，你应该把更多的时间放在产品业务上，也不是产品UI细节上，后者并不能决定你产品的成败。引以为戒，以后改正。

（二）确定体验设计的目标

当决定对APP进行大的版本改进时，最先考虑的问题时现有的产品框架已经不再能满足新增加的功能和需求，出发点并没有落在用户体验上，所以根本没有考虑体验设计的目标，更不会考虑到修改某个具体的功能的目的是什么。当看到球哥推荐的那篇文章时，并没有想着马上用这样的方法在产品上面，因为你并不能确定这样的“目标”驱动的方式是否适合我们的团队我们的产品。一方面我们收到的反馈意见就很少，再根据这些反馈意见提炼出体验设计的目标就更加的困难。而一个面对小众的产品跟面对大众的产品对产品的目标有着根本上的不同，前者考虑更多的是产品的“有用性”、“可用性”，而后者考虑的是在“有用性”，“可用性”的基础上要更多的考虑“用的爽”，因此，像网易云阅读这样面对大众的产品，用户停留在app的时间又比较长，因此就有必要去制定产品详细的体验设计的目标，这样才能保证产品“用的爽”。而对于我们的产品，还在“有用性”阶段探索着，甚至有些功能还谈不上“可用性”。总结说来，产品都是进行大版本迭代工作，但是彼此产品所处的阶段不同，而确定产品体验设计目标这样的流程或者说方法，放在“用的爽”阶段更适合。

(三)方案PK

整体团队决定进行改版的时候，其实我已经将产品改版的原型图画了出来，所以直接是拿着我出来的方案后团队觉得都还不错才决定改版的。之所以会出现这样的问题，跟我来到团队的时间有关系（这里不再累赘），所以对于大的框架方面没有所谓的方案PK。事后想想尤其是看了那篇文章后，还是有点后怕，如果你出的方案没有被大家肯定会是一个什么情况。以后有新的需求出现的时候还是尽量多出来几套方案会更好一些。

（四）交互细节

这个涉及到产品的具体情况，我会找时间单独来说，这里就不一一说明了。

（五）开发跟进

最近工作的重心就是跟进开发，中间还是遇到了不少问题，下面一一说明：

1.原型更新问题：即使高保真图出来以后在开发过程还是会出现修改原型图的时候，小团队并没有一个统一协同办公软件，很多的时候都是我一个一个告诉他们有地方需要更新。甚至有些时候还会出现忘记告诉的情况。后来想到了一个方法，就是每周把更新的地方统一告诉他们，后来发现效果也不是很好，有些更新的地方他们前端已经开放完成了。现在只能一点点盯着他们去做，也是更团队一个慢慢磨合的过程。

2.新的需求出现：版本的改进过程中会有些新的需求出现。现在的做法是全部压下来，等他们把这些过去的东西全部能完以后再考虑这些新功能，对于我们这样的团队我不知道这样会不会更好，但是，现在只能这样一步步来，后续遇到什么问题就解决什么问题，关于这一点，等版本上线后或者这个阶段产品开发完成后，再去总结这些问题。

这个版本改进过程中遇到过很多问题，这样的总结更多的是从宏观上看，涉及到具体细节的问题，我想要等到开发结束后做测试的时候去总结。