简约四原则：删除、组织、隐藏、转移

删除

standish group于2002年的报告中：64%的软件功能“从未使用或极少使用”

• 广度 vs 深度
  传统观点：功能越多，能力越强，越受欢迎。
  但实际上功能越多，即使注重产品的广度，而没有考虑到深度。删除不必要的功能既可以让设计师开发人员专注把核心功能做好，把有限的精力解决问题，也可以让用户心无旁骛完成自己的目标。
• 避免错删
  由于设计阶段求全的心理，到交付期接近预期收紧，删除功能过程中，倾向于把难于实现的功能删掉，没有从大局把握，是最常见的错删。
  此时如有反对，答复一般就是功能在第二期、第三期再实现。结果产品成为一个简单功能堆砌出毫无特色的产品，导致项目发散没有灵魂。
• 关注核心
  对产品的优先级别排序，1.时刻记住用户最关注的日常功能才是最有价值的；2.寻找用户挫折的来源，消除其挫折感也会使产品受欢迎。所以可以画用户行为旅途。

以新增功能先比，用户更加关注基本功能的改进

• 砍掉欠缺功能
  已经开发创建功能的费用是收不回来的“沉没成本”，评判是否要保留，需要看该功能可以发挥几分作用，保留会产生多少额外的成本。

砍掉功能有时候是血腥，而人们常常舍不得扔掉东西，即使它已经破烂不堪。

• 假如客户……
  当设计过程中场景假设中“假如用户……”时，需要反问“是否经常遇到”
  假设场景会激发设计者的求全心理，花费很多精力和时间增加用处并不多的新功能。
  当然也不要简单因为客户要求就新增功能：
  多问问：该功能是否真正应该存在于手中的产品；会不会增加产品性能和使用体验下降；会不会增加其他用户的疑惑；有没有其他满足用户的替代方案。
  想任何时候取悦所有用户是不可能的，只能退而求其次，专注用户的核心功能任务，让他们满意开心就行了。

如果一个小的变化导致复杂流程，就应该退一步寻找更好的解决方案。

组织

• 功能分块
  建议分块实行 “7加减1” ，分块过多会让客户难以记住分类。每种重要的几大菜单，由于每个菜单中的命令还是很多，对命令进行分块，一目了然。
  当然如果功能不是特别多，或是都是归为一类，就可以分3/4块，甚至不分块。

  
  image.png

• 围绕行为进行组织
  用户对功能第一个问题是“它能做什么”，而组织者为了更好理解用户，应该问“用户做什么，先做什么后做什么”
  多画用户行为图，有利于理解如何组织产品

• 分类要是非分明
  分类要参照一定的标准，但是标准应该尽可能客观，如车功能分类“技术、舒适度、性能”就不如“外观、内饰、性能”来得明确。分类不明确，客户不知道哪里找。同时，分类尽可能少重叠，减少困惑。