项目失败的教训

以下是Franco提供的十条逆向建议，并解释了为何要避免它们，而应该如何去做：

1. 如果你想失败，那就不要理解最终用户——70%的IT项目失败都是由于用户可接受性出了问题。
2. 如果你想失败，那就相信开发人员能够正确的做出设计决定。开发人员被逼迫着做出糟糕的设计，因为他们的工作量是由其所完成的功能数量决定的。当一个项目将要接近截止日期时，开发人员就会关注于删除功能而不是从最终用户的角度思考。
3. 如果你想失败，那就期望一个银弹式的设计。好主意是值得肯定的，但一个伟大的功能建议不应该取代优秀健康的UI设计。
4. 如果你想失败，那就满足所有人的需求。“如果一个公司试图为所有人创造一个产品，那么最后不会适用于任何人”。
5. 如果你想失败，那就启动项目然后忘却。在项目启动之后，产品需要更多的迭代以不断完善。
6. 如果你想失败，那就不要定义成功。不定义成功意味着不知道目标是什么。
7. 如果你想失败，那就避免冲突。冲突未必是坏事，因为“没有冲突就没有进步”。当屋子里的所有人都赞同某种看法时，那么就要提高警惕了。
8. 如果你想失败，那就相信不需要推销自己的想法。利益相关者应该努力在组织内部推销自己的想法，但不要期望仅仅因为来源于你就会被接受。这需要准备回答类似下面的问题：投资回报率如何？优点是什么？为什么要现在做？如果不做会怎么样？
9. 如果你想失败，那就追求完美。不应该一开始就把所有都计划好，并期望现实会按照计划行事，因为变化无处不在。
10. 如果你想失败，那就重视过程甚于产品。这条建议可以改写为：“如果你想失败，那就不要冒险”。我们可以非常重视开发过程，但是“按时生产一个糟糕的产品毫无意义”，通过迭代的方法构建满意的产品更轻松一些。

以下是Waloszek总结的糟糕用户界面18黄金法则，提供了负面的例子：

1. 让客户忙于那些不必要的工作——让用户在某些控件填写数据，随后又提示他们不能在那里输入数据（比如，一个应用让你在假期或周末填写数据，随后又提示说你不能在那些天工作）。
2. 不遵守标准——不把菜单条目放置在通常的类别和位置上（比如，在“编辑”菜单中放置“保存”按钮）。
3. 让软件运行缓慢——有无数的可能性导致软件运行缓慢。比如，你可以在每个用户输入之后包含长时间的验证或者切换。或者你可以强制用户浏览一连串的对话框。
4. 尽可能地使用缩写，特别是在有足够空间显示完整单词的情况下——使用“dat.”而不是“date”，“Tolky”而不是“Tolerance Key”，“NxOb”而不是“Next Object”，等等还有很多......
5. 使用技术型语言指导用户——使用UTF-8格式发送URL（需要重启，在MS IE的高级设置里）
6. 隐藏在用户看来重要和常用的功能——把其藏在用户永远找不到的菜单里。
7. 让你的应用只支持鼠标——绝不提供任何键盘快捷键。
8. 使用你的应用成为一项挑战——即使用户操作会导致严重的后果也不加以提示。
9. 脱离最终用户——许多用户有许多的选择，你只提供一个。这倒是可以更快更简单的实现。
10. 宣扬糟糕的示例——只需要听从本页的其他黄金法则就可以实现。
11. 花费大量精力设置糟糕的缺省参数：与用户的期望背道而驰，缺省配置极其糟糕、令人厌恶、无用——反正由你决定——在web表单上做缺省设置使用户收到不想要的新闻或者广告，散布他们的地址等等。
12. 在每次系统重新恢复之后都破坏工作上下文——在系统重启之后取消之前选择的屏幕元素。
13. 忽略让用户更方便的功能——让他们很辛苦——当用户需要在列表中添加条目时，只允许他们在列表末端插入条目，然后再让用户把条目移动到正确的位置。换句话说，没有提供额外的功能用于直接将条目插入到目标位置。为了增加点情趣，当用户直接把条目移动到目标位置时，应用提示一些伪造的错误，然后把条目插入到末尾。
14. 不让用户中断消耗时间和/或消耗资源的进程——偷偷启动一个备份或者索引进程，让用户难以取消，也就是说，无视用户的鼠标点击和键盘操作。
15. 应用不合逻辑——添加一个准备某操作的按钮使用户确认可以做该操作了。这里有一个真实例子：在许多电子邮件应用中，“转发”按钮实际上没有真正执行转发操作，而是做转发之前的准备工作（因为，我们不得不提供收件人地址）。
16. 时不时的来一次系统崩溃或者让应用僵死——让编辑器或者编辑域在用户事先未预料的情况下僵死，以至于用户还没有来得及保存他们的工作成果，而频繁保存的习惯会浪费宝贵的系统资源。
17. 尽可能的阻碍用户输入——页面加载也是阻碍用户输入的好机会。在等待的时候，用户可能会与室友聊天、读报或者盯着空屏幕发呆。
18. 阻碍用户输入，即使没有必要——阻碍用户在图片浏览器更新缩略图的时候输入就是一个很好的例子——没有任何理由阻止用户滚动、选择图片或者发起操作。