写在前面：这一系列是读《产品思维30讲》，针对每一篇写一些自己思考。引用部分是《30讲》的原文内容，其余是自己的内容。
——————————————————
这一讲讲了微信迭代的过程，最后留了一个问题，你的人生产品打算再怎样迭代。
让我想起了在请答到做的一个功能，最开始规划是在18年4月，后来因为优先级搁置了一段时间，今年年初又拿出来看，自己都看出了很多问题。
这个功能是团队协作，因为我们的用户可能是为了公司或社团的活动来创建签到，所以可能一个活动同时由组织里的好几个人负责，而我们的用户系统是基于微信登陆的，在多人协作时会带来不便。
第一版有许多缺点
1. 臆想了许多需求
一个用户可以属于多个团队，我设计了移动活动的功能，用户可以把个人活动移到某个团队中，或者把团队A的活动移动到团队B。在后来看到的时候，觉得真是“想太多”，种把一个活动在组织间移来移去的需求真实存在吗？即使存在，需求量大吗，需要在第一版也做了吗？
当时还做了团队权限的细分，一个团队分为创始人，管理员，普通成员三种角色。创始人拥有对活动的所有增删改查权限，以及对人员的增删权限。管理员则具有由创始人赋予他的对活动的部分权限。普通成员则只能查看活动。现在想来，既然已经在一个团队里的，说明大家是为活动共同负责的，因此这种授权的需求其实非常小，尤其是拉一个协作者却只让他查看活动这种可能性更小了。
2. 表达不清晰
因为这个功能是在现有官网的基础上进行功能拓展，所以很多页面都是基于已有页面做一些改变。当时做原型，试图把页面上每个元素都画上，却让方案本身呈现变得很不清晰。后来做了减法，只把页面中我想要表现的部分画出来，其他部分用框线或直接空白表示，视觉上清晰了许多。
3. 结构层设计有问题
协作功能的结构层设计和老驴当时讨论了好久。我最初想的是像右图这种，用户点击“我创建的”（该页面目前是用来查看活动列表的）后，先选择需要查看个人活动还是团队活动，同理，在创建活动前，用户也需要先选择自己要创建个人还是哪个团队的活动。老驴建议的是左图这种结构，通过右上角来切换登陆状态，当登陆状态在团队A下，创建、查看的就都是团队A 的活动。这样的结构更清晰，而且不影响创建/查看流程，不会增加操作。
老驴说自己看出来问题这是好事，说明成长了。
总结了一下这个成长过程
1. 在做第一版的时候，我对用户并不了解，而这半年多来，通过回复用户的问题，与用户了解，查看一些统计的数据等等，我更加了解用户了，所以在规划功能的时候，会能想象到什么是用户需要的，什么是不需要的。通过数据和沟通来了解用户，能够帮助提升产品经理直觉的准确度。
2. 通过开会与开发者沟通，可以知道他们需要什么信息，不需要什么信息，在做原型写文档的时候，可以慢慢变得提供足够的信息同时避免过于啰嗦。与自己团队成员磨合，彼此了解之后，工作会更高效。
3. 学习与交流。说实话在做第一版的时候，我并没有看过多少设计/产品的书，完全凭着自己的感觉在做。然而看过一些书，观察过其他网站/APP是怎么做的之后，慢慢的就可以对“好”的用户体验设计有了一些认知。所以，要不断地学习啊！
说人生要怎么样迭代这个话题太大了，而怎么迭代自己作为产品策划者的能力，我想就是，一直学习保持有输入，一直思考保持思维活跃，一直总结保持天天向上。
