查看文章 |
Scott Berkun写的文章往往从实用角度出发，比如本文： 摘要：关于网页及界面设计中批判性思维的讨论 批判性思维是设计和工程学的核心。在很多领域中，从电影导演到项目经理，从程序员到设计师，分辨哪些事物是有价值的都是一种非常重要的能力。这种能力是可以靠学习获得的，只是由于它独立于技术领域，经常被我们所在的行业遗忘。不过很明显，通常在工程、设计及可用性上犯的大多数失误都是由于全局的决策失误造成的，(因此)开发人员和设计师都应该了解批判性思维的方法与流程。在网站或软件开发中，批判性思维在三个方面显现：规划，灵感激发和项目管理。这里我们重点讨论制定规划，今后我再去撰文介绍另两个方面。 在开发过程中最常见的错误是不能正确的定义问题。如果目标是模糊的，就无法界定问题是否已经得以解决。就算目标是正确的，也有可能与当时的设计情形不相符而导致错误的目标。制造精良的机枪不可能帮你修理瘪掉的轮胎，因此上述两中错误是与技术的精准无关的。如果你不能避免这两种错误，即便是世界上最好的程序员和设计师也不可能成功。你可以写出最棒的代码，创作出最精彩的设计，但如果你不能正确解决问题，你的努力是白费的。 理解问题 另外一个挑战是：你接触用户的方式将影响到你从他们那里获取的信息类型，除非受过专门训练，每个人都会无意中使自己的问题带有偏向性，这样你将得到不可靠的信息。 观察和理解用户的技能非常复杂，这也是网站和软件团队需要可用性工程师的首要原因。你可以学习一些基础知识，但如果打算做一些重要的工作，还是要请专业人员。 在研究你要解决的问题时，记住以下几点： 如果你对回答这些问题没信心，说明你还没准备好，其实这些信息都是开发工作的基础。在继续工作之前要确保对你的用户有准确的理解，如果这是你的第一次尝试，就尽可能多地找到你的竞争对手及其用户信息吧。
分析 将从用户和其他来源收集到的信息过滤成针对特定问题的一句话，这些话应该从用户的角度来书写。举个例子，“将编辑框加宽至十五个字符”不是一个问题，而“输入比较长的文本很困难”是，这中间的区别是戏剧性的。不要同时定义问题和解决问题的方法，这样你会经常忘记真正的问题。在这个例子中，其实有很多种方法解决输入长文本的问题，包括改变搜索框的形状等。但是如果你太局限，你会看不到其他的选择 --- 好的工程即是去理解这些选择。 对每个问题描述提供支持信息，包括：什么样的用户有这样的问题，这个问题是怎样被提出的，甚至是潜在的解决之道。也许只有特定部分的用户遇到这样的问题，或者它只发生在某种情境里。尽量多描述一些来让别人信服或者挑战你的假设，如果你是唯一看到这些支持信息的人（例如可用性研究、市场研究等），让别人也得到这些信息。你对这些资源越公开，别人的质疑也就越少。 如果你是在一个团队中工作，将所有的问题及其支持信息做成一个小清单吧。 一些表述问题的例子： 注意用户问题和功能性bug是有区别的，我用两个特征来判断：
综合：列表和优先级 提炼是整理列表的最佳方式，团队中的某个人根据他或她对整个项目的感觉通览列表并排序：第一条是最重要的，最末一条是最不重要的，然后团队的其他成员应该通览这份摘要形式的列表并且在上面加注修改意见，以便起草人员修订更新，在某一阶段就可以做出决定并制定决策了。如果你是单独工作，最好找一个你信任的人来检查你设置的优先级，就像团队工作那样，一个聪明人整理筛选之后给出的各种意见能带来最好的思考。 制定优先级需要有能力去评估三项标准：时间进度、团队和商业运营。事先确认的项目日程安排有可能限制了工作的规模和程度，对于一个小开发周期，需要重写一半的基础代码就是有问题的。 团队的组成情况和环境决定了完成什么样的工作。这个团队有其他的资金支持吗？有没有设计师或者可用性工程师？有哪些网页或UI设计技能？最后也是最重要的，是商业上的考虑：这个项目的预期收益目标是什么？竞争对手是谁？解决某些特定问题你有什么优势？你有哪些合作关系可以利用？ 在你的项目里可能还有其他考虑，但不管怎样，它们需要在整理列表之前明确下来。考虑的越清晰，对所有问题进行排序的工作就越简单。如果在整理列表中途加入了新的约束条件，你就不得不重头开始再做评估。 一旦整理出了一份列表，你就可以分出哪些是重要的问题，那些是次要的，哪些问题需要优先解决则取决于日程安排。 有哪些有趣的事儿？ 要重点提出的是确定问题的前期工作是开放的，而不是限制性的。只要你着眼于解决重点问题，你就一定会找到正确的方向。如果你的问题陈述足够宽泛，就会有很多极具创造力和创新的方法来。就算你不能完全解决一个重要的问题，部分的解决正确的问题也要好过全面地解决错误的问题。 |
