网络界面设计中的批判性思维

Scott Berkun写的文章往往从实用角度出发，比如本文：

摘要：关于网页及界面设计中批判性思考的讨论

批判性思考是 设计和工程学的核心。无论是电影导演还是项目经理，程序员还是设计师，在众多领域里，分辨有价值和无价值的能力都是优秀的标记。虽然这种能力是可以靠学习 掌握的，但是由于独立于技术领域，它经常被我们所在的行业遗忘。尽管，毫无疑问，在工程、设计及可用性上最严重的失误都是由高层决策失误造成的，开发人员 和设计师也都应该对于什么是好的批判性思考和激发这些思考的方法有一定的了解。在网站或软件开发的努力过程中，批判性思考在三个地方显现：计划，灵感激发 和项目管理。本文着墨于计划阶段，如有兴趣我会在将来的文章中介绍其他两个方面。

在开发过程中 最常见的失败是不能正确的定义问题。如果目标是模糊的，我们不可能知道问题是否得到解决。就算目标被定义清楚，对于使用此项设计的环境来说有可能是错误的 目标。制造精良的手枪不可能帮你修理瘪掉的轮胎。这两种错误，模糊的目标和错误的目标，是与技术的精准无缘的。如果你不能避免这两种错误，即便是世界上最 好的程序员和设计师也不可能成功。你可以写出最棒的代码，创作出最精彩的设计，如果你不能解决正确的问题，你的努力是白费的。

理解问题

迈向批判性思考的第一步是客观审视问题。作为开发人员或设计师，你所做的事情让你有不可置信的偏见。你在内部向外看，很难以外人的角度 看待自己的工作。为了找到你的方位，你需要从大量不同的来源进行测绘。单独的开发人员、经理、某个重要用户的看法是没有价值的，你要找到全局的视野和尽可 能多可选择的观点。一定要直接和使用你的设计的人对话，但是不要用人们的话来理解问题。想象你是一个力图帮助你的选民的政治家，你会只相信你的智囊团的说 辞吗？为了做好，并且看到事物的真实情况，你必须从你平时做的事情中跳出来。

进一步的挑战，你接触用户的方式将影响到你从她们那里获取的信息类型。如果没有受过训练，每个人都会无意中使自己的问题具有引导性，这样你将得到不可靠的信息。

观察和理解用户的技能非常复杂，这也是网站和软件团队需要可用性工程师的首要原因。你可以简要的学习一下基础，但是如果你致力于其他重要的工作，那么请一个专业人员。

在研究你要解决的问题的时候，时刻记住以下几点：

·谁是你的用户？他们掌握怎样的知识和技能？

·我们可以用什么不同来源的数据去理解他们的背景？

·他们使用我们的产品或者网站要完成什么样的任务？
·我们做了什么样的假设，我们是怎样证实它们的？
·我们有什么样的数据来源？（可用性研究和启发式评估是一个很好的起点）

如果你对自己对于这些问题的答案没有信心，你还没有准备好。这些信息是你开发工作的基础。在你继续之前,确保对你的用户有坚实可靠的理解。如果这是你的第一次尝试，你可以使用你所能找到的竞争对手和他们的用户的信息。

分析

作为开发人员,有无穷的问题你要解决,无穷多的新特征你要添加。所以有一个想法不足以确保它实现。考虑到投资方的要求和它们有限的资金支持，很多问题是不 值得去解决的。有时解决一个问题会引发两个新问题。所以一个好的判断意味着能够分辨什么是可以做，什么是应该做的。在收集数据之后，分析是通向一个好的判 断的下一步。你需要分割信息并且评估出需要在哪里投入精力。

根据从用户和 其他来源收集的数据，将每个独立问题提取成一句话的信息。这些句子应该立足于用户的视角。举个例子，“将输入框加宽至十五个字号”不是一个问题，而“输入 比较长的文本很困难”是。这中间的区别是戏剧性的。不要同时定义问题和解决问题的方法，这样你会经常忘记真正的问题。在这个例子中，其实有很多种方法解决 输入长文本的问题，包括改变搜索框的形状。但是如果你太狭隘，你会看不到其他的选择。好的工程师就是去理解这些选择。

对每个问题描 述提供支持信息。包括这样的信息：什么样的用户有这样的问题，这个问题是怎样被提出的，甚至是可能的解决问题的方法。也许只有特定部分的用户遇到这样的问 题，或者它只发生在某种情境里。尽量多描述一些来让别人信服或者挑战你的结论。如果你是唯一看到这些支持信息的人（例如可用性研究、市场研究等），让别人 也得到这些信息。你对这些资源越公开，别人的质疑也就越少。

如果你在一个团队工作，将所有的问题做成一个小的文档，包括每个问题的支持信息。

一些问题表达的例子：

·网页跳转很困难
·用户等待软件下载的过程太长
·我们的安全错误信息很难理解
·我们的注册页面有太多问题，用户经常放弃这一页
·在页面索引里面寻找一个特殊产品很难完成

注意在用户问题和系统bug之间有一条细线区分开来，我是根据两个特征来画出这条线的.

bug符合下面的特征:

1) 因为代码错误而没有实现预期的功能
2) 有明显且简单的方法解决

例如：无法下拉菜单显示五十个洲是一个bug，而用户无法找到下拉菜单或者完成任务是一个用户问题。

综合：列表和优先级

整理列表是一件奇妙的事情。将条目列出来，排列优先级就已经定义了一个版本。如果没有明确的优先级，团队会因为何处需要完成何处需要删除吵作一团。设置优先级的工作应该比你做调查容易，但是也往往是一个挑战。

提炼是整理列 表的最佳操作方式。团队中的某个人根据他或她对整个项目的感觉通览列表并排列它们：第一条是最重要的，最末一条是最不重要的。然后团队的其他成员应该通览 这份摘要形式的列表并且在上面加注修改意见，以便起草人员修订更新。在某个阶段就可以做出决定并制定决策。如果你独自工作，最好找一个你信任的人检查你设 置的优先级，也像团队工作那样，一个聪明人整理筛选之后给出的各种意见能带来最好的思考.

制定优先级需要能力去评估三项标准：日程表、团队和商业运营。项目的日程安排可能是事先确定的，这限制了可能完成工作的规模和程度。对于一个小开发周期，需要重写一半的基础代码的更改是不可能尝试的。

团队的组成情 况和环境决定了什么样的工作可以被完成。这个团队有其他的资金支持吗？团队里有没有设计师或者可用性工程师？团队中的网页或者UI设计人员拥有怎样的技 能？最后，最重要的，是商业上的考虑。这个项目的预期收益目标是什么？竞争对手是谁？对于解决某些特殊问题你有什么有利条件？你可以利用什么样的合作关 系？

在你的项目里可能有其他需要考虑的方面，但不管是什么，它们需要在整理列表之前明确下来。考虑越清晰，制定问题的优先级就越简单。如果在整理列表进行过半时发现了新的约束条件，你将不得不重头开始再做评估。

一旦你整理出了一份列表,你可以在上面化一条线,分开重要和次重要的条目.有多少条目被划分到第一栏取决于你的日程表。

有趣的事情在哪里？

当这些目标都已经完成，需要解决的问题也已经被确定，有趣的事情就开始了。根据工作框架和决策，可以放任工程师和设计师去想各种方法解决这些问题。可以计 划好时间尝试解决问题的各种方法并且通过一些原型的可用性分析看看它们是否实际上提升了用户体验。然后在日程表上确定的一个点，评估这些可能的解决方法， 值得尽全力开发并且符合开发计划的保留下来。剩余的被放弃或者推迟到未来版本。从制定某种标准，通览整个进程这一点上来讲，这个步骤和确定问题的工作方式 是相似的。

最初确定问题的工作是开放性的，而不是限制性的。只要你的工作是应对重要的问题，你就一定会找到正确的方向。如果你的问题陈述足够宽泛，就会有很多革命性和创造性的方法去解决它们。就算你不能完全解决一个重要的问题，部分的解决正确的问题也要胜过完全解决错误的问题。