深浅灰色：作为思维装置的线框图

我的好朋友Russ Unger最近为Peachpit出版了一本名为“用户体验设计项目指南”的书。在有关线框图一章中他让我做一些设计，我也很高兴做这事。他向我提供了一些背景资料和要求，以便重新设计一个虚拟的邮轮操作员主页，并请我设计一些加注释的线框图以便可以在书中引用。当我完成了这个小练习后，他要我为整个过程写一个简短的解释。本文是我发给他的未经任何删节的详细解释，说明我在设计过程中使用线框图作为思维装置。毫无疑问它将被编辑以适应书籍的限制，但他很友好地让我在这里发表原文。

在我看来，线框图可作为一种设定和探索某个特定问题空间的“思考装置”—— 在这个例子中是供邮轮操作员使用的主页。要理解线框图的作用，就必须理解设计的本质。我把设计看作是对未来可能性的探索。我使用素描和线框图等手段进行探索行动，并评估这些行动的后果。当探索问题空间时，我可以比较容易地在头脑中保持设计模型，但我的首要目标——在利益相关者、目标受众和我之间创建一个对话框架的努力很可能会失败。

我认为对用户体验人员来说，把设计看作问题解决是非常正常的。对我来说，通过使用线框图进行设计就是搜索问题空间的可选择方案，既是问题设定的过程也是问题解决的过程，这就意味着我总是开始于上下文情境（context）。为了简化说明，我选择我的目标受众的一个活动，让他们快速、轻易、优美地达成一个目标。在这个例子中，目标受众想在合适的时间，以合适的价格轻易地找到最好的邮轮。在我用纸或者Omnigraffle描绘出一系列想法来探索这个主要目标之前，我甚至不看需求文档或竞争性分析。此刻我不是要寻求解决办法，因为第一轮线框图是为设计师提供一个与其他设计师，利益相关者，以及线框图本身进行对话的空间。

我的设计过程可以最好地描述为从发散阶段，通过转换阶段，最终达到融合阶段。在每个阶段，线框图都要提交给利益相关者进行批判和讨论。

“发散”阶段主要探讨设计情境的制约因素和各种可能性。我会尽力在设计情境中发现不变的事实并尽量贯彻整个过程。这一阶段的大部份活动是收集信息，尽力理解和详细阐述设计问题。通过画出许多线框图，我可以探索可供选择的方案。所有不可能的或者可想到的想法都被呈现、测试，在许多情况下还会被抛弃。

我最初的设想是在这一阶段形成的。在邮轮练习中我重点关注“搜索的集中性”，作为设计的驱动目标。我已经知道我想设计最佳邮轮搜索界面的可能性，我希望这项活动在设计前被引入并处于设计的中心地位。我描绘出这样一个概念：在用户甚至还没有看到完整的搜索结果之前，就立即向其提供建议的邮轮。从主页上，用户就可以进入一个对话并开始寻找一个完美的邮轮。这种交互方式背后的概念是很多年前由Blast Radius公司的 Peter Hong首次提出的，他们的小组现在与我们一起在Kayakon做PinPoint Trave的新搜索界面。这个概念曾经建立但后来又死掉了，但是我认为这个想法是值得保留的。

在“转换”阶段，我减少了可选择方案的数目，和我的线框图包括的设计范围。我开始抛弃一开始想到的确实糟糕的想法。通常在此时，我会去看需求文档，并尽力理解利益相关者和业务需求的整个生态系统，并在我的主要设计目标的上下文背景（我的核心受众的那个中心活动）中解决这些问题。也是在此时，我开始处理其他竞争性的需求。在邮轮操作员的例子中，我描绘了页眉，页脚和静态内容，并划出内容模块所在的区域，例如CTAs（Call to Action）和promotions。在这个阶段我会和关键利益相关者共享输出结果，但是也会带上视觉设计师，研发经理和质量保证工程师，以便他们能够有助于这一进程，并提供更多的想法，同时指出隐患和制约因素。

最后，作为设计师，我必须作出决定来执行设计规范。在“融合”阶段，我创建了两到三个备选方案供最后审议。我给线框图加上注释，以便利益相关者和目标测试者能够明白。你在图1.a和1.b看到的线框图正处于这一阶段，此时设计改变已经很少了，主要是对细节进行完善。

这里有两个基本细化过的线框图通过了这个阶段。它们绝不是完美的，但满足了本次练习的目的，并演示了我的线框图的样子。

Figure 1.a | Global Cruises Sample Wireframe

Figure 1.b | Global Cruises Wireframe

Mark Brooks, a friend of Russ Unger, and visual designer - was able to take those wireframes and rather quickly start exploring various visual designs including the screen below.

Global Cruises Homepage Comp v1

If you wish to see the complete set - or for the raw Omnigraffle files which I am happy to share - just ping me on twitter: semanticwill

You can download the PDF here: globalcruises_ixd_v1.51 (PDF)

Omnigraffle Files here: globalcruises_ixd_v1.51 graffle (ZIP)

心理分析案例系列（二）：不可能完成的任务

Finger 说明：其实这次测试的性质很模糊。我自己把它当做是一次用户体验的实践。但是，一来这个测试方案本身的出发点还是要获得软件兼容性测试数据，测试的时间又非常紧迫，二来我自己也很清楚软件工程和可用性工程的方法差异巨大，因此在本文中采用新方法的唯一目的是满足实际情况需要，并不代表哪种方法更好。

前天被头儿叫过去开会，要求我们UE组两个人对公司一款产品的软件兼容性测试方法重新评估。事件起因是这样的：

产品部领导想要了解我们产品（下面都用A产品指代）和其他产品（分别是B、C、D、E、F、G、H）对某主流软件的兼容性，于是公司需求组的同事制订了一 份详细功能点列表，总数大约是1000多项，交给测试部门。可怜的测试工程师们，他们一看就傻眼了：1000多项功能点，乘以7个产品，这就是7000多 次测试了。再加上，测试工程师们有他们自己的测试方法，他会根据你列出的功能点，编制出对应的测试用例。比方说，你告诉测试工程师我要测知道软件是否能正 常显示段间距，那么测试工程师就是编出1倍、2倍、10倍甚至317.8倍行距这样奇怪的数值，以确保是否正常显示。但是这样一来，从功能点到测试案例， 要测试的次数呈几何级数爆炸式增长了。进行到这个份上，软件兼容性似乎变成了不可能完成的任务。最后这个光荣的任务就落到了UE小组的头上，于是一段传奇 经历就此展开。

敌情侦察

孙子曰：“知己知彼，百战不殆。”我们打算先把当前的战场情况搞清楚。我们找到了需求组的同事，向她们详细了解为何要进行这项测试以及期望的输出物是什么，最后得到了这样一张战场态势图。

战棋推演

根据目前掌握的情况，我们迅速制订了这次的作战目标：

1. 快速有效地获得A产品与其他几款软件对某著名软件兼容程度的比较数据
2. 获得软件各组件用户使用权重的客观数据
3. 确定一套可重复执行的方法论，反映软件产品的兼容性

作战目标一旦明确，我们就开始制订具体的作战计划。我们的思路很明确，既然是一套可重复执行的方法论，那么它的数据收集一定是客观的（可测量的定量数 据），它的处理方法也是自动化的。换句话说，在传统软件兼容性测试中靠人工逐一排查问题的方法将在本次测试中被无情抛弃。那么可行的方法是什么呢？

首先确定测量指标，这个指标必须是客观、简单、并且可重复测量。我们首先想到的是对某个任务是否通过做二项判断：通过或者不通过。要知道之前我们是要求测试工程师们对每个功能点的兼容性做从1—5的打分的，这中间就掺杂了很大的主观性。做二项判断后，工程师的判断难度是降低了，但是又一个问题来了：如果一个功能点上有3个测试用例通过，5个没通过，该给1分还是0分呢？A作战计划失败！

于是我们又想到：计算单个功能点的通过率。这下总没有问题了吧？包三哥曰：非也非也。计算出通过率后，暮然回首，我发现自己完全被大大小小通字辈给包围了，大通（测试用例较多的功能点）和小通（测试用例较少的功能点）完全没有可比性（因为分母不同）。B作战计划失败！

没办法，只有启动我们的C作战计划了。这时候我们突然想到：既然Google可以用PageRank一项指标来反映网页的流行程度，我们为什么不找一个合适的指标呢？我的脑海中这时灵光一闪：任务时间和鼠标点击次数。我的假设是这样的：

产品对该著名软件的兼容性反映在用其他软件打开后内容显示的相似程度（H0）

由此又得出一个扩展推论是：

兼容性差的软件，用户打开后需要较多的步骤才能达到著名软件的显示效果（H1）

因此我们的实验任务就很简单了：随机找到100篇测试材料（或者你可以自己制作），先用该著名软件打开，然后在依次用待测试软件打开，要求用户判断二者显示是否相同，如果不同则手动调到相同，任务即算完成。由H1我们可以反推：当用户操作时间过长并且鼠标点击次数过多（这些数据都可以通过相关软件实时获得）时，反映出软件兼容性较差。并且，由于我的测试指标都是可测量的客观指标，可以进行统计推断，这就保证了我可以用较少的样本推论较大总体的情况，从而节省了时间。

我为自己天才的想法而沾沾自喜，下午跟头讨论的时候似乎底气也足了写，胜利就在眼前了。然而不幸的是，头对我这种想法并不认可，他需要的仍然是逐项排查并 且得出每个功能点的具体情况的汇总表。正好测试部门同事说大部分测试案例已经排查完了。于是，事情又回到了它最初的原点，按原计划测完所有功能点。C计划彻底失败！

作战总结

我不是很了解软件工程的测试流程，但是我的出发点是想找到一种简便、快捷并且抽样的自动化算法代替传统的排查法。这次实践虽然失败了，但是我会继续探索下去。希望计算机专业和其他专业背景的朋友看的本文后不要吝啬发表你的高见。

心理分析案例系列（三）：掷骰子还是画方格？

Finger说明：上次写了一篇《软件兼容性测试：不可能完成的任务？》后，感觉意犹未尽，于是打算新开一博，尝试对统计思维和计算机思维两种方式的差异做出比较。因为思维方式是一个很复杂的事情，笔者从自身角度加以揣度，难免有偏颇之处，就当抛砖引玉了。

统计思维与计算机思维：掷骰子还是画方格？

有这样两个故事。其中一个故事说：上帝创造这个世界用了六天时间。在第一天里，上帝说“要有光，于是就有了光”。此后的几天里，上帝依次创造了空气（第二 日）、海洋地面和植物（第三日）、日月星辰（第四日）、动物（第五日），最后在第六日创造了人。在随后的几千年里，人类反复颂扬着上帝创世纪的功绩，终于 有一天，一个叫做海森堡的年轻人发现：量子是完全不确定的，构成这世界的物质也是不确定的，以概率的形式出现。于是人类惊呼：上帝在掷骰子！

另外一个故事说：有个德国人在工作的时候，不小心把一枚针掉在了地面上。为了找到这枚针，德国人把家里所有东西搬离一空，然后开始在地面上画格子。等费了九牛二虎之力画好格子后，德国人开始一个格子一个格子地寻找失落的钢针，没找过一个格子（当然针还没找到）就用手里的粉笔在格子上打个叉。就这样找啊找 啊，直到几乎满屋子都画满叉号，终于找到了钢针。

这两个故事很能说明统计思维和计算机思维的差异。在统计思维看来，如果随机地抛一枚硬币，正面和反面都可能出现，而如果你大量重复抛硬币，就会发现一个规 律，即正面和反面出现的概率基本相等。这种在大量重复试验中具有某种规律性的事件叫做随机事件，这是所有统计分析的基础。

而计算机思维认为，任何信息都可以用二进制表示为0和1的组合，只要组合的方式足够复杂，可以描述任何复杂的情况。于是我们在程序设计中经常会看到：某个数据因为超过了其允许的范围而溢出。

在我看来，统计思维和计算机思维的差异在于：前者视图用具有代表性的样本，描述整体可能出现某种情况的概率，而后者则试图提供一个远超出常规需要的运算空 间，尽可能包括所有情况，来避免在常规情况下出现问题。这两种方法都是经过实践检验的，从实用主义角度来说同样有效。

我的疑问在于：软件工程中视为寻常的bug测试或者兼容性测试，实际上是靠人来进行大量的简单重复劳动，为什么没有一种合理的算法来描述这些问题呢？我个 人认为：bug是永远修复不完的，并且很可能越做越乱。一个替代性的看法是：把软件开发当做是一种自发、无序并且具备自我调节的小系统，不试图去控制问 题，而是尽量合理地描述它的产生和发展趋势，避免向坏的方向发展。至于这个描述工作，应该是靠超级计算机依靠精密的算法实现的，而不是人的手工劳动，这是 对人类创造性的极大浪费。