可消费性设计 让软件贴近用户

 在产品的设计开发讨论会上，与会人员有若干开发人员、组长，讨论一个XML配置文件编辑器的做法。

“组员甲”说可以做成树状、表格的、带输入框的方式。

“组员已”说可以基于XML编辑器做扩展，支持语法和语义提示，类似Java JDT编辑器。

“组长”说做成图形化的展现方式，比较炫，对客户有吸引力。

这个会上，大家展开了激烈的讨论，最后组长胜出，组长虽然也赞同组员的提议，但坚信自己的提议和设计更好。

次日，另一个设计开发讨论会上，项目经理也参加了会议。大家重新讨论了这个编辑器的设计和做法，于是又展开新一轮的激烈讨论。最后，项目经理觉得“组员甲”的方案最好，经过经理激烈讨论，最终这个方案胜出。

上面类似的会议在身边时常出现，大家是否有似曾相识的感觉？

这个场景不是去批评组长和项目经理的独断，而是在描述一种软件设计开发中的现状：软件产品设计开发时，各种设计方案单纯从实验室和技术的角度出发和讨论，没有引入“可消费性”思想和方法论，所以各自的讨论容易陷入一种“自由”讨论的形式，公说公有理、婆说婆有理，最终胜出的往往是会议中最有决断力的人。

本文和大家一起讨论由IBM提出的可消费性思想和方法论——Consumability，以及笔者把这一思维方式和方法论引入参与的产品并应用的一些体会和经验。

1. What is Consumability

可消费性设计（Consumablity）是IBM提出的一种概念和思维方式，包括这个词也是IBM发明的（刚接触这一概念和单词的时候，多次怀疑自己写错了。Consumablity，是IBM发明的词，在词典中找不到，而Word和邮件系统会提示这个词不存在"红线"）。

可消费性设计涉及设计、心理学、用户行为分析、软件设计等多门学科，其中有很多专业理论和技巧，但作者认为可消费性更多是一种以“一切设计从用户的角度出发”来思考问题和设计产品的思维方式。抱着这种思想，生活中、工作中，处处都是可消费性设计问题。设计软件、开发工具、装修房子、吃喝住行，甚至演讲、写信、写PPT等，处处都充满可消费性的思维方式。

总而言之，只要有用户和需求，就有可消费性。

可消费性在当今社会正扮演越来越重要的角色：

1) 做正确的产品，在市场中有正确的定位和用户群

当前的世界，产品极大丰富，不管任何产品都会有的竞争对手和替代产品，大家熟知的有浏览器大战，输入法血拼，视频网站、博客满天飞，国内外ERP系统竞争激烈等。

可消费性思想指出，一个可消费性好的产品，首先应该是一个“正确的产品”，能在激烈的市场和竞争对手中找到市场定位，有客户需求和市场销量，能提高产品使用者客户体验的产品。如果产品不是个正确的产品，没有以客户为中心，策略和方向不对，那产品做的再好、界面再优美也不是一个高可消费性的产品。

正如Wikipedia中IBM可消费性概念的第一个重要内容就是：Identifying the right product。

可消费性设计提倡基于角色（Persona）的设计方法论，注重产品购买者的需求、直接和间接使用者的用户体验。如上面的会议争论，如果每个提议都从角色（Persona）的角度去考虑，就不会陷入主观的判断中。设计和讨论时，围绕“请问谁是使用者，使用者在所有的使用者中的比例是多少，重要程度如何”等问题，自然而然就朝着设计出用户需要的产品的方向前进。

2) 信息极大丰富和人脑的有限

现在信息量极大丰富，各种概念流行，各种产品层出不穷，网络信息和广告信息膨胀，而客户的大脑却是有限的，客户在多种竞争产品的无数广告的压力下, 脑袋为你产品留下的空间已经很小。

所以，产品在名称上、概念上、逻辑上、使用功能上、甚至广告宣传上都能应该尽量“一目了然”、“不言而喻”。“不要让用户思考”是非常重要。这样才能在客户的脑中和知识结构中留下“一席之地”。让客户一有相应的需求，头脑中第一个想到的就是你的产品。可消费性也是“知识营销”的重要部分，只有你的产品好记、好用，才能被更广泛的认知，认知后才能进一步进行购买。

现在是“注意力经济”的时代，试想如果用户需要看上万字的说明，几个小时的课程才能明白一个产品究竟是做什么的，能给客户带来什么好处，有什么样的功能，怎么使用的话，最大的可能是这个客户将不会使用这个产品、不会继续看下去。

可消费性提倡从定位，到概念，到使用的可消费性，这样才能让用户容易记住，并记得更牢。

3) 科技越来越发达，功能越来越复杂

现在科技越来越发达，产品的功能也越来越复杂。就拿上个世纪90年代的洗衣机和现在的洗衣机相比，功能上不可同日而语。

但发达的科技和复杂的功能，带来用户使用的困难。有些可消费性问题导致客户满意度和产品销量降低，而有些可消费性问题可以造成灾难性的结果。

如刚发明飞机的头几十年中，据调查有很多的飞机事故是由于飞行员使用不当造成，当时把责任归咎到飞行员身上。但从可消费性设计的角度来看，用户不会使用或者难以使用产品，设计人员也是有很大一部分责任的。试想一个产品要培训N年，有着N千页的操作顺序和文档，操作失误那是人之常情。

科技越来越发达，功能越来越复杂，这时候更需要可消费性。我们应该牢记住，用户不会使用产品，那是设计人员的错。

4) 敏捷开发方法

敏捷开发方法推崇由外到内的开发方法（outside-in development，OID），强调以客户为导向的开发方法，重视市场的发展趋势和客户需求。

现在敏捷开发方法越来越被广泛使用，它和可消费性设计的理念相吻合，可以互为补充。请参考笔者的敏捷开发文章《我的敏捷开发实践》。

2. How to Consumability

本小节介绍笔者引入可消费性理念，并改进所参与产品(WebSphere Multi-channel Bank Transformation Toolkit, BTT)过程中的一些实践和体会。
将从四个方面介绍可消费性理念和实践：可消费性需求、可消费性设计和开发、可消费性文档和安装，以及可消费性测试。

1) 可消费性需求

笔者认为这是最重要的一项，因为这是后面所有其他可消费性的前提。没有可消费性需求，就犹如路和方向就是错误的，不管在这条路上走得多好，多稳，也不会通向理想的目的地。上面一节介绍过，可消费性设计注重Identifying the right product, 也强调outside-in development。做正确的事情，说起来简单，但做起来是最为困难和艰险的。在这里，一步走错就会导致整个产品全盘皆输，因为产品定位和需求都错，再如何努力开发和测试也是枉然。

下面是笔者在产品设计过程中经常使用的集中方法，尽量达到高可消费性的需求。但一般来说，尽管是正确的需求，也是在不断的演变中，所以也需要具体情况具体分析，迭代地进行设计开发。

Persona的方法论

Persona指的是角色，也就是基于角色的方法论，强调一切从角色出发思考问题。每个人思考的角度都不一样，开发人员在设计和开发软件的时候，容易陷入自己的思维角度，开发出不符合客户思维角度的产品，而没有满足客户的需求。很多人都会陷入这样的惯性，而根本不知道错误在哪里。

Persona的方法论中强调，不论产品有哪些需求，哪些功能模块，甚至会议中的讨论，请首先确认出Persona。Persona可能不止一个，所以需要分析并确认出不同的Persona，并设定所有Persona的背景、需求、期望等。然后把讨论的需求、功能模块、会议议题，对应到定义的Persona中。再根据Persona的重要与否、Persona的背景等，进一步分析、确认需求。

Persona的简单模板：

·Name

·Photo

·Brief Biography

·Goals

·Context scenario

笔者的经验中，Persona的方法论非常有益于理清思路，特别是在需求讨论阶段尤为重要。需求收集和讨论时，不同的同事代表不同的Persona（有的是客户业务人员，有的是客户架构师，有的是客户技术人员），他们提出各种不同的假设、需求、改进、功能模块。这时，如果不从Persona的角度去思考和理清问题，就经常陷入混乱和口水大战。

演示和原型

我们在产品敏捷开发过程中，除了正式的产品开发，还有专门的团队只做演示和原型。演示是为了向客户和业务人员展示产品功能，并获取反馈；原型是为了展示对产品未来的雏形和概念，便于产品讨论和获取客户需求。原型、产品和演示三者的关系如图所示：

不管是演示，还是原型，对产品的需求管理来说都非常重要。

最高境界：跟随需求，不如创造需求

可消费性需求的最高境界是创造概念、规则，并由此创造需求。不管是软件行业，还是其它商业界都是如此，如：

·从BP机到手机，再到iPhone；

·从胶片相机到数码相机；

·从门户广告到搜索广告；

·从Blog到Twitter等。

商业界创造概念、规则、模式，并由此创造需求者，才能创造出蓝海，并成为领头羊。而其他跟随着只能符合创造者的提出来需求。

在这个境界上，创新是最至关重要的因素，唯有创新才能打破规则，打破需求跟随者的状态，创造出符合未来用户需求的规则和产品。

2) 可消费性设计、开发

可消费性设计、开发指的是，设计需求的结构、设计和实现方法是否具有可消费性。包括下面几个方面的内容：

架构和设计可消费性

这里指架构和设计方法的逻辑性和合理性，并且是否符合主流的架构模式和设计模式。良好的架构，应该是采用标准、结构清晰、一目了然，并层次分明的。

架构逻辑性、层次性依赖于架构师的功力。但业内有一些最佳实践和标准，是值得大家去遵循。笔者在此分享一些这方面的经验教训。

经验是：在架构设计上，应尽量采用标准，以及主流的架构设计模式。标准和主流的架构模式一般意味着最佳实践，而且都有免费或者开源实现，可以复用标准，加快开发速度。比如，企业Web前端的展现层框架可以利用标准的JSF，后端的服务接口使用Web Service等。

教训是：笔者参与的项目重新实现了一些业内已经很成熟的架构和技术，比如界面组件，而没有采用标准定义模型等，造成一些不必要的工作量，而且效果不如采用标准的好。

界面设计可消费性

界面设计和开发是可消费性的重要内容，因为它是和用户进行交互的主要通道。笔者总结了一些常用的最佳实践，界面设计至少需要符合下面这些点：

·信息清晰原则。尽量少用缩写，除非你的缩写已经众人皆知。比如IBM、PPT这样的词语。但像VC=Verification Code，这样的缩写尽量避免。

·可视性的设计原则。用户界面的操作尽量让人一看就知道如何操作，而不用记忆或查阅文档。比如，界面中隐含操作顺序而不用用户牢记；用星号标记出必选项等。产品界面是否好用，用户第一次使用，或者用户很长时间不使用后重新使用时是否能够很方便的使用，这些都很关键。好的设计无需用户记忆，在设计中隐含着可视性的提示，便于用户完成操作。

·限制性原则。尽量限制在界面上的用户错误操作。一座高楼，如果危险，就应该加上栏杆，界面上也是如此。应该屏蔽用户当时不能输入的输入框等，尽量不让用户操作会引起错误的界面元素。限制错误的操作，指示正确的操作，只给用户一条正确的路，用户就能无需去判断错误，容易的完成操作。

·反馈原则。反馈是控制科学和信息理论中的一个常用概念，其含义为：向用户提供信息，使用户知道其某一操作是否已经完成以及操作产生的结果。举一个例子，我们在打电话时，按键都会产生提示音，并且在液晶显示屏上会提示用户输入的数字，这就是一个典型的应用反馈原则设计的产品。如果用户的每一个电话按键的输入，完全没有反馈，只有到电话拨通后才能知道是否拨错电话，那可想如此的电话系统必不受用户欢迎。在界面设计中，用户输入信息，界面上应该能验证输入信息的正确性，并提供反馈信息给客户。

·分类原则。当界面上的信息多时，这一点尤为重要。把所有信息分类，并把同类的信息显示在一个区域，能方便用户浏览信息。

·差异性原则。用颜色和和字体体现不同的界面元素，如必选项用红色标记，字体用粗体。颜色与心理学、公司或国家常规是相关的，否则会适得其反。

·逻辑性原则。逻辑上两种元素的结构关系，可以通过界面上的视觉结构体现出来。如层次包含结构，在界面上应该用缩进、层级菜单等结构体现出来。

配置可消费性

现在产品越来越多的配置，有基于XML的、基于Property文件的、基于编辑器的。配置带来产品灵活性的同时，也带来了可消费性问题。下面是几点可消费性建议：

一：配置集中化。现在产品配置步骤繁多，大都需要配置多个地方，多个文件，如果其中一个没有配置就会导致所有的配置不起作用。

建议能用一个配置，尽量不用两个配置；能在一个文件，尽量不要分散在多个文件中。

二：配置向导化。配置也好，调整也罢，你需要告诉客户都要做那几步配置，在哪里配置，怎么配置。现在大多数的配置需要在成千上万页的文档中查阅，然后一一对应，有时候配置的顺序还有关系。

建议如果有多步的配置，采用向导的方式，一步一步的指导用户完成正确配置。

三：配置验证性。用户完成了许多的配置，大多产品不给用户足够的反馈结果，提示配置是否出错，出什么错，哪里出错；而需要用户在运行环境按经验去找错，看Log、Trace。结果好不容易找到了，兴许也就是一个很小的大小写错误。用户兴许会想，都是自己不小心，怪自己疏忽。但笔者认为这是设计开发人员的可消费性错误，不注重可消费性的今天，用户帮着承担了。

建议：用户的配置应及时甚至当场就提供给客户反馈信息，提示用户配置的结果，如果配置错误，应提供足够的错误信息，哪里错误，出什么错，有什么解决方法。

开发规范可消费性

开发规范可消费性是在开发的过程中，开发人员编码规范和编码习惯的可消费性。好的编码机构清晰，读起来毫不费力，是一种享受。开发规范可消费性包括：程序代码结构可消费性，代码格式可消费性，注释可消费性，包结构和命名可消费性，类名和方法名可消费性，变量名可消费性等。

·代码结构可消费性在于开发人员不断重构，把代码按照逻辑结构分成不同的包。

·代码格式可消费性一般可以通过编辑器的代码模板和格式器来控制。

·注释可消费性即符合JavaDoc或.Net的注释格式书写注释。

·这里强调一点是命名的可消费性，不管是包命名、类命名还是变量命名，命名时应该采用能够让人看懂的名字。名字长一些往往更好，尽量少用不清晰的缩写，如：People对象，应该用people等能够一目了然的命名，而不是p、pe等简短不清晰的命名。

3) 可消费性文档、安装

文档可消费性

文档的目的是让人学会使用产品，可消费性的最高境界莫过于连文档都不需要了，比如傻瓜相机。虽然它也带有文档，但由于其易于操作，用户无须知道光学原理、焦距、曝光就可以使用，很少有人去查阅文档。

下面是文档书写的几点最佳实践：

一：能用视频少用图片，能用图片少用字。现在用Flash视频教学是非常好流行的一种教学方式，尽量多用一些Flash视频的教学方式，如果没有视频，也尽量多一些图片、产品截图等。

二：多一些例子，比如Struts框架提供了show case等一系列例子，教导用户如何开发和使用技巧，这些比纯文字的文档形象直接，效果更是不可同日而语。

三：文档中尽量少用缩写，除非是人尽皆知的缩写，如EJB等词语。如果需要使用缩写，需要在一些地方标记出全名。

安装可消费性

安装现在是大多数产品一个很大的问题。由于计算机业分工越来越细，一般来说，一个产品很难单独使用，需要其他一系列的产品辅助才行。这就造成安装上的极大困难，甚至出现几天才能搭建一个环境的情况。

如果能提供已经安装和配置好的，包括所有所需软件的环境，那肯定会受到用户的好评。最好是绿色版的，下载解压即可使用。

产品花N天准备的这个环境，将节省所有用户N天的安装配置环境时间。

4) 可消费性测试

测试人员是产品的第一个使用者，可消费性测试需要他们反馈所有的不可消费性问题，包括概念不清晰，结构不清楚，界面使用可消费性问题，API使用可消费性问题，API JavaDoc可消费性问题，文档可消费性问题，演示可消费性问题等。

现在产品有功能测试、集成测试、性能测试等阶段。但很少产品有单独的可消费性测试阶段，也很少有可消费性的Defect。鉴于可消费性的重要性，笔者觉得很有必要增加一个产品的可消费性测试阶段，用于提高产品的可消费性。这个阶段中，测试人员对上面介绍的产品各方面进行可消费性测试，并开相应的可消费性Defect。

可消费性测试是黑盒测试，除了上面的各种规则测试外，还需着重关注下面四个方面，并给出测试结果：

·效率 - 用户要花多少时间，多少个步骤才能完成一个任务。比如注册用户、查找一篇文档。

·准确 - 在操作的执行过程中，用户犯了多少错？测试人员要时刻记住，用户在使用产品中犯错，是设计人员的错，而不是用户的错。

·无需记忆性 - 用户在第一次使用中是否能容易的使用产品？或者用户多长时间不用后，还能记得如何操作产品？好的产品设计是无需用户记忆，一切使用规则是隐含在设计中。

·情感反映 - 用户完成任务后的感觉是什么？放松，还是紧张？该用户是否会推荐产品给用户？用户使用产品，就犹如和设计师对话，好的设计师处处为用户考虑，用户使用完产品后会很放松甚至兴奋，会迫不及待的推荐产品给其他用户。

可消费性与否很关键的在于第一个使用者，所以建议在可消费性测试中，测试人员可以互换测试模块进行测试。

3.可消费性实践总结

可消费性—Consumability—是一种思维方式和方法论，它影响产品的定位、架构、设计、测试、文档的方方面面。可消费性是知识营销和市场营销的重要组成部分，最终会反映到产品市场销量和客户满意度。不管是产品还是项目都应该从可消费性角度去思考和设计。下面是笔者在产品中开展可消费性设计的几个阶段：

·引入可消费性思想阶段。这个阶段中引入可消费性思想进入团队和产品开发，需要培养团队可消费性思想和方法。刚开始团队不具备这方面的知识和意识，需要一段时间耐心的培育。这期间可以举行一些讲座，传阅一些相应的材料。

·分步执行阶段。这个阶段团队具备一些知识，可以提出可消费性问题和改进，但还不系统和全面。这个阶段，可以分步执行上面介绍的可消费性的几个方面，如可以从可消费性测试开始执行，慢慢开一些可消费性相关的Defect。

·全面开展可消费性方法。这个阶段，经过一段时间的培育期，团队已经成熟，并具备可消费性思想和方法能力。可以从需求，到架构设计，到文档、安装，到测试全面开展可消费性设计。

希望更多的公司、项目开始采用可消费性设计思想。可消费性设计不是设计人员的专利，任何人都可以从可消费性思想角度去改进产品。

我的口号是：ABCD - AnyBody Can Do it.