“我不太喜欢这种自动的伞~” 早上电梯里面碰到一个同事，向我抱怨。

这是我手里拿的那把被人嫌弃的伞~

自动伞

我们先定义伞的3种形态，用于下面的描述更加方便

在某宝上买的时候，这把伞的噱头是：全自动，刚用起来之后，也确实是这样，按手柄上的按钮，伞可以直接变为展开状态，再按次这个按钮，伞面自动折叠，只会变成中间状态，如果想还原回原始状态，只能手动收回。

OK，那么问题来了~

当我通过按钮，将伞变为中间状态，再次展开的时候，我需要先还原回原始状态（手动收起长长的伞柄），再按按钮才能打开囧了

所以为了避免这种情况，我一般是自动打开，并手动收伞，费力的将伞收回到原始状态，以方便下一次的使用，（之所以用费力这个词，是因为手动收伞的确很费力~）

如果我为了方便直接按了按折起了伞面，面对一个中间状态，下次需要打开的时候，我需要先收回到原始状态，再按钮弹开这样给我的感觉是我真像个S13

抛开这些个人情感不说，我们来分析下，这把伞提供的功能点：

顿时感觉好全面好强大~

那么使用的感受呢？

功能多了么，多了好用了么？不见得

这把伞的功能所带来的负面效果，就是每次用伞，都需要先将伞还原回原始状态，忽略了中间状态的存在，而中间状态在使用场景中占用的比例，现在看来是不容忽略的。

功能设计

技术专栏作家David Pogue曾提出过一个“夸耀效用原理”：人们喜欢自己被包围在不必要的功能中。

这种原理在工具类型的产品的体现的尤为突出，工具型产品经常面临的问题，在于处处存在可能，却又无法否定这些可能，只能为了这种可能开辟新的路径，引入新的交互，从而导致整个工具越来越复杂。

个人在做交互的时候经常遇到这种场景，PD们看到类似产品的功能就会告诉我，我们也需要这个功能，即便现在不需要，以后也是要加的~

每次看到这句话我都会想起我会很怀念我们的产品目标：将XX系统做精做简、提升易用性。而当我们深深陷入到业务场景，为了迎合各类场景而点对点的推出解决问题的方法时，这句话顶多就是会在迭代回顾会的时候再出现了。

个人曾经见到过很多优秀的工具型产品，Worktile推销介绍折叠雨伞的功能推销介绍折叠雨伞的功能，Springloops，Heroku，甚至用Redmine用久了都觉得也OK，这类工具有一个比较共同的方面，就是他们将某部分功能做简做精，比如Worktile的项目任务管理，Springloops的代码管理和部署，[Heroku]应用层面的部署等，我尝试着拿我们的场景去放到这些工具中，发现一个都无法满足我们的场景，但是对于外界来说，这些功能总能有适用的人群，这也是我觉得内部产品与对外产品**的区分。

大而全对产品设计人员的吸引力相信是很大的，毕竟在介绍产品的时候，你的功能列表就彰显了这个工具的强大，但是正如那把雨伞那样，全面并不意味着好用。

设计，是为了构建有意义的秩序而付出的有意识的直觉上的努力，功能的设计，是为了将复杂的业务场景能够更好更快的完成而付出的努力。

为了特殊场景添加特殊的功能，不如提供一个简单的功能可以扩展到各个场景，相信后者才是真正的设计，前者只是功能的累加。

So~

如果我来改进这个雨伞，我会去把自动展开的功能做精，只要雨伞处于折叠状态，无论是原始状态还是中间状态，都可以通过按钮展开，雨伞的收折由用户自己去手动完成。牺牲了自动折叠的功能，加强展开功能，避免对功能按钮的混淆。

正如早上的对话：

-“我不太喜欢这种自动的伞~”

-“嗯？为啥？”

-“感觉用起来很复杂。”

伸缩的雨棚算违建吗