如何进行大版本迭代？如何高效完成产品的设计工作？

当产品需要大修改时，这意味着产品经理应该日夜赶上进度，完成新产品的设计，这也是一个难得的高压机会。抓住这个机会往往可以成为他们自己的谈话资本，那么如何迭代大版本呢？如何高效完成产品设计？我参考了前墨迹天气产品总监的分享，整理了以下七个步骤:敏捷A/B测试01前期准备概论，准备建立车间kickoff会议，验证快速实现，发布快速验证:团队内部明确了大修改目的产品的现状:在用户肖像细分用户行为偏好大修改的过程中，内部必须确定一个非常明确的目标。是只改变交互和页面，还是整个应用程序架构已经改变，另一种情况是只改变单个模块，如果模块是旧模块，当我们改变旧模块时，我们会说旧模块有一些问题，此时我们需要列出它的问题。如果我想做一个新的尝试，可能是基于我现在的APP架构和模块，简而言之，不同的业务，不同的产品时期，或公司不同的情况导致你的目的有不同的优先事项，我们必须清楚地知道我们的目的是什么，做好产品的目标管理。此外，我们还需要了解我们产品的现状。现在我们都在谈论大数据和用户肖像。在产品的早期阶段，有几种用户在制作需求场景时被定义为A类和B类。A类必须有需求，但A类用户是什么样子的，这是当你以前做过的时候，你现在正在修改用户肖像是否已经改变，你必须确定；或者我的用户肖像已经改变了，我是否想重新整理我以前设计的场景，也就是如何使用它们。现在有些团队可能有用户肖像和用户标签，有些团队可能没有，当然，包括用户组和用户偏好的细分。这里为您提供一些方法，想要在线禅宗大师、酷技术、七麦数据等互联网产品分析网站将积累大量的数据和相关研究，如果公司没有这些用户数据可以考虑使用第三方平台提供服务，相互合作，完成早期准备。在整个设计过程中，我们应该提前梳理用户的行为，即用户吸引他的核心路径，在修改核心路径之前，用户打开主页，跳出页面，然后我改变功能模块，改变结构不影响核心路径，如果影响核心路径如何改变。最后一点是你需要找出你的核心流程和主流程。梳理一两个核心功能，判断上线后的数据是什么样子，或者把这个作为快速迭代的判断指标。一个统计数据是用户80%集中在核心流程上，另一个功能弱，也就是说你发现只有五六个人使用这些功能，所以修改在资源调度或者方向上非常重要，包括我们日常迭代的时候。如何关注关键功能是一个想法和参考。02成立车间将团队分为两个team，每个team完成四个任务(角色讨论20min，使命15min，设计原则20min，品牌特色25min)，然后汇报审核，共同讨论。02成立工作坊将团队分为两个team，每个team完成四个任务(角色讨论20min，使命15min，设计原则20min，品牌特色25min)，然后汇报审核，共同讨论。为什么要建工作坊？因为我们要和所有团队的人讨论大修改或者实施方向，我们怎么做这个工作坊？我们把我们的整个团队分成两部分。在这个时候，你选择人是非常重要的。当我们做出改变时，产品经理可能不是最接近用户的人。此时，我们应该打电话给运营市场的专员，或者我们在修改时有什么坑。如果你找到的team1和team2必须来自不同的部门，并且有不同的需求，这不是我的产品在综合修订时应该创造什么，而是击中了每个人的思维。我们之前说过，产品经理应该学会借力，这也是借力的方法。有了研讨会，第一个任务是角色讨论。在我们做了这么多的早期准备并定义了一般的方向之后，下一步是细分我们的用户，即用户是什么样的。从广义上讲，70后、80后或90后根据年龄和性别、经济状况、手机使用情况、行为状况不同，应建模用户决策，明确现阶段我们在做什么。另一个是项目的使命是什么。我们应该不断完善项目的使命，最终确定一个清晰简洁的项目使命。另一个是项目的使命是什么。我们应该不断完善项目的使命，最终确定一个清晰简洁的项目使命。例如，第一个任务是16个单词，然后慢慢减少，每次减少一半，直到不能减少，然后有一个明确的目标。第三个设计原则，包括UI和交互，可能会有更多的人参与。我们的设计原则是什么？希望实现什么？为什么要这样设置？由于产品设计中存在一些问题，他可能不敢说迭代过程中的时间，但他敢于在这个过程中表达自己的想法。另一个是品牌特点，这是解释我们如何做宣传，然后我的功能点可以差异化，一个是宣传差异化，另一个是现有的产品差异化，细化，是品牌特点，品牌特点有很多方面需要考虑，品牌不仅与我们的产品有关，还与我们的应用推广有关。有很多东西可以挖出来。修改时，不要局限于修改模块或设计，而是从全面的角度考虑我修改的目的。03Kickoff会议Kickoff会议可以确定项目周期，启动什么，然后第一个UI，包括产品原型，然后什么时候设计开发，我们需要多长时间，或项目跟进如何调动资源，必须有一个明确的项目周期。此外，改变后必须进行外部评估，因为改变后可能是设计风格审查，也可能是主要功能审查，可能关心用户不同，有些公司可能是团队测试，部门测试向老板报告，安排时间周期，因为每个决定，不同的人从不同的角度决定，将对项目周期和产品结果产生很大的影响，我们需要考虑所有这些因素。Kickoff会议结束后，重点是深入探索和输出。建议大家不要让自己的想法太分散，而是在关键的一两点上去做。Kickoff会议结束后，重点是深入探索和输出。建议你不要让你的想法太分散，而是在关键的一两点上去做。我们可能会改变一个新的，数据急剧下降，新用户无法保留，所以建议内容必须拆卸，找到一两条主线，因为现在的产品无法忍受很多麻烦。还有业务重点建议输出高保真原型，可以通过高保真原型尝试研究。04验证我们与用户进行高保真验证，相当于我们进行可行性测试。沟通需求、测试计划、用户招聘、撰写脚本、研究准备、预测测试、测试执行、撰写总结、撰写报告、宣传报告这是一般的内部流程和环节，用户筛选条件必须足够，是第一次不建议做新用户，可以做老用户、核心用户，除了主要路径流程高用户可以删除。一般来说，大修订将进行三轮。第一轮有一些核心销售人员。他们将在中期运行模拟器，并在后期推出产品。他们必须每次都这样做。第一次可能很难。我们应该找到合适的方法。在05快速实现和发布快速实现的阶段，我们将拆卸模块功能。如果发现新版本有问题，我们可以将功能放在旧版本中进行迭代。当我们做5.0和6.0的新事物时，6.0是一个大模块。此时，我们需要维护5.0和6.0。我将此拆解迭代到5.0，以查看一些用户对此功能的反馈，假如这是好的，就放在6.0上通过。我们将引入相关机制，这将降低您修改的风险。我们将引入相关机制，这将降低您修改的风险。此外，深入筛选您的目标渠道。事实上，包括百度、购物中心和商店在内的360用户肖像与豌豆荚用户肖像完全不同，尤其是oppo、vivo和小米有完全不同的用户肖像和用户群体，包括不同的消费水平。我们需要在发布时做出具体的考虑。另一件事是，在全面发布时必须有一个标准，至少产品质量，包括提供的服务，必须没有问题。所有发布的标准必须在内部定义，即内部策略和在线渠道，然后在发布时推给老用户或新用户。必须进行相关验证。此外，当新版本发布时，应建立一个快速和敏捷的机制。这种敏捷机制应该是做一些假设，可以快速修改，修改可以快速查看一些机制。因为在线可能经历了无数的个人功能模块调整之前，这导致我们的商业化低调整，用户偏好不同，所以在线可能会发现一些用户反馈特别差，快速改变这些，这也是通过我们的产品验证自己的方法，这必须是最重要的想法。07A/BTestA/BTest，随着我们体积的增加，我们使用A/BTest，A/BTest在中国一直在使用。A/BTest最有效的方法是在你的团队中发生争议时测试图标。你可能会觉得这个图标不好看。使用此机制后，您可以将其图标打成三份。虽然你清楚地知道它很丑，但分享率特别高。这是A/BTest在设计中非常有用的地方。还有产品的转化率，就是当我们从主页入口到滴滴订单的时候，我们在设计上可能会有差异，所以我们可以快速展示两三套A/BTest机制。最后总结一下大修改背后的一些注意事项:Timing:团队情况 产品属性时间周期，资源迭代模式，小步快跑A/BTest主线，迭代发布前不要分配太多预热准备危机意识的预防