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

批判性思维是设计和工程学的核心。在很多领域中，从电影导演到项目经理，从程序员到设计师，分辨哪些事🐈物是有价值的都是一种非常重要的能力。这种能力是可以靠学习获得的，只是由于它独立于技术领域，经常被我们所在的行业遗忘。不过很明显，通常在工程、设计及可用性上犯的大多数失误都是由于全局的决策失误造成的，(因此)开发人员和设计师都应该了解批判性思维的方法与流程。在网站或软件开发中，批判性思维在三个方面显现：规划，灵感激发和项目管理。这里我们重点讨论制定规划，今后我再去撰文介绍另两个方面。

在开发过程中最常见的错误是不能正确的定义问题。如果目标是模糊的，就无法界定问题是否已经得以解决。就算目标是正确的，也有可能与当时的设计情形不相符而导致错误的目标。制造精良的机枪不可能帮你修理瘪掉的轮胎，因此上述两中错误是与技术的精准无关的。如果你𒀰不能避免这两种错误，即便是世界🔯上最好的程序员和设计师也不可能成功。你可以写出最棒的代码，创作出最精彩的设计，但如果你不能正确解决问题，你的努力是白费的。

理解问题

迈向批判性思维的第一步是客观审视问题的ꦿ本质。作为开发人员或设计师，你不可避免地会偏向于自己的工作。你是由里及外，很难以外人的角度看待自己的工作，这时你就需要考量各种信息来找出自己的定位，孤立地看待开发人员、经理、某个重要用户的观点几乎没有价值。你要找到全局的视野和尽可能多可选择的观点，就一定要直接跟使用你的设计的😼人对话，但不依据他们的话来理解问题。把自己想象成一位试图帮助公民的政治家吧，你会只相信你的智囊团的说辞吗？你必须从常规思维中跳出来才能把事情做好，并看到事物的真相。

另外一🍰个挑战是：你接触用户的方式将影响到你从他们那里获取的信息类型，除非受过专门训练，每个人都会无意中使自己的问题带有偏向性，这样你将得到不可靠的信息。

观察和理解用户ꦗ的技能非常复杂，这也是网站和软件团队🌱需要可用性工程师的首要原因。你可以学习一些基础知识，但如果打算做一些重要的工作，还是要请专业人员。

在研究你要解决的问题时，记住以下几点：
• 谁是我们的用户？他们有哪些技能和知识？
• 我们可以用哪些不同来源的数据去理解他们的背景？
• 他们使用我们的产品或者网站要完成什么样的任务或目标？
• 我们做了哪些假设，如何论证？
• 我们掌握了那些数据来源？（可用性研究和启发式评估都是很好的起点）

如果你对回答这些问题没信心，说明你还没准备好，其实这些信息都是开发工作的基础。在继续工作之前要确保对你的用户有准确的理解，如果这꧟是你的第一次尝试，就尽可能多地找到你的竞争对手及其用户信息吧。

分析

作为开发人员,有非常多的问题有待你解决，也有非常多的新功能有待你添加，因此仅仅有创意是不够的。考虑到投资人的要求与它们🐈有限的资💙金支持，很多问题是不值得去解决的。有时解决一个问题会引发两个新问题，所以好的判断意味着从可以做的事情中理出应该做的事情。收集完数据后，下一步迈向成功判断的工作就是分析了：你需要筛选信息并且评估出需要在哪里投入精力。

将从用户和其他来源收集到的信息过滤成针对特定问题的一句话，这些话应该从用户的角度来书写。举个🎃例子，𒆙“将编辑框加宽至十五个字符”不是一个问题，而“输入比较长的文本很困难”是，这中间的区别是戏剧性的。不要同时定义问题和解决问题的方法，这样你会经常忘记真正的问题。在这个例子中，其实有很多种方法解决输入长文本的问题，包括改变搜索框的形状等。但是如果你太局限，你会看不到其他的选择 --- 好的工程即是去理解这些选择。

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

如果你是在一个团队中工作，将所有的问题及其支持信息做成一个小清单吧。

一些表述问题的例子：
• 网站各部分的跳转很困难
• 软件加载时间过长
• 安全错误信息难以理解
• 注册项太多，导致用户常常放弃
• 在页面索引里很难找到特定产品

注意用户问题和功能性bug是有区别的，我用两个特征来判断：
1) 因为代码错误而没有实现预期的功能
2) 有明显且简单的方法解决

例如：下拉菜单无法显示五十个州是一个bug，而用户无法找到下拉菜单ꦐ或者使用它来达到目标是一个用💧户问题。

综合：列表和优先级

列出条目，按优先级把各条整🏅理出来是件有意思的事儿。如果没有🔴明确的优先级，团队成员往往会对哪些事需要做哪些事儿不需要做产生争执。经过调查后设置优先级的工作应该比较容易，但也往往是个挑战。

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

制定优先级𒈔需要有能力去评估三项标准：时间进度、团队和商业运营。事先确认的项目日程安排有可能限制了工作的规模和程度，对于一个小开发周期，需要重写一半的基础代码就是有问♉题的。

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

在你的项目里可能还有其他考虑，但不管怎样，它们需要在整理列表之前明确下来。考虑的越清晰，对所有问题进行排序的工作就越简单。如果在整理列表中途加入了新的约꧟束条件，你就不得不重头开始再做评估。

一旦整理出了一份列🅘表，你就可以分出哪些是重要的问题，那些是次要的，哪些问题需要优先解决则取决于日程安排。

有哪些有趣的事儿？

当目标和有待解决的问题都确定后，有趣的事儿就开始了，根据工作框架和决策，工程师和设计师可以放开手脚解决这些问题，在调研不同可选方案以及开始原型和易用性研究等方面规划好时间来审视它们是否实际提升了用户体验。然后在日程表上确定某个点来评估这些可能的解决方法，找出值得全力投入开发的一些点，剩余的就可以放弃或者放到未来版🅷本中去做啦。从制定某种标准，通览整个进程这一点上来讲，它和明确问题的步骤是相似的。

要重点提出的是确定问题的前期工作是开放的，而不是限制性的。只要你着眼于解决重点问题，你就一定会找🐟到正确的方向。如果你的问题陈述足够宽泛，就会有很多极具创造力和创新的方法来。就算你不能完全解决一个重要的问题，部分的解决正确的问题也要好过全面地解决错误的问题。