Indigo 的数字镜像

界面优先：很多应用程序的开发都从程序的设计开始，这是一个糟糕的方 式。在你编码之前先设计好界面。编码是开发一个程序最繁重的一部分工作，它是昂贵的并且在确定之后难以改变的。而设计相对廉价许多，只需要简单得草稿就行 了，当然你也可以用HTML代码来实现你的原型界面。界面优先的另外一个原因——它就是你最终产品的样子，大家都能够看到你将做出什么样的产品。从界面开 始你能够感觉到产品是存在的，容易使用吗？能够解决什么问题？大家能够在开始就找到这些答案，你也能够灵活的去调整程序。

核心式设计： 从最核心的页面开始设计，然后延伸开去。这意味着在开始你并不需要去考虑页面导航条、页脚内容、颜色和LOGO之类的，你应该将精力花在核心功能的页面 上。例如你设计一个BLOG程序，BLOG文章的显示就是最重要的页面，而不是旁边的分类、页头导航和用户的评论。只有当页面上最核心的元素设计完成了， 你才应该去考虑那些相对次要的内容，然后一步步地向边缘移动，这就是核心式设计。它和那些框架式设计正好相反，先是整体结构，最后才是核心部分。核心式设 计让你把时间花在真正需要关注的地方，你能够尽早的与设计师和开发人员交流，而不是等到所有的部分都设计好了再去。

界面的三态：对于你设计的每一个功能页面，你都必须注意它的三种呈现状态。

• 常规界面：用户在正常使用时操作的界面，上面已经有用户的使用数据显示。
• 初始化界面：当用户第一次来到时看到的界面，上面没有任何用户的数据。
• 错误界面：它会在产生任何错误的时候出现

初始化界面： 忽视你的初始化界面将是一个非常严重的错误。它是用户使用你的程序所见到的第一个界面，失去这个第一印象你将再也无法挽回。设计师们通常会把页面模版的所 有地方都填充上数据，任何一个列表、表单、缝隙和剩余空间都不会放过，他们认为这样看上去很不错，程序会工作得很正常。在大多数的情况下，程序都是出于缺 乏数据的状态的，只有用户长期的使用才会慢慢的填充数据，其实用户都会通过初始化界面的好坏来决定是否使用这个程序。然而很多开发者和设计师都忽略了这一 点，因为他们从来都是在一个充满了数据的测试界面下工作的，很少会扮演一个新的用户进入系统去看看。一个成功的初始化界面应该包括下面的内容。

• 显示快速的教程和帮助性内容
• 给一个填充了内容的示例图片
• 向用户解释如何开始以及最终会看到什么
• 回答初次使用者的基本问题，我看到的是什么？我应该如何做？

记住，一定要给你的用户一个好的开始，留下一个好的印象！

防止错误的设计： 在线的操作难免不会产生错误，这一点是我们应该认同的。不管你是多么仔细的实际你的程序，经过多少次的测试，用户总是会碰到问题。那么如何处理这些不可避 免的问题呢？使用防止错误的设计。就像预防事故的驾驶那样，开发者需要坚持不懈的寻找那些容易让用户混淆和受挫的地方，并且要提供更加友好的错误的提示页 面，给用户清晰的引导，提高用户体验。

关联性胜过一致性： 应该用按钮还是链接，这取决于要执行的动作；日历是用列表显示还是用网格显示，这取决于它会显示多长时间；是否全局的导航链接要出现在所有的页面上，是否 每个页面上都要显示搜索框或者相同的页脚，这些都取决于是否真的需要。当用户需要的时候再给他，用相关联的操作来提示用户，去掉那些没有必要的，不要被那 些生硬的一致性原则束缚了你的设计，用户的体验永远是第一位的。

书写也是界面设计： 伟大的界面是写出来的。你在界面上的用词和像素、图标与字体一样重要。你需要关注那些阅读你的界面的人们想知道什么，以及如何简洁又清晰的表达。你要使用 与你的用户相同的语言来表达，千万不要用那些技术化的词汇，不要像工程师之间的交谈那样，用户看起来会觉得是天书的，尽量使用短小而亲切的句子来表达内 容。几乎在所有的地方文字都是设计的一部分，例如图标旁边的文字、表单的示例、带标签的按钮，还有操作的步骤说明，所有这些都是界面的设计。

统一界面： 将管理界面整合到前端的公共界面中去，所谓管理界面，通常都是用来设置一些参数，管理数据和用户的。因为大部分的精力会花费在前端的界面设计，所以可以将 管理界面前置，不要分隔成两个不同的操作界面。例如一些常用的编辑、添加、删除操作，放在前端的界面里比较合适。如果你同时维护两个不同的界面，其实是一 件痛苦的事情，就像同时交两份税一样，所以尽可能的减少界面的数量，这样才能提高界面的质量。

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)

尽可能少的雇人：其实不需要过早的让你的团队规模膨胀，也许今后也不 需要。如果真的需要100个人的话，你也不用一次性的把他们都招回来，从来都没有一个有效的办法让很多人快速的融入到一个工作环境之中的。过多的人员会让 你为培训而头痛、时常发生的个人摩擦、无法避免的沟通障碍，大家各自有各自的主张，总之是十分麻烦！所以，尽可能的避免雇人，同时想想其它的办法来解决人 手不足的问题。看看负担是否过重，那件事情是否需要去实现，或者用其它的办法来解决，总之最后再考虑增加人手。GE的前任CEO Jack Welch在雇用一个人之前都会考虑一下如果没有这个人情况将会怎样，因为通常都不会向你所想象的那样需要那么多的人。

炒掉不合格的人：除了看简历、了解雇用人员的工作经历之外，试用也是 一个非常重要的过程。在你正式录用一个人之前，你应该给一个小项目让他去尝试一下。你可以了解到他是如何处理这个项目、如何沟通、如何工作的，如果你有机 会在屏幕前看看他的编码和设计，你将会了解到更多的细节，这些对于考察一个人是否合格非常有用。

不要只说不做：用来考查一名技术人员，OpenSource是一件非 常棒的礼物，如果他参与过开源项目（国内好像太少了），你很容易就可以从中可以看出他的能力和对技术的热情，那些只说不做的应聘者很快就会在你的眼前漏出 马脚。你可以通过下面的条件来判断一个开发人员的能力：工作质量、对于文化的看法、热情程度、完成度和社交能力。37Signals 只雇用参与过开源项目的开发人员，要知道真正热爱开发的人才是你的团队所需要的。

雇用能力全面的人：对于一个小的团队，更多需要的是能力全面的多面 手，而不是某一个领域的专家。你需要一个善于书写的设计师，一个有设计能力的开发人员。每个人都有系统架构的能力，善于组织自己的思维，并且能够和客户沟 通。因为小的团队经常需要快速的改变决策方向，所以你的团队成员也必须有很强的学习能力，能够快速的适应决策的变化。

热情是不可能伪造的：你所需要的并不是一名技术专家或业界名人，通常 第一个跳槽的就是这类人。对于你来说，一个快乐的能力稍逊的人要比一个经常抱怨的专家适合的多，因为热情是不可能伪造的。你应该雇用那些充满热情的人，不要你费心就能够独立的完成任务的人，厌倦了大公司那种官僚和缓慢节奏的人。当然，如果他们想你所想、恨你所恨，如此志同道合，那就再好不过了。

你需要“语言大师”：如果你正在为录用那个人而举棋不定，选择最善于 书写的那个。不管他是设计人员、开发人员、市场人员还是销售人员，写作能力才是最重要的。有效与简洁的文字会带给你高效简洁的代码、设计、邮件、即时通讯 和更多的好处。一个善于书写的人并不仅仅是会用词，他们善于沟通，他们让事情更容易被理解，他们知道那些细节被忽略掉了，他们有清晰的思维，而这些正是你 所需要的。

Clear writing leads to clear thinking. —— Michael A. Covington, Professor of Computer Science at The University of Georgia

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)

尽可能的整合：很多公司将设计、开发、阮文撰写、支持和市场划分为不 同的运作部门，这样做得优势是更加的专业化，但是这种隔离似的划分会让每个部门陷入到自己的信息孤岛之中。因此对于一个小的团队，要尽可能的整合人员，取 得沟通中的平衡，不要让你的团队迷失在繁杂的沟通与交流里面。你可以尝试让你的设计人员做一些阮文撰写工作，也可以让开发人员做一些客户支持，当然最好的 情况就是雇佣能够胜任多种工作的能人了。

提供独立的时间：不要让你的团队成员在工作的时候被打断思路，因为要 重新集中精力需要花费很多的时间。这也就是为什么很多人希望在深夜或者是清晨工作，这些时段通常都不会被人打扰。在独立的时段里面，思路会更加灵活、效率 也会比平时高很多。你可以尝试把早上10点到下午2点作为独立时段（午饭时间除外），这段时间里面团队成员不需要沟通，没有会议、电话、即时通讯、邮件的 干扰，只有静心工作，通常这样的工作方式会比整天的忙碌要更有效率。

会议就象毒药：尽可能的避免会议，如果你突然有个想法需要和大家交流 一下，可以先尝试即时通讯或者邮件沟通，因为非面对面的交流思路会更加严密一些。会议会打乱你一天的正常工作流程，一群人在一起通常会为一些无关竟要的想 法讨论半天（跑题），而且总会有些人会为一些愚蠢的问题浪费大家的时间。如果实在是要开会，那么坚持下面的原则：

• 将时间控制在30分钟之内
• 只让相关的人员参加（与会人员要尽量少，不然就成了演讲报告）
• 一定要有清晰的议题

寻找并庆祝小小的胜利：在开发过程中作重要的东西就是成员的热情与动 力，阶段性的胜利是激发团队斗志的最好方法。如果你把胜利的周期拉的太长，成员的斗志会被消磨，也就不可能开发出优秀的产品。如果你处在长达一个月的产品 周期里面，争取每周来个阶段性的成功。当然最好的情况就是每天都能够有个小小的胜利，你可以通过下面的方式来界定阶段性的成功：

• 实现一个小功能
• 增强一个现有的功能
• 重写一些帮助文字来降低客户支持的成本
• 移除一个你不需要的功能特性

持续性的成功会让你的团队保持最高的开发热情！

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)

尽快让你的软件运行起来：一个可以运行的软件是激励你团队最好的兴奋 剂，还能让你暂时不去考虑那些无法使用的功能。这就意味着你要从最简单的功能开始，绕开细节的纠缠，用快速的方式去取得阶段性的成功，如果你做到这一点 了，你就能够更加精确的控制过程，这远比那些完美的规划、框架以及HTML页面的演示来的实在得多。一个看的到的可以运行的程序，可以让你和客户能够更清 晰的理解自己需要什么、在做什么，还能够避免讨论方案所浪费的时间。

使用迭代的方式开发：不要期待你开始的设计都是正确可行的。随着你的 系统的逐渐完善，它会告诉你如何改进才是正确的，你必须要接受开发期的变化，其实它带来的是系统的进化。因为Web程序不像那些传统的软件，需要封版发 布，你可以在任何时候对你的程序进行调整，一遍一遍的直到满意为止。系统运行起来之后，用户的反馈将对你的设计和开发更有帮助。

从想法到实现：这里介绍的是37Signals的方法，从头脑风暴到草图到HTML页面，最后再是代码实现，他们用这个简单的流程来实现每个功能和产品。

• 头脑风暴：先收集众人的想法，大家一起找出自己的需求，产品可以做什么，这里不需要制定太多的细节，只需要给产品一个轮廓，后面你可以慢慢再去完善它。
• 画出草图：这是你表达想法的最廉价的方法，用简单的线条把你想象中的轮廓画在纸上，系统的结构、功能的流程和界面，这些都是尝试性的表达，所以不需要浪费过多的时间去争论对错。
• 实现HTML预览：用网页来实现你勾勒的界面，让所有人都能看到它的样子。这是你还不需要写任何程序代码，仅仅HTML+CSS就足够了，这样可以让你的设计与编码并行。
• 编码实现：当你觉得前面的过程已经足够表达你的想法了，就可以开始编码了。

上面的过程可以针对具体的功能和目标重复进行，以迭代的方式直到完成所有功能的开发。

避免过多选项：大家都希望通过选项来满足用户可以订制系统的需求，这 样看起来系统很灵活，给了用户更多的自主性，但同时也给用户带来了更多的困惑，他们会为满屏幕的选项而头痛。用默认的习惯和最佳设置来取代那些不必要的选 项，这样或许对用户更友善一些。还有就是过多的选项会给你的程序带来过多的代码和界面，也意味着有可能产生过多的BUGS。

以”搞掂”为目标：当你实现一个目标就意味着你可以继续 向前进，不要为了某些错误的决定而停止前进。碰到问题你应该及时回头，而不是想办法去完成一个无法完成的任务。每一次目标的实现就像是一次小战役的胜利， 值得庆祝和纪念。让你的团队保持这种持续前进的士气，去完成那些正确的目标。要记住一点，好的执行力要远远比好的想法和目标重要。

真实测试：在真实的环境里面测试你的程序，获得真实的数据和反馈，再用这些来改进你的程序，因为实验室里的检测永远无法反映出实际的情况。所以要提前让用户体验你的Beta版本，你可以在用户使用的同时持续的完善功能，及时获得用户的反馈才是最重要的事。

缩短计划周期：制定一个需要数周或者数月才能完成的计划几乎是个不切实际的幻想，因为你根本就不可能预知这段时间内会发生什么事情。所以缩短计划 周期，将时间分片，你可以把一个需要12周的计划分解成12个只需一周完成的小计划；把需要30-40个小时完成的任务细化到6-7个小时能够完成的每日 任务。同样的理论也适用于问题的解决，你可以把一个大的问题分解成若干个小的部分，然后逐一解决。

Smaller Tasks and Smaller Timelines —— Gina Trapani, Web developer and editor of Lifehacker, the productivity and software guide

999999">学习笔记仅供交流参考，需要了解完整的内容，还请大家购买《Getting Real999999">》的原版:)