产品开发

关于新产品开发流程的六个步骤你都知道几点，其实新产品开发通常来说都是遵循一个分阶段的流程，在流程中，公司构思新产品创意、然后研究、计划、设计、原型开发和测试，最后将其推向市场的过程，今天就来详细聊聊新产品开发流程的六个步骤！ 一、什么是新产品开发「NPD」流程？ 产品开发流程是指公司构思和实现新产品的整个活动，其中产品概念可能源自市场，也可能源自模糊前端的实验室或工作空间，通常，这些想法也包括来自客户的要求。 新产品开发通常遵循一个分阶段的流程，在流程中，公司构思新产品创意、然后研究、计划、设计、原型开发和测试，最后将其推向市场。 当 NPD 流程包含对现有产品的管理时，它也被称为产品生命周期流程。 使用敏捷方法，你可以减少步骤数量并充分利用瀑布式和敏捷式两种产品开发方法。 产品开发战略是企业战略与产品开发之间的桥梁，通过产品开发流程实现新产品并满足市场需求。 产品开发流程因公司而异，与行业、产品类型、产品是渐进式改进还是突破性创新，以及公司对产品的关注程度相关。 产品开发流程可以是敏捷的，被称为敏捷产品开发或混合开发。 二、新产品开发流程「NPD」 典型的瀑布式产品开发流程有六个步骤： 第 1 步：构思：创意产生； 第 2 步：产品定义； 第 3 步：原型设计； 第 4 步：详细设计； 第 5 步：验证/测试； 第六步：商业化。 1. 第 1 步：构思 新产品开发流程 NPD 的第一步，通常被称为“构思”，是新产品概念的起源。 通常这一步是为新产品进行想法筛选的结果，一般会涉及： 探索产品概念的创意； 业务分析； 进行市场研究； 并探索其技术和市场风险。 创意阶段通常是集思广益新产品的最重要步骤，因为它是大多数产品创意的来源——这为开发奠定了基础。 在早期阶段弄错产品概念会浪费时间并增加机会成本，当然，也并非所有新产品创意都来自内部。 构思步骤通常是最具挑战性的，可以使用产品开发清单来查明此阶段和整个开发过程中的风险，也是在这个阶段，提出了目标市场和目标客户。 2. 第 2 步：产品定义 有时会被称为“范围界定”或概念开发，此步骤涉及细化产品概念的定义，并确保团队真正了解客户需求。 设计团队在此阶段组建，该团队对新产品概念的技术、市场和业务方面进行了首次详细评估，并确定核心功能。 一般情况下，这个阶段可以通过设计简单的产品原型来获得有关产品市场契合度的早期反馈，具体情况可以根据产品类别决定。 如果这是一个增量产品，那么可以开始概念设计； 对于创新型产品，团队可能会考虑通过设计模型，以获取用户反馈； 产品类别对公司来说越新，就应该探索更多的概念测试； 产品设计的基本目标是确保这些想法是有效的，并且会让客户满意。 例如，如果你正在对现有应用程序进行渐进式改进，则可能无需进行概念契合阶段。 如果你现有的产品是成功的，那么你已经证明了概念以及产品/市场契合度，这样的项目可能只需要团队和管理层之间的一次核对，没有必要在不增加价值的情况下进行三次核对。 概念设计通常在这个阶段开始，设计团队可以开始可视化最终产品，并将其传达给潜在客户。 1）营销策略 探索和定义新产品的差异化关键点，如果操作不当，可能会增加产品上市时间或导致误判市场需求。 2）商业分析 需要查看类似产品，进行竞争分析，并开始制定分销策略。 这样做是为了确保公司的利润可以达到设定的阈值，市场策略还将指导广告和公关费用的预算，这同样会影响新产品的 ROI 计算，通常三年的损益计划是业务分析的一部分。 3）开发成本 作为业务分析的一部分，在了解产品定义后，团队可以在开发周期的这个阶段估算开发成本。 3. 第 3 步：原型设计 NPD 流程中的这一步要求团队制定详细的业务计划来证明公司对产品开发的投资是合理的，通常涉及深入的市场研究。 需要彻底探索新产品的竞争格局以及产品在其中的适合位置，同时还为新产品创建一个财务模型，对市场份额进行假设。 除了概念测试，定价也是在这一步确定的。 对于有形的新产品，例如，硬件或混合系统，还需要考虑新产品的可制造性，包括产品的采购。 在此阶段结束时，你应该清楚地了解你正在投资什么以及它将如何在市场上表现。 产品开发流程的第三步至关重要，因为它降低了新产品的市场风险。 因为具备可以向客户展示的原型，这也是你可以开始测试营销的阶段。由于创建逼真的用户界面相对容易，软件开发人员可以更早地进行这些测试。 4. 第 4 步：详细设计 在这个阶段，重点是产品设计，但也是对产品原型的改进。 在大多数情况下，这个阶段开始对原型进行 alpha 测试，通过与客户合作迭代产品（获取他们的反馈并将其整合到原型中）。 同时，营销、销售和制造开始创建发布和制造平台以支持新产品，新产品开发过程的第四步有时称为开发，有时还包含下一步的“验证/测试”。 这个阶段通常由项目经理领导，对于小公司一般由产品经理兼顾负责。 5….

SaaS产品迭代，我们往往过多的关注于技术性策略，抛开常规的产品迭代策略，我们在维持长久的产品生命力周期中，还应该关注哪些容易踩的坑呢？

编辑导语：作为一名设计师，开发前对产品的思索策划与开发中的实现过程往往会存在一定的偏差。那么，我们应该如何改进产品开发过程，减少自己和开发人员不必要的工作量，在产品开发中保证设计质量和体验呢？ 几年前，我曾在一个大型公司的项目中工作，主要是为他们重新设计旧有的应用。这简直是设计师一直梦寐以求的：有机会重塑全套 web 应用的未来用户体验，项目中发布的第一款应用将为其他产品打下基础。 我没有浪费时间，立即开始研究用户，了解现有软件程序，与产品所有者（我们的客户）和其他利益相关者合作，开始处理积压的需求。 几周后，我们对手头的挑战有了更好的理解，于是召集会议来讨论设计新产品。与此同时，直到我们验证了详细的需求，并且至少有了一个粗略的线框图之后，开发团队就可以开始搭建必要的基础架构。 几个月过去了，我们从草图到线框图，为关键的用户旅程勾勒出流程步骤，设计 UI 组件以及详细的规范，甚至有原型来演示我们想要的产品实现方式。 我们已经去客户那里测试设计，收到了很好的反馈，一切似乎都朝着正确的方向发展。 只有一个问题：我们至此还没有任何可以发布的产品，而我们设计的产品和我们能做出来的产品之间相差了十万八千里。 上述问题并不少见，我们一次又一次看到设计方案没有实现，或者与预期的设计和体验相去甚远。 这对于探索或概念验证一类的工作来说是很好的，但在快速发展的行业中，我们需要快速而频繁的发布产品，以保持在竞争中的领先地位。 在过去的几年里，为了改进产品开发过程，我调整了我的流程，并想分享一些关键的变化，希望这些变化也能帮助你和你的团队。 一、MVP：不止是说说而已 你可能听过无数次“我们需要一个 MVP（Minimum Viable Product，最小可行性产品）”，但这不应该只是一个流行词。 如果你完全理解如何实现一个可接受的 MVP，就可以帮助团队把精力集中在发布上。为了快速发布，团队必须愿意发布最基本的产品。 这对于客户和利益相关者来说是非常困难的，因为他们往往为所有特性和功能做预算，并预期最终得到功能齐全的产品。但是先发布 MVP 的好处是显而易见的。 你发布的速度越快，就能把产品越快投向用户，获得有价值的反馈，并给你带来意想不到的见解。而且，越早开始获取用户，你的用户群就越快开始增长；在几个月的用户增长之后，你就会领先了。 你需要接受的是，MVP 可能没有那么快的竞争力，但也不需要立即进行大规模营销。关键是尽快发布，为持续的增量改进铺平道路，从而为用户提供不断增长的价值。 Slack 是一个很好的例子，它依赖于用户的反馈来帮助塑造产品。在没有首席营销官（CMO）和大众营销活动的情况下，他们通过倾听用户意见，逐步改进产品，赢得了用户的心。 二、打破幻想 作为设计创意人员个人，我们常常希望独立工作，很少考虑我们无法控制的事情。 我们关心的是交付的成果，只要它们有效并且看起来很棒，我们就完成了工作。如果最终发布的产品看起来或感觉不像我们的设计，那不是我们的错，对吧？ 事实上，人类是情感动物，视觉刺激更能说明问题。酷炫的界面更能让客户惊叹，并留下持久的印象。 作为创造者，我们也从别人的意见中得到反馈，从而在视觉方面做得更好。然而，如果忽略高保真的模型和原型，仅仅把发布产品的实际使用效果归功于设计，而不是一些令人惊叹的个人作品，我们还能做好这种设计工作吗？ 我并不是建议停止做那些美妙的，像素完美的工作。我追求完美的强迫症源于 800 × 600 的显示屏时代，在那个时候，最终产品就已经应该是完美的。 正如 Salesforce 设计团队所说： “以体贴优雅的工艺，表现对人们时间和注意力的尊重Demonstrate respect for people’s time and attention through thoughtful and elegant craftsmanship” 高保真的设计还可以让我们测试一个真实的产品，验证我们的假设，并确认可用性。但重要的是，我们不会浪费时间来创建一个能给客户留下深刻印象，但却不能实现的产品。 相反，关注一个现实的、可用的产品。 三、找到正确的节奏 为了减少不必要的工作量，我们需要了解产品开发中发生的所有事情。 路线图、待办事项列表、下一步计划开发的功能，以及开发人员在每个阶段积极工作的内容。只是坐在外面，你就希望展现出团队合作，以为你已经做完了，产品接着自然就会实现，这是没有意义的。 对于一个产品团队来说，将设计视为事后的考虑，或把它完全排除在外是很容易的，而且并不少见；作为设计师，我们希望创造性解决问题，利用我们的经验和获得的反馈来验证正确的解决方案，我们不希望被告知“让它好看就行”。 了解每一件正在发生的事情，并确保设计是产品开发和发布周期中不可或缺的一部分，这不仅会帮助你的设计看到曙光，还会让团队的其他成员参与进来，这就引出了我的下一个观点。 四、分享所有权 如果你足够幸运，能在产品刚推出的时候就参与进来，请确保你作为设计师的想法能让每个人都了解。这将帮助团队有归属感，并给他们提供贡献的机会。 没有人希望别人告诉你该做什么，所以分享你的想法，并利用你的专业知识和经验来推进贡献。团队会更希望交付一个集体的想法，这也将有助于每个人都保持一致。 你还会发现，当每个人都达成一致并向相同的目标努力时，团队的士气会高涨。 五、关于代码工作 多年来，设计人员是否应该编写代码一直是一个热门话题。 作为一个 UI 开发人员和 UI 设计人员，我可能有点偏见。我知道这是一种奢侈，学习如何编写代码需要花费大量时间，但好处显而易见。 对我来说，编程能力给了我在代码工作中表达想法的自由。 有时候不需要提交代码，或者代码水平粗糙而混乱，但这仍然锻炼了个人经验，对产品实现逻辑有了深层理解，使后期减少对错误的解释次数，以及由于不熟悉而试图重新设计的时间。 如果设计人员不愿意或者不能编写代码，他们至少应该了解代码和平台的基本原理。建筑师在设计房子时，不会不考虑材料和周围环境。 这对你优化工作什么帮助？应该是显而易见的。具备相关的代码能力将减少编程所需的工作。如果你了解开发产品的平台或框架，就能够在它们的约束下进行设计。 表单组件有按列过滤功能吗？select 组件可以获取数据吗？还是所有选项都是预加载的？如果组件 X 与组件 Y 提供相同的用户值，那么哪个更容易实现？ 一套可重用的组件可以节省大量时间，因此你对这些组件了解得越多，就越清楚如何定制它们来满足需求。 你的设计离技术上可行的距离越远，你就会浪费更多的精力来纠正它，开发人员也会浪费更多的精力来满足你的设计要求和客户的期望。 除此之外，在过去的几年里，我们设计和开发产品的方式发生了巨大的变化，动态设计规范、组件模式库和新的设计工具使我们比以往任何时候都更有效率。 更好的技术知识，让你现在可以真正提高团队的操作效率，这是以前无法做到的，你还在等什么？ 六、总结 总而言之，如果你想优化工作流程、想更有效的发布产品，那么遵循以下建议，你和你的开发人员都会减少不必要的工作量： 1. 理解向最终用户交付产品价值所需要的最低限度（MVP）…

本文总结了设计产品前需要询问客户的20个基本问题，问清楚这些问题，能够帮你有效明确客户需求并保证设计的时候按正确方向行进。 要想设计一个成功的产品，首先需要了解清楚客户的需求。产品设计之前，通过正确地询问客户一些问题可以更顺利地完成设计，避免不必要的返工。更容易获得客户对设计成果的肯定。时刻记住：尽早建立融洽的关系，以及给于对方尊重对于合作至关重要。 以下是设计产品之前需要咨询客户的20个基本问题。这些问题不仅可以让客户觉得自己参与了设计过程，还可以帮助你快速清理项目背景，并按照正确的方向进行设计。 一、建立共识 首先要让客户知道你非常在意他们这个设计项目。站在他们的角度，理解他们寻求设计解决方案的原因，并建立共识。询问以下这些问题将帮助你了解他们所面临的问题，并通过这些信息思考如何提供出最好的设计解决方案。 1. “这个产品背后的灵感是什么?” 从这个问题的回复中，你可以了解到客户想做的是复制品还是与众不同的新产品。探寻客户项目背后的灵感可以让你清晰地认识到客户想和你合作的原因，以及你应该如何开始设计这个项目。 2. “你想要实现什么效果?” 根据客户需要实现的效果设定分段目标，这样可以帮助你跟踪项目进度，自查设计是否符合效果。同时，当你清楚不同时间段设计应该完成到什么程度时，你就能合理安排时间来完善设计效果了。 3. “你的项目期望是什么?” 通过询问这个问题，不仅会让客户觉得你是一位专业设计师；同时，也可以帮你杜绝一些不必要的麻烦。如果你了解“范围蔓延”这个现象，那么你就知道在设计前关注这个问题是多么重要。 （“范围蔓延”指项目范围没有很好的控制,项目工作范围超出了项目立项时的范围。） 二、了解客户品牌 了解客户的业务和品牌可以帮助你清楚他们的想法。当你开始设计时，他们的一些想法和情感正是你在设计中需要参考的。因此，以下这些问题也是非常重要的。 4. “你们的立场是什么?” 这个问题可以帮助你了解驱动客户业务的核心价值观。清楚客户的立场有助于尊重他们的信仰，避免不必要的错误。一些设计项目也可能包含文化或政治角度，这些价值观可能需要成为设计的一个明确部分。 5. “贵公司的优势是什么?” 通过了解客户的优势，有利于突出客户独特的卖点。你还可以通过这些信息来激发总体的设计思想。 6. “你的主要竞争对手是谁?” 了解客户的主要竞争对手，可以帮助你了解客户所在的行业。你会发现一些行业反复出现的元素和策略可能对你的设计项目有效，并有机会使其脱颖而出。 7. “你是否喜欢你们之前的品牌?” 请客户提供之前的行销材料，确保你的设计与他们现有的行销材料相一致。如果客户有过去的设计样本，你可以从中提取有效内容用于设计，尤其是当接到重塑品牌的设计项目时。 三、定义受众 设计前一定要了解客户的受众群体，从人口统计学(年龄、性别、民族等)和心理统计学(个性)两方面了解受众特征。 8. “你的目标受众是谁?” 从心理统计学开始分析，请客户准确地描述他们的理想受众，包括他们会做什么，他们怎么做，他们喜欢什么等等。当你设计的时候，可以根据目标受众的特征使用一些元素来引起他们的思维共鸣。 9. “受众是女性、男性还是中性?” 某些品牌可能会利用传统的性别期望来吸引特定的受众，你需要了解客户目标受众的性别。如果客户告诉你，他们受众在性别上涉及比较广泛；那么你可以在设计中加入更多的中性元素。 10. “产品针对的是哪个年龄段?” 在设计中你应该知道，不同的年龄段对不同的事物有不同的期待和反应。根据受众的年龄段，你需要考虑如使用颜色、形状、排版和风格才能更符合他们的胃口。以及应用这些元素是会产生共鸣还是会失败? 11. “你的受众在文化上有什么顾虑吗?” 某些设计元素在其他文化中可能是不合适的或不被认可的。通过提出这个问题可以避免踩雷，帮助你确保设计中的元素能被受众群体所接受。 四、设定预期 有些客户倾向于关注他们的需求，而忘记了产品的细节。如果你听客户说过类似这样的话，“我想要一个独特的、吸引用户的设计，来展示我的产品有多酷，这样我就可以增加销量了。”你就能完全明白我这句话的意思。​ 因此，设计之前需要通过问客户一些问题来设定他们的期望。你可以赞扬或“认可”客户的想法，也可以委婉地告诉他们这个计划行不通。(例如“抱歉，我认为我们不能把所有200名客人的名字都放在你们的请柬设计上。”) 12. “你想要什么样的风格?” 通过假设客户可能是设计专家来确定他们在设计美学方面的品味。但你不能这样去问他们，“你想要包括等距插图或一些不对称的布局吗?” 过于专业和生硬的问题可能让人费解。 你可以问得通俗一点，“你想要一个稳重、干净的产品外观，还是更具挑战性和动态性的产品外观?” 这个问题将帮助你尽快确认产品风格。 13. “你的设计需要哪些必备元素?” 确认你的客户是否有怪癖或独特的要求。询问这个问题可以确保不会忽略任何对设计至关重要的文本、图像或主题。(PS：我之前有一个在时尚界工作的客户，他就希望在设计中看到一些闪闪发光的东西。) 五、了解更多细节 通常情况下，客户会将你的设计以印刷或数字影像的形式用于营销活动、在线广告、博客、出版等。因此，了解更多关于最终产品的细节信息，可以帮助指导你的设计。 14. “你会在哪里使用这个设计?” 请客户告诉你成品的规格、位置和尺寸；并咨询客户将在哪里使用这个设计。了解这些信息后，对于打印或数字化，手持或大比例尺寸应用应该如何设计，你将会有不同的设计考虑因素。 15. “你将如何分配或使用产品?” 对于印刷设计，通过咨询印刷规范来帮助你设计。根据生产技术，你可能需要限制你的颜色，或者也有可能需要在设计中添加更多的图层。如果是数字化设计，你将需要准备另外一种设计标准。 六、确认合作模式 为了合作的顺利进行，一般需要先跟客户沟通，了解他们希望如何合作。你也有机会表达你能为客户做什么，不能做什么。最后，根据双方的意见，设置合作模式。​ 16. “你更喜欢怎样沟通?” 有些客户更喜欢不断地收到更新信息，而有些客户则会给你时间“做自己的事”。“了解你们客户喜欢的工作交流方式，将有助于你更专注于你的工作或预见干扰。通过这种方式，你可以安排设计任务并准备更新信息提供给客户。 17. “你愿意在这个项目上花多少钱?” 咨询客户的预算，同时也让客户清楚你的基本收费是多少。如果每一次修订都需要另外收费，无论是按小时计算还是按修订轮次收费，请给出收费标准。这样可以避免最后结算时，产生不避免的纠纷。 18. “你想如何进行设计反馈?” 根据这个问题来确定你更新设计版本和向客户反馈的频率。有些客户喜欢和设计师来来回回地交流，也有些客户喜欢采取不干涉的方式。咨询并考虑好反馈方式，可以帮助你避免浪费时间和精力。 19. “你需要什么文件和格式?” 这个问题让客户清楚地知道他们可以接收和处理的文件。再者，这也有助于你预测可以使用什么类型的设计资源（如字体和图像）。 20.“这个设计需要什么时间交付?” 这个问题有助于确定你是否有足够的时间来完成设计和其他任务。记得给自己预留一些修改的时间，因为设计中可能会遇到一些突发情况。 伟大的设计始于小小的问题 请记住，客户需要的不只是有吸引力的设计。他们还希望有专业的建议、耐心和理解，外加一点关心和认可。通过咨询客户正确的问题，建立共同点，了解他们的需求，你就可以更好地做出令客户满意的设计，提供对方一个愉快的合作体验，并可能在未来获得再次合作的机会。 原文作者：Guest Blogger 原文地址：https://99designs.com/blog/tips/questions-to-ask-your-client/

本文作者从工作实践出发，根据团队中的实际情况总结了新人产品经理容易遇到的几点问题，适合0~2年的产品经理阅读。 新人容易遇到的问题，今天先谈三类： 不开口提问 多任务并行有问题 做项目，先画原型图 01 不开口提问 有的新人，有一种心态：怕自己初来乍到，懂得不多，不满足大家的预期。 所以看到不明白的信息，或者自己项目进行中的问题，宁愿装作知道，也不会开口提问。 这是错误的。 新人首先要有一个意识：暴露自己的无知并不是坏事。 因为在这样一个快速发展的行业，任何人都要有长期学习、拥抱变化的觉悟，每个人都可以说是无知的。 另一方面，对于新人，团队也会留足够的时间来培养。产品经理团队，绝对可以接纳一个好奇宝宝。 但对于一个从不提问的新人，会认为没有存在感而逐渐忽略，因此无法给予针对性的帮助，这对于新人的发展是不利的。 所以，如果你是新人，记得要把你看不懂的、听不懂的，自己查了资料、思考了也没整明白的事情，在合适的时间，咨询合适的人吧。 02 多任务并行有问题，捡芝麻丢西瓜，或者，连芝麻也没捡 产品经理本身是信息处理的中枢，每天大量的信息输入和沟通输出。 所以，很多产品经理都会吐槽：一天基本没干什么正事，就过去了。 另外，手头的工作多了，也容易有遗漏，被领导提醒才想起来做。 这就产生了“瞎忙”——累了一天，却老是捡芝麻丢西瓜，或者，连芝麻也没捡。 其实，这是缺乏时间管理能力导致的。 时间管理能力，是在职业生涯早期就需要提升的能力，它能帮你在多任务并行中，分配足够精力给重要的工作，且不遗漏任何一项待办事项。 时间管理，有很多理论，比如番茄钟、重要&紧急四象限法则；也有很多工具，比如各类清单类APP、云笔记APP、番茄钟APP等等。 用哪个其实都可以，因为工具和理论并不重要——一个纸质清单，一个便利贴，一个wiki文档，一个excel表格，都可以用来做时间管理。 更要紧的是：新人得有这个意识，先行动起来，养成随手记录，定时复盘的习惯，并逐渐完善自己的时间管理方法。 工作七年多的我，是这么做时间管理的。我建立了不同用途的清单： 短期清单：今日工作事项；本周工作事项；会议安排…… 长期清单：总需求池； 分版本需求池；团队成员长短板和case…… 在打仗一般的工作日，我会每天拿着这些清单，复盘两次： 最重要的工作今天是否如期开展了？ 工作事项是否有遗漏? 是否有优先级的变化? 有什么风险？ 需要告知哪些人？ 所以，我不容易遗漏事情，也能够为团队成员兜底。 在工具方面，早些年，我还会下载各类APP使用，对比其体验。后来发现，还是朴素的纸笔、wiki上的表格、桌面上的电子便利贴，这几个最常用。 因为我的清单，是给我自己看的；清单本身也只是满足阶段性的需求，不需要多么华丽的格式和多么先进的功能，用起来简单方便就好。 关键是，要有时间管理的理念根植心中。 03 做项目目，先画原型图 小A被老大安排了一个项目，对现有的某个功能进行完善。 小A略加思索，并参考了一些竞品后，就开始画原型图，美滋滋。做完后提交给领导，却被发现，遗漏了一个重要分支。 更沮丧的是，被指导之后发现，原来连原型图都不用画，其他方案，也可以解决问题…… 以上是新人提交产出时，时常出现的窘境，不仅浪费了时间，还不能拿到好的结果。 解法很简单，所有的项目，都需要按照目标-框架-内容的思路来进行梳理——先整树干树枝、再添树叶。（其实和《金字塔原理》说的又是一回事了） 没有想明白目标，没有梳理整体解决方案框架之前，千万不要做任何具体的原型示意图、需求描述文本。 在这里列举下我常用的方案设计步骤，供参考： 明确此次项目的目标、确认效果评估的方案； 梳理方案的框架（有很多种梳理框架的方法，比如按照目标拆解对应的功能点、按照用户视角梳理整体流程、按照前后台各服务的交互梳理时序图等）； 与产品同事、研发同事小范围交流上述1、2项是否合理； 画原型图、写需求描述文档。 每次都按照这样的方法做，相信你不仅能提升效率，还能加深自己的深度思考能力。 作者：然阿姨，微信公号：然阿姨的产品课，曾就职于鹅厂、搜狗、瓜子等公司，迄今8年互联网产品经理生涯。一起探讨职场、生活和读书吧。

不要为梦想而创业，要为满足用户需求而创业。

在本文中，我们收集了2020年用于网页设计、图形设计和数字插图的一些最流行的色彩组合。 黑色和黄色 霓虹黄和黑色是一种非常时尚的组合，颜色组合的成功是因为它能简单地抓住用户的注意力。 经典的黑白两色搭配辅以叛逆的黄色，让这一组合呈现出令人惊异的前卫造型。 蓝色和红色 非常经典和优雅的配色，为许多图形设计和插图提供了完美的配色方案。 作为两种原色（黄色是第三种），蓝色和红色形成对比，且以纯色或令人愉快的渐变的形式彼此完美地互补，在中间融变成紫色。 紫色和珊瑚色 一种非常现代的颜色组合，以敏感和神秘的魅力。 把这个组合的颜色命名为紫外线和盛开的大丽花（珊瑚色），现在已经很受欢迎了。我们可以从插图、网页设计、平面设计和移动APP设计上看到它。 黑色和白色 最流行的颜色组合：黑色和白色。它在手工艺术品、插图、图形和网页设计、印刷设计等方面显得很优雅和雅致，它与极简主义的视觉趋势有着完美的关系。 灰色和充满活力的绿色 一种非常充满活力的色彩组合，特别是在网页设计中非常流行，通常将这种颜色组合视为高科技，这对于应用程序设计也很常见。 珊瑚色和蓝绿色 一组对比鲜明的色彩组合，在所有类型的数字艺术设计（插图，图形和Web构图）上看起来都非常令人愉悦。两种颜色本身看起来都令人赞叹，当它们组合在一起时，它们的效果会进一步增强。考虑到“活珊瑚”是今年的颜色，这种组合现在很受欢迎。 黑色和橙色 类似与黑色和黄色，黑色和橙色是一种乐观和充满活力的色彩组合。清新的黄色吸引人的感觉。结合经典的黑白配色方案，设计师可以创造出和谐的构图，给人以创新和创意的印象。 蓝色和橙色 蓝色和橙色在色轮上放置正好相反，这有助于它们在设计中使用时获得完美的对比度。流行的色彩组合在传递信任和乐观的同时，也使得它在网站设计和数字艺术中非常受欢迎。 作者：By Lyudmil Enchev 原文链接：https://graphicmama.com/blog/the-best-color-combinations-to-try-in-2020/ 译者：Tzw_n，公众号「小阿田的设计笔记」

本文作者复盘了一次后台体验优化项目，还原其中七个阶段，分享由这次项目而来的经验与心得，供大家参考和学习。 后台产品的用户场景、任务往往复杂而琐碎。在进行产品/交互设计时，是否有方法可以让我们更系统性地去思考，从而去满足用户在各项场景、任务中的诉求呢？ “设计赋能”、“设计推动”是设计团队在工作中常常会接到的任务，是否有什么沟通或推动技巧能让业务方更好的接受自己的观点和方案呢？ 本文将结合一次由设计团队赋能的后台体验优化项目，还原整个项目的七个阶段，为大家分享关于上述两点的一些经验。 一、改版业务目标制定 首先，简单介绍一下业务背景。本次优化，主要针对的是酷家乐“到店购”业务的报备单管理后台。 关于“报备单”，大家可以近似理解为“商机线索”；我们后台的主要用户——品牌商，需要对这些商机线索进行审核、分配到各地门店跟进；“线索”成交后再进行奖励金的结算……整个后台的链路较长，功能操作点也很多。 由于此后台的初期搭建并没有交互&视觉团队的介入，后台的整体产品体验不够细致，在长时间收到来自用户、运营、平台等各方面问题反馈后，业务团队决定从体验角度进行一次优化改版。 综合各方面的反馈，我们和业务方讨论定下本次优化的初步目标： 二、基于“交互五要素”的问题发现思路推导 接下来，便开始进行前期的分析工作了。 我们一接手，便立刻通过体验的走查，发现后台页面存在诸多问题： 问题很多，但解决了这些问题是否能够真正满足业务的各项用户诉求呢？ 前期的问题，都是由我们作为设计师的经验和习惯得出，用户又是否和我们想的是一样的呢？ 看来需要回归到用户的视角，去分析他们实际的任务和场景，再重新思考产品的问题与方向。 这时，我们想到了传统的交互设计方法——交互五要素：以场景、用户、媒介、行为、目标来概括人与系统的交互过程，即“在某个场景下，用户通过一定的媒介及行为，达到自己的目标”。 那么也就是说，我们可以把一整套业务拆分成一个个小的业务场景，去研究每个场景下的用户诉求、痛点；再把每一个场景串联整合起来，便是我们整个业务的用户诉求和痛点了。 由此，我们归纳出用户诉求、产品问题的拆分及整合顺序： 三、结合“双钻模型”的问题发现-解决总思路制定 在发现问题之后，还需要对问题进行处理和解决，这里我们选用的是常用的“问题聚焦-解决方式拆解”的双钻模型。 最后，综合两大阶段的思路，也便形成了本次改版的整体思路： 四、用户诉求调研与整合 接下来，我们便按照这样的思路展开具体的分析与设计工作。 与业务团队合作，通过定性/定量的方式，我们收集到了较为丰富的用户场景、目标、行为等信息： 再利用大家都很熟悉的工具“用户体验地图”，将所有用户的所有场景、目标、行为汇聚形成一张完整的体验大图，形式如下： 在每个场景下，我们提取各类用户的共性诉求（即表格中相近的内容）、核心用户（在本业务中为“小公司客户”）诉求，归纳得到每个场景下的主要用户诉求/行为： 五、产品问题发现与整合 将每个场景下的用户诉求，与产品现状进行对比。那么，我们的产品现状中没能满足用户诉求的地方，便是产品存在的问题了： 而得到的问题，其实还是较为零散和发散。我们便需要利用双钻模型对问题进行聚焦，也就是对同类问题进行归类、发现零散问题背后的本质问题。 这里我们和业务方进行了2次共创会议，对问题的归类和聚焦进行讨论，最终得到五大核心问题： 六、改版方向确定与拆分 再结合之前定义的改版目标、解决成本，确定了本期需要优先解决的问题： 从而也便得到了改版的方向和策略： 将三个策略方向进一步拆分成小的方向点，分配到每个用户场景中。这样做的目的，一方面是将他们与之前分析得出的细节问题进行匹配，同时也可以在各个场景中发现新的改进机会点，从而确保优化点可以对全部场景进行完整、全面的覆盖。 与业务方进行讨论，将每一个优化点转化为产品的功能点，并进行产品需求的立项评审。 七、交互与视觉设计 最后，也就是我们熟悉的交互、视觉设计环节了。 基于改版方向和拆分方向，我们最终的设计方案对业务流程、界面设计进行了优化： 以上便是完整的“问题发现-问题解决”的过程了，其实实际的交互/视觉设计用时还是很短的，主要精力都集中在前期机会点的推导与分析。 虽然相比单纯的承接需求，我们耗费了更多的时间，但这样一个过程未尝不是对我们思考分析能力的一种考验和提升。 八、关于“如何更好地推动赋能”的思考 而在实际与业务方合作的过程中，我们其实也遇到了“业务方向不明确”、“业务方听我们的观点一头雾水，难以理解和接受”等平时常见的沟通协作上的问题。通过这次项目实践，我们也总结沉淀下来了一种可能实用的解决上述问题的思路： UED的优势和专业在于，可以站在用户的角度，为用户发声并让产品更关注用户的体验。因此，我们在与业务团队交流时，也可以以“用户”作为我们的支撑，去引导业务方和我们一起聚焦在用户的诉求和痛点上，让对方意识到我们彼此所做的事都是为了帮用户解决问题，而不是UED单方面的强势输出。或许这样他们能更容易理解、接受我们的想法或提案，和我们站在一边。 比如，我们在与业务方沟通产品问题时，业务方开始并不理解我们这些问题从何而来，我们便基于用户体验地图为他们描述问题的发现过程，并说明所有的优化建议或者问题点并不是我们自己臆想的，而是真实收集到的用户行为和目标。他们在理解了我们这一意图之后，也便非常积极主动地参与到和我们的讨论之中了。 以上便是我们在整个项目后的一点总结和心得。 针对不同的业务诉求及问题，选取合适的方法去应对，是对设计师的思辨能力的考验。而反推或引导业务方接受我们的想法，则需要更多沟通协作的“软技能”储备。 希望我们都可以在这个过程中不断学习和成长，有所收获。 作者：白羽，公众号：酷家乐用户体验设计

人的脑容量是有限的，面对复杂的产品设计可能就会出现逻辑混乱的问题。此时，信息结构图就是一个有力的助手，可以最大程度避免这种情况。 上一篇文章，介绍了什么是功能结构图、绘制功能结构图有什么好处，以及如何绘制功能结构图。 有同学对功能结构图和信息结构图的区别产生了疑问，这篇文章，单独对信息结构图做详细的介绍。 一、什么是信息结构图？ 我们每天都在接收和处理信息。 打开微信聊天列表，好友头像是信息、好友备注名是信息、最近联系时间是信息、最后一天聊天记录是信息。 进入聊天详情页面，好友备注名是信息、好友头像是信息、自己的头像是信息、每一条聊天记录是信息、聊天记录的类型也是信息。 信息是有结构的。 大部分公司都会为员工建立员工档案，员工档案信息一般包括姓名、性别、名族、籍贯、出生年月、身份证号码、所属部门、所在岗位、入职时间、转正时间、合同到期时间、工作单位、工作时间、职位、收入情况、离职原因、毕业院校、学习时间、所学专业、获得证书等信息。 这么多信息，看着就觉得很累。 于是，我们将这些信息进行分组： 基本信息（姓名、性别、名族、籍贯、出生年月、身份证号码）； 入职信息（所属部门、所在岗位、入职时间、转正时间、合同到期时间）； 工作经历（工作单位、工作时间、职位、收入情况、离职原因）； 教育经历（毕业院校、学习时间、所学专业、获得证书）。 分组后的员工档案，相对更清晰、更有条理。 为了清楚地描述一个对象，把信息按一定的逻辑，组合到一起，就构成了这个对象的信息结构图。 二、信息结构图有什么特点？ 1. 功能原材料的说明书 狭义上看，功能存在的目的，是满足用户需求。而“功能”的实现，是需要有“信息”这个基础的——有信息的存在，才能对这个信息进行操作，才能有功能。 发送好友名片是一个功能，这个功能的存在是为了满足用户推荐好友的需求。从用户的视角来看，是把一个好友的名片发送给了另一个好友。但本质上，是把一个好友的信息，发送给了另一个好友，发送好友名片功能的实现，依赖于好友名片信息。 正如同“巧妇难为无米之炊”。“炊”是功能，“米”是信息。有米，才能炊。 大部分时候，我们更直观关注到的是功能，而不是信息。因为功能是按照我们的心智模型设计的，我们使用产品，往小了说，实际上是在使用功能，而不是在直接使用信息。 信息往往被隐藏在功能的背后。 我把好友名片发送给我的朋友，我并不关心我具体发送了哪些信息，我只关心我有没有发出去。同样的，我的朋友收到名片后，并不关心名片里有哪些内容，他会去添加好友，然后开始对话——好友名片信息，就这么被隐藏起来。 用户的感知上，他只使用了功能，却对功能背后的信息无感。 有了信息，我们才可以对应地设计出很多的页面和功能。 有了好友名片信息，微信设计了发送好友功能、编辑好友名片功能、通讯录功能等等。 信息结构图，是功能的数据抽象，是功能原材料的说明书。 2. 与页面和交互没有关联 有些产品搞混了信息结构图和功能结构图的区别，在绘制信息结构图时，按照页面和交互来绘制。每个页面是一个对象、页面中的功能模块或交互是一个子对象。 看起来有信息、有结构，但其实并不是信息结构图。 信息结构图，其实跟页面和交互是没有关联的。 我们在设计页面或交互时，为了更好地实现业务流程、更方便用户理解，往往会在多个页面或多个地方显示同一个信息。 以我们最常使用的微信为例，微信好友名片信息，包含了多个字段：头像、备注名、昵称、微信号、地区、电话号码、标签、描述（文字描述、图片描述）、个性签名、来源、是否星标、朋友圈和视频动态可见状态、是否黑名单。 这些字段分别出现在多个页面，且在多个功能中有使用到： 1）通讯录列表中，显示了头像、备注名、昵称 2）名片详情页中，显示了头像、备注名、昵称、微信号、地区、电话号码、标签、描述（文字描述、图片描述）、是否星标、朋友圈和视频动态可见状态 3）社交资料中，显示了个性签名、来源 4）设置备注和标签功能中，使用了备注名、标签、电话号码、描述（文字描述、图片描述） 5）资料设置中，使用了是否星标、朋友圈和视频动态可见状态 6）对话记录的名片推荐卡片中，显示了头像、昵称、微信号 很多个功能，都使用了好友名片中的信息，但这些信息其实都是对同一个对象的描述，他们就是同一个信息。 通讯录列表中显示的备注名，和其他页面显示的备注名，没有任何差异。同样的，对话记录的名片推荐卡片中的微信号，跟名片详情页中的微信号，也是一样的。 信息结构图是用来描述对象本身的，不是用来记录“描述这个对象的信息”在哪些页面、哪些交互中被使用到的。 信息结构图是脱离于功能、页面、交互的，与页面和交互没有关联。同一个信息，不同功能的很多个页面、功能模块都可能需要用到。 三、为什么要绘制信息结构图？ 1. 梳理信息构成，高效绘制原型 人的脑容量是有限的。 科学研究表明：人类短时记忆容量是7±2个组块。一旦超过一定数量的信息，要想记下来，就需要花费一定时间、运用一定的方法，刻意记忆才能记下来。 当我们要设计一个比较简单的功能时，我们可以很轻松地完成方案设计，且不会出现信息遗漏、混乱。因为我们的脑容量足以支持，让我们短时间内记住这个功能所包含的信息。 但如果是一个很复杂的功能呢？ 复杂的功能，往往有很多个从功能中抽象出来的对象，而且描述对象的信息往往也是比较丰富的。在脑容量有限的条件下，如果我们仅凭着记忆，一个页面一个页面地画原型，最后很可能会出现信息遗漏和混乱，做出来的产品方案自然漏洞百出。 而有了信息结构图，在设计具体的页面、交互、功能时，我们只需要对照着功能结构图和信息结构图，通过对用户使用场景的分析，从信息结构图中，选择每个页面和交互需要使用的信息，并完成详细的原型设计，即可高效、逻辑清晰、无遗漏地完成产品方案设计。 如果要设计一个简单的订单评价功能，设计评价功能的信息结构图如下： 在进入提交评价内容页面前，被评价的订单id和评价用户id是明确的，评价时间自动取提交评价的时间，其他的信息，需要用户主动填写，并提交到服务器；所以，提交评价内容页面需要用到总体评分、服务质量评分、服务态度评分、服务速度评分、评价内容这几个信息； 评价成功页面需要简单显示评价内容最重要的信息，所有只需要用到总体评分和评价内容； 产品经理从用户体验的角度，还会在页面上增加一些信息结构图没有的信息，如操作成功提示文案、引导文案，使得整个页面的内容更容易被用户理解、更有效地承载业务的发展。 2. 设计数据表结构的参考 产品的视角和开发的视角是有差异的。 产品更关注需求、功能、交互、体验。 落实到产品方案上，一个功能的流程是怎么样的、有哪些页面、每个页面分了哪些模块、每个模块有哪些信息字段…… 开发更关注方案的实现方式。 落实到技术方案上，要实现这个功能，需要设计一个什么样的技术架构、有哪些数据表、有哪些接口、接口调用方式是什么、性能如何保证、服务如何解耦、如何预留可能的后期扩展…… 开发在拿到一份没有信息结构图的复杂产品方案后，需要在充分消化产品方案后；自己从功能、页面、交互中抽象出若干个“对象”，再将对象涉及到的信息字段穷举出来；最后再根据数据表设计的要求，加上一些特有的字段，完成数据表的设计。 如果产品经理能替开发多想一步，直接把功能包含的“对象”抽象出来，并完成信息字段的穷举，这对开发理解产品方案、设计数据表结构会是一个很重要的参考依据。 四、如何绘制信息结构图？ 功能结构图重点考察的是产品经理对业务理解和流程拆解的能力，而信息结构图则更多地考察产品经理的抽象归纳能力，这也是产品经理最基本的技能。 1. 分析并抽象信息主体 信息结构图是描述一个对象的。 要绘制信息结构图，就必须要先找到要描述的对象——这个对象，就是信息主体。 当我们去商店购物的时候，一瓶500ML的娃哈哈饮用水是一个主体、一盒益达口香糖也是一个主体。 从信息的角度来看，这瓶水和这盒口香糖，都是一个信息主体。 一个功能中，可能只有一个信息主体，也可能会有多个信息主体。这些信息主体，是构成这个功能的零件。 如果要给公司的行政部门做一个简单的图书管理功能，要求满足图书详情查阅、图书检索、作者信息查阅和检索、出版社信息查阅和检索功能、借阅申请功能，就可以抽象出书、作者、出版社、借阅记录4个信息主体。 它们是信息结构图需要描述的对象。 2. 梳理信息字段 确定了描述对象，接下来就要梳理出用于描述这个对象的信息字段。 很多产品经理在梳理信息字段时，从既有的生活和工作经验出发，将自己能想得到的信息字段全部列入信息结构图中。最后发现在设计原型图时，很多的信息字段用不上，同时也有很多需要用的信息字段又是缺失的。 这是因为产品经理在梳理信息字段时，没有考虑到业务和功能的实际需要。 不是所有的信息字段都要绘制到信息结构图中。是否要被抽象为信息字段，取决于业务和功能是否需要它们，取决于它们对业务和功能的设计或未来的发展是否有价值。 如果有价值，即使现在用不上也可以提前规划好；反过来，如果没有价值，就暂时不需要考虑。 描述一本书，可以有很多的信息字段。如果穷举一下，就会得到这些信息字段：书名、出版社、作者、ISBN、版次、包装方式、所属丛书、开本、出版时间、用纸类型、价格、重量、正文语种、页数、所在书架等等。 但我们仅仅是给行政部门做一个图书管理功能，需要满足的需求也不多，且相对简单：…

中台的概念到处都是，笔者所在的公司玩出了一个“伪中台”，针对这个伪中台，笔者该如何进行产品设计呢？ 愿景： 在笔者的产品工作中经理的一些比较有意思的坑，分享出来，可以给大家一点思考，一点启发。 目标人群：产品人&年龄<2岁 idea：分享一些实际的产品设计案例 竞争对手：个人兴趣、时间、惰性 预计耗时：阅读本文预计耗时7分钟 写在前面的话： 其实随着做产品的不断深入，我们都会遇到各种各样的坑。比如同事的不靠谱、领导的错误抉择又或者是鸡肋的产品架构或者不清晰的产品定位，这些都可能会导致我们在进行产品设计的时候感到无奈和超级想吐槽。 但是吐槽完了之后，还是得按照客观条件进行设计产品，不然，你的产品方案可能就无法落地。 所以，笔者认为，我们的产品工作，其实限制蛮大的，也需要在这样的限制下，去做好一些微创新，通过一些微创新的方式来平衡我们的产品认知和现实客观条件的矛盾。 好了，接下来我们开始进入正题，如何基于伪中台做好产品设计。在这里，笔者将会结合自己的实际案例，给大家进行解剖。 一、中台概述 1. 中台是什么 这里，笔者首先为大家列举几个常见的中台名称：微服务开发框架、容器云、Paas平台、用户中心、订单中心等。 是否觉得这几个名称很熟悉？ 其实如果名称再包装一下，就是我们所熟悉的技术中台又或者是业务中台，所以中台并不是什么很稀奇的概念。 但业内其实并没有一个对中台的准确定义，所以笔者选取其中一个比较靠谱的定义供读者们认知“中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构）。 它存在的唯一目的，就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接”。 2. 中台的价值是什么 从定义中，我们就能知道，中台的价值就是进一步提高服务用户的效率和质量。 但为什么这么说呢？ 这是由于在传统的架构中，我们只是将产品分为前台和后台。前台就是和用户的触电，类似于网页、APP、小程序、公众号等，而后台就是对企业资源的管理，类似与CRM系统、ERP系统等等。 其实在这里我们可以了解到，前台和后台并非一一对应，前台主要是服务于用户；而后台更多的是服务于企业的管理，提高企业管理效率和降低成本。 因此，会出现一个现象，前台变化快而后台变化慢且稳定。所以这个时候，很多为了服务于用户的需求，都堆积在前台，使得前台越来越臃肿，而换一个行业的用户，又需要重新起一个前台，重复工作量大。 所以，中台的出现，实际上就可以将臃肿的前台系统中的稳定通用业务能力“沉降”到中台层，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的支撑能力。 所以，企业在平台化的过程中，需要建设自己的中台层，这里强调一下，是平台化的过程中，而非一定要建设中台。 二、笔者接触的伪中台 笔者所在公司，今年提出了中台战略，但是笔者很不能理解为什么要做中台。笔者的理由如下： 公司的业务都还没有做透，就急于做中台，包装公司的产品； 公司业务目前还很简单，技术团队规模并不大，服务需求的响应效率也非常及时，完全没必要建设中台； 公司当前的技术团队的技术沉淀不足，无人进行技术架构，进行中台建设。 但是，我们产品经理，在无法说服金主爸爸的时候，也不得不按照金主爸爸的要求进行产品设计。 在公司内部，直接拉了一个团队过来，建设公司的用户中台、资源中台。 虽然笔者没有直接参与中台建设，但是笔者所建设的产品是要直接于中台进行对接的。笔者了解到，建设出来的中台是这样的。 1. 用户中台 首先，笔者的产品需要进行用户注册，根据用户属性不同，注册方式不同，达到的效果也不一样。 如果是A类用户，该用户如果需要同时使用2个产品，那么首先要在用户中台进行用户信息注册，然后再到笔者的产品这边，再次录入用户信息。两个产品都需要是手工录入，无法进行同步，而且录入的信息不一致，也会有冲突。 如果是B类用户，该用户仅需要使用笔者的产品，那么就可以直接在笔者的产品里面录入用户信息，这里录入之后就会直接同步到用户中台进行用户信息保存。 但是如果想要再申请使用其他产品，这里无法在笔者的产品进行权限更改，也无法在用户中台进行权限更改。 因为用户中台认为笔者产品同步过来的信息字段不足，需要特殊处理，不允许进行用户权限更改。 其次，笔者的产品需要进行登陆，但是登陆的流程需要经历2个关卡。通过笔者的产品登陆入口，是直接进入到用户中心的用户登陆页面。 在该页面进行用户登陆，登陆成功之后，由用户中心通知笔者的产品，用户登陆成功，而笔者的产品还需要进行一次登陆验证。因为有可能这个用户是其他产品的用户，但不是笔者产品的用户（所以，这里读者可以考虑下如何建设好用户中台）。 最后，笔者的产品如果需要更改用户的账户信息，比如进行手机号变更、微信绑定等，都需要拉着所有使用用户中台的产品进行一起讨论，这样的改动会不会影响到其他产品。 笔者认为，中台是服务于产品业务的，既然都建设成了中台，那么就应该屏蔽笔者的产品与其他的产品关联，笔者只是需要使用中台的某些业务服务，而不需要关心和其他产品的关系。 2. 资源中台 资源中台，是负责管理公司所产生的所有供业务使用的资源，包括视频、文档、PPT、Excel，文件包等等。但是这一类的资源，资源中台又要求笔者的产品按照他们的规则进行资源设计。 但是，这样的规则又不符合笔者的业务要求。 如果，强行按照资源中台的规则去设计的话，实际上，在笔者的产品运行使用过程中，用户反馈是非常糟糕的体验，要求更改资源的设计规则。 所以，如果是一个建设失败的伪中台，实际上并不能达到快速响应用户需求的效果，反而会大大降低服务效率，增加产品设计、开发的工作量、增加公司的成本，得不偿失。 三、如何适配伪中台做好产品设计 笔者还是得适配公司的伪中台进行产品设计，不然产品方案就无法落地，也没有按照公司的大方向走，恐怕产品经理的日子也会很快到头（开个玩笑）。 这里笔者就以设计的微信解绑为案例，进行讲解，如何根据伪中台做好产品设计，以及如何把控产品需求。 微信解绑原始需求: 微信解绑，只能由公司运营在后台进行解绑，禁止B端用户自行进行解绑（为了防止账号公用）； 用户更换了手机号，需要重新设置账号内容，进行微信重新绑定，就需要对该用户进行解绑； 用户可能绑定的是组织或者部门提供的分配账号，但是需要更换账号绑定，就需要进行微信解绑，但是用户不知道自己绑定的账号是什么； 如果运营在笔者产品这边把用户删除了（是允许未解绑进行删除的，但绑定关系还在），用户要求进行微信解绑，无法进行解绑，只能通过刷数据库的方式。 这里，就需要结合笔者上诉所说的伪中台的现状，进行设计，毕竟用户的微信账号绑定关系，也是存放在用户中台的。 所以，笔者设计的思路就是，尽可能减少和中台的交互！ 用户中台仅需要提供针对单个或者多个userid进行解绑的接口接口，只需要给笔者的产品返回解绑成功的code码即可。 解绑的用户，全部从笔者的产品这边查询出来，不依赖用户中台，在笔者产品中的成员管理列表，增加要给操作“解绑”和“批量解绑”。 不设计用户的微信绑定状态，原因是用户中台的微信绑定关系不会通知到笔者的产品端，在笔者产品端进行微信解绑的操作可以感知到微信绑定状态。但是，如果微信绑定操作是从其他产品入口进行操作，笔者的产品端是无法及时感知到的，会误导使用者（也就是，笔者也放弃了从用户中台查询用户绑定关系的功能）。 产品设计的一点原则是，每一个操作都有响应。因此，笔者设计了一个微信解绑记录给使用者，凡是解绑成功的账户信息都会记录到这个微信解绑记录中。使用者进行解绑操作之后，就能知道哪些账号是解绑成功的，哪些失败了，系统也会有微信解绑操作响应。 由于微信的安全性，不会将用户的微信账号信息返回给第三方，所以笔者的产品是无法拿到用户的微信信息的，因此也就无法根据微信账号进行解绑，只能根据绑定的账号信息进行解绑。 针对用户不知道自己绑定的账号是什么，所以在用户的账户信息中，增加绑定账号信息内容，提供给用户；用户需要进行解绑，首先登陆查询到绑定的账号信息，然后再将该账号信息告知到公司运营进行解绑。 针对删除的用户，笔者无法设计，删除即解除绑定关系的功能在产品里面。因为，有可能该用户使用多个公司产品，TA只是不使用笔者的产品，但依然使用其他产品，那么就会影响用户使用。 针对删除用户，为了满足运营，笔者设计了删除记录，可以通过查询账户信息的内容，查询到删除的用户信息；通过重新添加到笔者产品中，进行微信解绑，然后再次删除即可。 综上，笔者就根据微信解绑的使用场景，设计了这8条原则，从而满足微信解绑的需要。 四、总结 笔者实际上是依据问题拆分的方法，将微信解绑的一个大的问题拆解，拆分成多个小场景，并根据每个小场景，设计解决方案，从而解决这个大问题。 另外，通过减少和中台的交互，舍弃一些不是必要的需要，从而能够快速的进行版本迭代，响应用户的需求。 所以，我们所能做的，就是在大原则下，不断包装自己，进行微创新，提高自己的效率。