“我不太喜欢这种自动的伞~” 早上电梯里面碰到一个同事，向我抱怨。
这是我手里拿的那把被人嫌弃的伞~
我们先定义伞的3种形态，用于下面的描述更加方便
- 原始状态：伞处于全部折叠，如上面图中的样子。
- 中间状态：伞柄已经全部展开，伞面还是折叠状态
- 展开状态：就是下雨时打伞的那个状态。
在某宝上买的时候，这把伞的噱头是：全自动，刚用起来之后，也确实是这样，按手柄上的按钮，伞可以直接变为展开状态，再按次这个按钮，伞面自动折叠，只会变成中间状态，如果想还原回原始状态，只能手动收回。
OK，那么问题来了~
当我通过按钮，将伞变为中间状态，再次展开的时候，我需要先还原回原始状态（手动收起长长的伞柄），再按按钮才能打开囧了
所以为了避免这种情况，我一般是自动打开，并手动收伞，费力的将伞收回到原始状态，以方便下一次的使用，（之所以用费力这个词，是因为手动收伞的确很费力~）
如果我为了方便直接按了按折起了伞面，面对一个中间状态，下次需要打开的时候，我需要先收回到原始状态，再按钮弹开这样给我的感觉是我真像个S13
抛开这些个人情感不说，我们来分析下，这把伞提供的功能点：
- 自动弹出并展开（赞！）
- 自动折起，附带强大的duang还能震动下伞面上的雨水，如果你在打伞的过程中不小心按到了这个按钮，呵呵，那你会被伞面上的水淋一身（亲身体验）
- 同时提供手动的收折功能。
顿时感觉好全面好强大~
那么使用的感受呢？
- 第一次使用，在别人欣羡的目光中，潇洒的自动弹开~
- 遇到了避雨点，自动折起伞面~
- 再次暴露在雨中我擦，按钮怎么不能用了？丫的是不是坏了赶紧把伞还原回之前的状态再打开，然后你之前的优越感已经荡然无存了~还会有一种被坑了的感觉。
功能多了么，多了好用了么？不见得
这把伞的功能所带来的负面效果，就是每次用伞，都需要先将伞还原回原始状态，忽略了中间状态的存在，而中间状态在使用场景中占用的比例，现在看来是不容忽略的。
功能设计
技术专栏作家David Pogue曾提出过一个“夸耀效用原理”：人们喜欢自己被包围在不必要的功能中。
这种原理在工具类型的产品的体现的尤为突出，工具型产品经常面临的问题，在于处处存在可能，却又无法否定这些可能，只能为了这种可能开辟新的路径，引入新的交互，从而导致整个工具越来越复杂。
个人在做交互的时候经常遇到这种场景，PD们看到类似产品的功能就会告诉我，我们也需要这个功能，即便现在不需要，以后也是要加的~
每次看到这句话我都会想起我会很怀念我们的产品目标：将XX系统做精做简、提升易用性。而当我们深深陷入到业务场景，为了迎合各类场景而点对点的推出解决问题的方法时，这句话顶多就是会在迭代回顾会的时候再出现了。
个人曾经见到过很多优秀的工具型产品，Worktile，Springloops，Heroku，甚至用Redmine用久了都觉得也OK，这类工具有一个比较共同的方面，就是他们将某部分功能做简做精，比如Worktile的项目任务管理，Springloops的代码管理和部署，[Heroku]应用层面的部署等，我尝试着拿我们的场景去放到这些工具中，发现一个都无法满足我们的场景，但是对于外界来说，这些功能总能有适用的人群，这也是我觉得内部产品与对外产品最大的区分。
大而全对产品设计人员的吸引力相信是很大的，毕竟在介绍产品的时候，你的功能列表就彰显了这个工具的强大，但是正如那把雨伞那样，全面并不意味着好用。
设计，是为了构建有意义的秩序而付出的有意识的直觉上的努力，功能的设计，是为了将复杂的业务场景能够更好更快的完成而付出的努力。
为了特殊场景添加特殊的功能，不如提供一个简单的功能可以扩展到各个场景，相信后者才是真正的设计，前者只是功能的累加。
So~
如果我来改进这个雨伞，我会去把自动展开的功能做精，只要雨伞处于折叠状态，无论是原始状态还是中间状态，都可以通过按钮展开，雨伞的收折由用户自己去手动完成。牺牲了自动折叠的功能，加强展开功能，避免对功能按钮的混淆。
正如早上的对话：
-“我不太喜欢这种自动的伞~”
-“嗯？为啥？”
-“感觉用起来很复杂。”
“收起来很麻烦，还不如正常的伞”
同事肯定了自己的态度，如是的说道~
