极端可用性：案例分析和设计方法

从这张表可以看出，产品设计和开发团队在最初设计一款产品的时候，如果想要增加产品的可用性，就需要把产品的标准定得高一点。

这个“高”，并不是让我们必须要做出完全没有BUG、使用一万年也绝不卡顿、就连三岁小孩拿到手也能玩转的完美应用。

而是让我们在追求“完美”的过程中，把应用做得越来越好，超过市面上的绝大多数竞品。

“瞬间”或者“毫不费力”这样的词汇听起来夸张，但是努力争取它，就可以保持一个正确的方向。不要满足于已有的产品设计，妥协和让步只会让产品越来越慢，越来越令人厌恶！

总的来说，要做到“极端的可用性”，就是要做到：

一目了然的目录；

极端便捷的操作；

可靠稳定地工作。

那么，究竟怎样做才可以接近，甚至达到“极端的可用性”呢？

下面，我们就来一项一项地分析实现极端可用性的几种方法。

一目了然的目录

现实难点：当用户拿到某个应用或设备时，可能会被里面的一大堆的菜单选项和晦涩难懂的专业术语给淹没。那么，那些第一次使用的用户，或者没有类似经验或相关知识的用户，就会无从下手。

常见的例子包括：

一款普通的便携式设备，各种按键混乱且复杂。我该按哪个键才能开始工作？

软件的设置选项隐藏在好几层目录之下，各项条目充满了各种各样的专业英文简称。谁能告诉我他们究竟是什么意思？

我只是想看看如何由A实现B，结果被一大堆的产品介绍淹没。我要找的东西究竟在哪？

极端可用性的实现方法：

提高清晰度——你的说明到底在表达什么

难懂的说明确实容易让人云里雾里。用户需要的，只不过是一个简单的提示。

“你想把以下证书ADD到Rootspore吗”这样的句子实在不应该出现在用户的界面里

请以我能够理解的方式告诉我，我的下一步究竟应该是什么？

把重要的东西放前面

我们先来看一张列表：

这是没有经过优化某公司说明。这样的列表会让人分不清重点：看起来都差不多，，我需要的内容究竟在哪？

而经过优化以后，我们可以把重要的内容放在更容易让人注意到的地方：

你看，并没有改变列表的内容，但是经过这样的调整，我们需要向向用户呈现的、用户想要看的东西变得一目了然，这样是不是好很多了？

再比如：

微软的word文档在早期的版本确实秒杀市面上一众对手，但是在今天看来，当时的word易用性确实还有很大的改进空间：

以前的word版本把各项功能隐藏在文档顶部的菜单栏里，看似简洁，但是它其实已经隐藏了太多的功能。如果有那么几个功能用户不是很熟悉的话，当我们需要它的时候：

翻山越岭我也要找到你！！！

好在，word2007发布的时候，我们已经看到了很大的改观：

微软把各项常用的功能放在顶部的工具栏内，极大地方便了用户的使用。

不要藏着掖着。没有人会对一个把各项功能放得很隐秘的产品感兴趣。

如果你的产品真的有什么能耐的话，摆出来，让大家看到！

让说明在适时出现

不要让产品界面像一潭死水一样，应该引导用户进行正确的操作。在人们需要说明出现的时候，他就出现在你眼前

比如当我打开一个界面的时候，他会告诉我：“在什么地方，可以做什么事情”

PS：我不是在给这个网站打广告(o′?ェ?｀o)

以及，当我不明白某个图标是什么意思的时候，我希望马上看到关于它的说明

便捷简单的操作

现实问题：设计师、程序员、服务供应商所说的便捷性，几乎永远不等于用户所说的便捷性。便捷性是一个与出发点密切相关的事情。要想清楚你是为了创造产品还是使用产品。

不要给不便捷一个正面的托辞

常见的例子包括：

设计者在设计产品的时候，往往会替用户做决定，添加一大堆不必要的功能。导致最终产品臃肿而又没有意义。

产品提供了太多不必要的功能扰乱了我的视线，这密密麻麻的列表让我感到不安等。

极端可用性的实现方法：

适当的删除

美国专门从事跟踪IT项目的权威机构Standish Group曾发表一份研究报告，称64%的功能“从未或极少使用”看看你手上的遥控器，数一数有多少个按钮你从来没有碰过。同样的结论也适用于几乎任何小玩意或你能叫得出名字的软件。通过删除来简化设计可以说是屡试不爽。

Basecamp是一个37signals公司旗下的一款非常流行的基于云服务的项目管理软件。以简单易用和颠覆性的创新而出名。尽管它的功能只有Microsoft Sharepoint的几分之一，却在全世界拥有几百万用户。

美图秀秀作为一款免费的图片处理软件，相比起Photoshop被删除了太多的功能，但是这并不妨碍它受到广大用户的欢迎。

传统的观点认为，功能越多，能力就越强大；用途越广。但是，注重深度，在主要功能上打败竞品，一样可以胜利。

不要担心删掉了功能，那些努力就跟着白白浪费了。

坏的可以修好，次品永远存在

不要替用户做决定

产品会议中，如果有人提出删除某个功能，肯定会有人跳出来说“可是，如果用户想……”最终，这个功能很被可能保留下来。

不要让“如果”把你的产品填满。

你的产品可能因此变得臃肿不堪。渐渐变得离用户越来越远，与市面上的平庸产品别无二致。

“假如用户想……”只会刺激人们求全的心理，担心自己漏掉了什么内容和需求。为了寄托这份担忧，就要有人付出大把的时间和金钱去增加新功能了。

这种无端的担忧，导致了产品会议上那些强烈的反对意见。

如果你准备说“假如”两个字，那么，请先搞清楚这个功能是否真的重要。我的用户经常遇到这样的问题吗？如果答案是“不”，那就放弃这个想法吧。

如果你想要远行，就总得丢掉一些东西。

方案，而不是流程

乍一看到某个问题，你会觉得很简单，其实你并没有理解其复杂性。当你把问题搞清楚后，

又会发现真的很复杂。于是你拿出了一套复杂的方案。实际上，你的工作只做了一半，大多数人也就到此为止了。但是，真正伟大的人还会继续前进，直到找到问题的关键和深层次原因，然后再拿出一个优雅的，堪称完美的有效方案

——史蒂夫乔布斯

用户会向我们提出很多产品上的建议，但是用户从来都不会想到一个点子是不是合适添加进产品里。

他们不会思考这样做会不会和其他功能冲突；这样做有没有很大的必要；添加这个功能性价比究竟怎么样……

如果把用户提出的点子直接放进产品里，很可能导致产品失败。

我们需要去思考的是：用户提出这样的要求，他的目的是什么？我们能否抓住问题的重点，而不是仅仅去关注流于表面的一个简单需求。

可靠稳定的工作

没有人想要一个用着用着就崩溃的产品。保证产品稳定的重要性自然不言而喻。

它很可能关系到你在消费者眼中的产品形象。比如：

“开不坏的陆巡，修不好的路虎”等……

（我不是在故意黑某个品牌或某个品牌的车主，只是我脑子里就是突然蹦出来这么一句(o′?ェ?

｀o)

而好一点的例子比如：

每年双十一，天猫的系统在午夜十二点都会承受巨大的瞬时流量。在这样的情况下能够保持系统不崩溃，保证用户的正常使用自然十分困难。当然，做好了，就能够来的巨大利润。

结语：

极端的可用性，并不是要求产品具有三头六臂，能够飞天遁地。

而是当我们在设计产品的时候，心中如果可以保持这样一个信念，就可以一点一点地接近存在于自己和用户心中的那个“完美的产品”。

作者在上面举的例子只是一点小小的引子，大家如果想到更好的方法也可以与作者讨论。

人人都是产品经理（https://www.360docs.net/doc/be13543828.html,）中国最大最活跃的产品经理学习、交流、分享平台