现在的毒牛奶，搞得九阳豆浆机空前火爆，市值甚至超过了小家电龙头老大海尔，一个以豆浆机为主打品牌的小家电企业能做到这样，无论怎样都令人佩服。

牛奶终归不太合适中国的我的肠胃，豆浆就亲和多了。所以慕名前往买了九阳。

第一次使用，可以说是心惊肉跳。我有个习惯，第一次使用的锅具都会加水烧开自行消毒一下，毕竟我不知道从生产到落到我手里中途会产生什么，我也不确定沸水加热一次可不可以消除一些东西，但这么做了总会心里安心一些。于是我干了这事，看了n遍说明书后，选择了研磨度最低的玉米汁键，慢慢的等待它的运作。老妈在一边心急，说，已经开了5分钟了，可以了，我们停止吧？怎么停？我盯了眼，第一次用还是多煮一会儿吧，让它自己停。25分钟后，刺耳的轰鸣声和蓝色灯光吓着我和老妈，我们不知所措。这么叫是什么意思啊？好了？好了不用这么可怕吧？说明书再翻了n次，发现里面写不能空煮水，可是我已经做了怎么办呢？说明书里面又说，不可以中途断电，特别是中后期，我的天，他断绝了我最后的处理方法，断电，我无奈的看着说明书，听着刺耳的声音，不知怎么办。因为说明书说，如果不严格按照操作步骤做，会损坏机器。最后我一咬牙，哼，还有7天的包换期，我强行断电。心惊惊胆战战的，试验做一次豆浆，看看机器有没有坏，还好顺利完成。

现在我用它还是会心有余悸，心想，我现在我终于明白父母为什么会这么害怕使用家里的电器。故事讲完，改回想九阳的n宗罪了。

设计上的缺陷：

1、无法暂停、重启

2、单一设置，如无法设置分量（最高水位线和最低线只有很小的一段距离，必须严格安照配比，无论需要多少都要弄相同的分量）

3、发动机与加热设备连接，清洗不易

说明书上的问题：

1、有吓唬消费者的嫌疑

2、未给出明确的可能的错误，诊断办法，及解决方法

3、未标明不同状态下，机器提供的基本信息方式。（如，那种轰鸣声是煮好了，哪种是出错了等）

看上去问题不多，可每个都令人崩溃，不过熬煮出来的豆浆味道纯正，还是很好喝。这个估计是广大消费者容忍它的原因吧。目前美的开始进军豆浆机市场，九阳如果还不改进设计，目前豆浆机的霸主地位可能很快就会被动摇。

而我所从事的工作，大部分都是针对某个部门的内部应用系统。面对的用户是比较单一，因此同类的任务几乎不值得再去划分用户。这也是一直以来令我非常困惑看不明白他人文章的原因。对于这样的系统，用户角色的划分模式，更多的是倾向于，划分整个系统的不同的状态，并分析状态间的任务，再对任务进行类比分析，确认系统的最小范围的任务清单。角色的划分是基于这些任务清单，定义角色，以及这个角色所涉及的任务。

所以这种角色划分的方式，与大家通常指的角色有很大的差异。这种角色的划分是基于任务的，而大家通常指的角色划分模式是基于用户特性的。我想这就是两者的根本性差异。

我的工作过程中，在角色定义下来后，这个角色可以说与研发定义的角色高度吻合，会对这些角色进行现场观察，看看他们是如何开展工作的？工作的瓶颈在哪？有些什么困难？工作的很有趣的做事方式是，等等...，对于他们是否是初级用户，高级用户，中间用户，关注度不会太高。因为对于这类的用户，他们最终都将会处于一个中间用户的阶段，当然某些特殊的角色会一直出于高级用户的阶段。这种模式下，更关注的会是如何让他们更加顺畅的完成任务，或者是如何去改善他们现有的工作模式。我们可能会“跳过”大家认为的“角色”的分析过程。

我不太确定两种角色的做法是否都是大家讨论的那个角色。但对于内部系统的应用软件，我认为还是选择我目前使用的分析模式会更加有效。

1. PS线框图+文字说明+xhtml展示实现demo
2. Axure 制作交互原型+PS线框图+文字说明+xhtml展示实现demo
3. ps基本效果图 + Xhtml 展现demo + 文字说明

最早的时候选用了A，通过ps线框图，让用户选择自己喜欢的风格，再通过文字说明交互过程。在用户确认风格后，对效果进行实现，提供xhtml原型，以及通用界面元素的css样式，再加以必要的使用说明。

这种方法的弊病是：让用户去选择风格，很多时候他们先看到的是功能，让后是我们期待的风格。所以用ps绘出线框图的时候，修改一些功能细节反而会是一个很长的迭代过程，这个耗时巨大。这种方式逐渐被我在的团队抛弃。当然对于一些简单的皮肤替换型项目，这么做反而是最低制作成本的方法。

因为A带来的时间浪费，以及文字说明交互的难写，难看懂的问题。调整的策略，用了方法B

利用Axure描述界面的基本元素以及交互过程，线框图描绘风格，文字对这两部分进行适当说明。在确认后再使用xhtml实现原型，为程序提供可调用的css样式及必要的文字说明。

这种方法，在与研发沟通方面取得了很好的效果。大家在开发前都能明白系统界面出来会成什么样子。用axure沟通修改也非常方便。在确认界面元素交互的基础上出效果图，节省了很多ps上的时间。

但对于用这样的方式同客户沟通，困难就很大了。用户看着axure的原型说，这个设计师做的东西也太粗糙了吧？看着ps出来的效果图说，这个里面怎么没有表格，没有数据呀？这个要有******。解释这样的工作过程费口舌，还不一定能接受。这种方式，对于直接同用户去确认效果来说存在很大的弊病。两种模式的叠加带来的理解困难。

其实方法A、B其实可以发现一直没有让XHTML原型发挥作用，原因是，我们都认为写代码和脚本实现交互要花更多的时间。现在想想如果真正想更好的与客户沟通，还是需要将XHTML的原型先做。

减少xhtml编写的耗时，需要一定的积累，通过累积各种的控件库，样式库，脚本库，将一些公司项目常用的模块模块化，需要的时候进行快速调用。见到一个朋友他们公司采用方法C，有时间去看看他们是如何工作的。

xhtml原型的一些文章

翻译：XHTML原型开发－用代码说话 http://ucdchina.com/post/1106

原文：Prototyping with XHTML http://www.boxesandarrows.com/view/prototyping-with