l 设定你的起跑线
先满足自己的需求、从自己的投资开始、限定时间和预算、设定一个假想敌
l 保持精简
保持小规模和低成本、开发三人组、做回你自己
l 学会把握优先级
抓住最主要的想法、在初期要忽略细节、找对你的用户群、以后再考虑扩展性、让你的软件保持风格
l 功能选择
先实现最关键的功能、从说不开始、做你可以控制的事情、给用户最大的自主权、问问用户不需要什么
l 执行过程
让你的软件尽快地运行起来、用跌代的方式开发、从想法到实现、真实测试、缩短计划周期
l 团队组织
尽可能的整合人员、提供独立的时间、避免会议、庆祝小小的胜利
l 关于雇员
尽可能的少雇人、炒掉不合格的人、雇佣能力全面的人、不要只说不做、你需要”语言大师”
l 界面设计
界面优先、核心式设计、注意初始化界面、防止错误的设计、文字也是界面、统一界面
l 关于编码
小巧的软件、为快乐而编码、倾听你的代码、使用开放的格式
l 关于文档
不需要冗长的功能说明、给我讲述一个故事、使用真实的内容、拟人化的产品
l 服务定价
提供免费使用、避免长期的租约、制定有弹性的价格策略
l 产品推广
好莱坞式的产品发布、建一个强大的推广网站、利用BLOG来宣传、以教育的方式推广、跟踪用户的访问记录、取一个有吸引力的名字
l 用户支持
感受用户的痛苦、零培训、快速解答、坚持自己的原则、将失误公诸于众
l 产品推出之后的工作
每月更新、持续更新、不要拿”beta”当借口、不要对”bug”一视同仁、关注你的竞争对手
二、 设定你的起跑线
少量构建：在传统的模式之中，尤其是软件开发，要击败竞争对手就是要做比对手更多的功能，好像冷战时期的军事对抗赛一样。你会为这样的行为付出高昂的成本，而且总是处于跟随竞争对手的状态。因此开始你伟大的计划之初，要坚持少量构建原则！用少而精来击败竞争者，我们需要的是：
- 少量的功能特性
- 少量的用户选项
- 少量的人员与精简的企业结构
- 少量的会议
- 少量的承诺
满足自己的需求：创作一个软件的最好形式就是解决自己的需要，自己才是最好的观众，知道什么重要、什么不重要。能够满足自己的需求，才会有热情投入，同时也以为之你会真正的去使用它和关心它。这种热情同样也会感染其他有相同需求的用户。
从自己投资开始：不要一开始就想着拿别人的投资。与人钱财，替人消 灾，这是常理。大多数投资者都向快速的获取回报，不可预期的决策与外部环境将会影响你的计划。随着硬件与带宽成本的降低，启动一个小型的Web应用服务的 投入其实是很少的，初期的费用自己能够承担就自己来了。还有一个好处，那就是“约束激发创新”。
限定时间与预算：一定要在预算之内准时地上线，不要花费过多的时间和 金钱在一个问题上面，你可以合理的调整你的规划来保证时间和预算。区分好功能的重要性，什么是一开始应该有的，什么是需要增强的；如果你希望完全按时，按预算，按规划的来实施，你不可能创造一个完美的产品；能够应时而变是关键，你的规划需要有弹性，不要把它制定的太完美和长远，它需要经验来逐步完善。
设定一个假想敌：某些时候，明确产品能做什么的最好方法就是明确他不能做什么。设定一个假想敌，不是去模仿它增加更多的功能，而是寻找两者之间的不同点。37Signals 的Basecamp 就以微软的Project软件为直接的竞争对手，而且这个对手还异常强大！简化复杂的功能，突出项目成员的协作性，满足那些希望快速简便的用户的需求。大多数情况下，用户都会对产品进行比较，你需要给你的用户讲述一个他们希望听到的故事（如何去实现目标），而不是阐述你的产品有多么的优秀和快速。
保持小规模：物体越大，它需要的能量越多，这个自然界的定律同时也适用于商界。在Web开发领域也一样，你需要能够容易并且低成本的转变，因此你必须要会控制自己的规模。
规模通常在下列情况下膨胀：
- 时间过长的契约
- 雇佣过多的人员
- 长期不变的决定
- 为了开会而开会
- 过程繁重
- 投资（物理上或者精神上的）
- 硬件、软件或者是技术的瓶颈
- 私有的数据格式
- 用过去的观点来约束未来
- 时间过长的规划
- 官僚！！
同样，也会因这些情况缩减：
- 合时的思考方式
- 能够胜任多任务的团队
- 在约束的环境下工作
- 少量编码
- 少量特性
- 精简的团队
- 简单
- 减少交互的接口
- 使用开源软件
- 使用开放格式
- 开放式的组织架构可以减少决策上的错误
保持低成本的转变：记住，灵活的转变将是你最好的朋友，这一点尤其是用户互联网行业。如果你的竞争对手能够比你更灵活的转变，你将处于劣势；如果他的转变成本更低，那么你将会输掉竞争。你的小巧才是那些巨头们内心深处的恶魔，你可以在一天之内完成一个大型团队需要数周才能完成的转变。廉价与快捷才是一个小型团队制胜的秘密武器。
开发三人组：只用三个人的小组来开发产品的1.0版，这是你最精简的团队组成，他会满足你初期的人力需求，并且拥有足够灵活性。一个开发人员、一个设计人员（注重交互设计）和一个多面手（组织管理、策划推广与公共关系），不过前提是你必须找对合适的人，优秀的人才是不会花费无尽的资源的。如果你感觉人力不足，那么就应该尽早的调整任务的优先级，要记住的就是一定要保证第一个版本的小巧与紧凑。
“沟通的成本是团队成员的人数平方倍！” —— 梅特卡夫定律（Metcalfe’s Law）
拥抱约束：有限的条件会激发你创造更好的解决方案。我们总是感觉资源不足，时间不够、人力不足、资金短缺，这是好事，它会使你更加的专注。37Signals 在开始 Basecamp 开发的时候，只有一个设计、手头还有其他客户的工作、一个远在丹麦的开发人员（还有7小时的时差）、一个小团队并且没有外部投资。面对条件苛刻的限制，他们将任务分解成小块，按不同的优先级来完成；同时减少人与人之间的会议，利用IM与EMail沟通，迫使自己快速的向目标前进。
做回你自己：很多小公司都将自己扮演成大公司那样去运作，这是一个致命的错误。个性化与友善是你与那些大公司最大的不同，小公司可以享受没有成规与官僚的约束，拥有更多的自由，而且更加容易亲近你的用户。利用BLOG来取那些官方的发言与公告（当然很多大公司也开始这样做），让用户能够实时的融入进你的产品开发，并感觉你在及时地响应他们的反馈。保持小巧的最好的一个原因就是减少内部的沟通流程，它将大幅降低你的成本。
抓住最主要的想法：在你开始设计与编码之前，你需要知道你做产品的目的——产品定位。它为什么存在，与竞争者有什么不同。产品的定位会指导你的决策，让你坚定路线。你的产品定位应该尽量清晰，最好能够用一句话来简单描述。同在大家都把这样的描述追加在产品名的后面！例如37Signals的产品：
Basecamp - Project Management is Communication
很清晰的定位，抓住项目沟通的重点。去掉传统项目管理系统中那些繁琐的表格、状态、报表，而将产品的重点定位在消息、评论、任务跟踪与文件共享上面，让客户能够即时的了解到项目的状态并获取到相关的资源。因此，为你产品的大方向做个定位，它会让你每个细节的决定都很明确。
在初期要忽略细节：我们都为细节疯狂过。虽然细节决定成败，但是细节也不是决定成败的唯一条件。你会发现停滞、意见不一、会议和延时也会磨灭你的团队的积极性，并降低成功的机率。你可能经常会为一个按钮的设计耗费一整天的时间，而且这些还经常出现在你产品开发的初期，其实有充足的时间让你的产品变得完美，就是不要在早期做这些事情。尽早的让产品工作起来，再去完善那些细节。
Work from large to small. Always! —— Patrick Lafleur, Creation Object Inc. (from Signal vs Noise)
当问题发生时再去处理它：把要浪费时间在还没有发生的问题上。你是否真的需要担心10万用户的压力当你还需要2年的时间才能达到这个数字，或者一下子就雇佣八个工程师当你只需要三个的时候。Basecamp刚推出的时候还没有用户支付功能，他们在系统运行后花了一个月时间去实现。当你的系统出现由于用户增长带来的访问压力时（基础规划还是要做好的），你只需要真诚的向你的用户解释清楚，并且尽快在1-2周内解决，用户还是可以理解的，当然处理的速度要足够的快。
找对你的用户群：为你的产品找到核心市场，并想办法去解决他们的需求。客户的意见并不一定都是正确的，你需要分辨对与错，不要盲目的客户建议。还好互联网将这个过程变得前所未有的简单。如果你试图让所有人都满意，那么所有人都不会满意，这是真理！Basecamp最初将他们的核心用户锁定在设计公司，满足他们与客户之间项目沟通的需求，这样其他类似的用户群体也会来尝试他们的产品。所以Basecamp最终以狭窄的市场定位获得了成功。
以后再考虑扩展性：在开始你优先要考虑的是建造一个牢靠的可以运行的产品，而不是去考虑它的可扩展性和使用服务器集群。一个伟大的程序只需当它在非常流行的情况下再去考虑其扩展性，否则你将浪费能量、时间和金钱在那些永远都不会发生的事情上面。因此你最关键的问题不是去考虑如何扩展，而是在何时去扩展。
让你的软件保持风格：很多人常说一个好的软件是如何如何的灵活，有多少多少特性，其实那是胡说！好的软件有它的定位和特点。人们用软件不是来欣赏功能的，而是要实现自己的目地。一个很好的例子就是wiki的设计，它去掉那些无用的文档修饰和可视化的编辑，将协同写作的特性发挥到极致，这种特性让wikipedia获得了巨大的成功。因此，不要期望让所有的人都来用你的软件，除非他们的目的和你的产品定位相同。
宁要半成品：不要将那些单独看起来很棒的功能随便添加到产品中去，除非你想开发一个质量打折的产品。你需要知道那些是真正核心的，将它们列成一个特性清单（Feature Table），想象你的产品将会是什么样的，然后将这些功能分半实现。也就是先实现一个拥有主要功能的半成品，除去那些无关的特性。
先实现最关键的功能：忽略那些无关紧要的功能，这是实现一个伟大产品的先决条件。就像那些优秀的设计师和开发人员，他们并不一定拥有最好的技术、有灵巧的双手、或者能够熟练的使用Photoshop，而是他们知道如何去分辨那些是至关紧要的，那些是可以忽略的。不要将大量的时间花费在不重要的功能之上，如果你能够把握好这一点，那么你就一定可以创造出优秀的产品来。
从说不开始：当你承诺要实现一个功能，你需要从设计开始，然后是实现、测试，经过一个完整的产品周期，你最终把这个功能推出给用户，观察用户对它的反映，并倾听用户的建议。每一个功能你都必须付出精力和时间，但并不是每一个功能都能够得到用户的认可。所以说那些来自用户或者是自己的新功能建议，应该把它记下来而不是立刻去实现它，然后给出我们现在不会实现这个功能的答复。你应该尽量的让你的用户相信现在的功能足够满足他们的需求，你要让用户喜欢你的产品是因为它不会让100个毫不相关的功能来迷惑他们，要让用户忠诚于你现有的功能，然后期待新的功能！
发现隐藏的成本：在你开始计划一个新的功能时，你需要分析清楚那些潜在的隐藏成本。当37Signals决定在Basecamp中加入一个会议功能时，它需要牵扯到地点、时间、与会人员、日历集成和相关的文档，许多原先并没有的新特性会因为增加一个功能而产生。还有那些不容易被人注意到的界面预览、推广形式、相关的法律条文、客户支持等等。有时候一个新的功能会像滚雪球那样将你的成本越滚越大，所以每一个功能都需要慎重。
做你可以控制的事情：你有能力免费的为每个用户提供1G的存储空间吗？仅仅是因为Google为他所有的用户提供了1G的邮件空间。或许你应该从100兆的开始，也可以对你的空间进行收费，这一切都应该量力而行。记住，你的底线是你提供的产品和服务必须是你可以控制的，这样容易兑现给用户的承诺。你所做的任何事都应该是你可以支撑的，包括组织、战略和资金上的。
给用户最大的自主权：不要强制约束用户的行为，让你的产品实现最基本的概念，然后鼓励用户按照自己的想法去使用并解决问题。如果你总是认为你能够为用户考虑的很全面，任何一步操作你都想得很周到，这样不仅限制了产品的灵活性，也束缚了用户的思维，同时还会带来更多产品BUG与使用障碍。所以将你的基本功能做好，让用户在你所规划的框架之下能够自由的完成自己的任务。
忘掉用户的功能需求：用户会希望你的产品拥有他们想要的任何功能，你基本上会被这种功能请求给淹没！在前面已经提及过，这时你最好的回应就是说“不”。对于那些功能请求，你只需看看就可以扔掉了，当然你不能直接向用户表现出置之不理的态度！其实用户会提醒你什么是最重要的，如果一个需求真的值得被记住，用户会反复的提及它直到你无法忘记为止。虽然有些粗暴，不过这也是一个行之有效的办法，当大多数用户反复的提及同一个功能需求的时候，你确实应该将它列入功能计划表了。
问问用户不需要什么：大多数的软件调查和问卷都围绕着需要什么功能为中心，其实可以反过来思考一下。问问用户什么功能是可以去掉的，如果去掉之后会怎么样，那些功能是他们从来没有用到过的。让用户来裁剪功能，可以有效地限制无用功能的膨胀。最后引用一句名言：
Innovation Comes From Saying No! —— Steve Jobs, CEO, Apple (from The Seed of Apple’s Innovation)
尽快让你的软件运行起来：一个可以运行的软件是激励你团队最好的兴奋剂，还能让你暂时不去考虑那些无法使用的功能。这就意味着你要从最简单的功能开始，绕开细节的纠缠，用快速的方式去取得阶段性的成功，如果你做到这一点了，你就能够更加精确的控制过程，这远比那些完美的规划、框架以及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
尽可能的整合：很多公司将设计、开发、文档撰写、支持和市场划分为不同的运作部门，这样做得优势是更加的专业化，但是这种隔离似的划分会让每个部门陷入到自己的信息孤岛之中。因此对于一个小的团队，要尽可能的整合人员，取得沟通中的平衡，不要让你的团队迷失在繁杂的沟通与交流里面。你可以尝试让你的设计人员做一些文档撰写工作，也可以让开发人员做一些客户支持，当然最好的情况就是雇佣能够胜任多种工作的能人了。
提供独立的时间：不要让你的团队成员在工作的时候被打断思路，因为要重新集中精力需要花费很多的时间。这也就是为什么很多人希望在深夜或者是清晨工作，这些时段通常都不会被人打扰。在独立的时段里面，思路会更加灵活、效率也会比平时高很多。你可以尝试把早上10点到下午2点作为独立时段（午饭时间除外），这段时间里面团队成员不需要沟通，没有会议、电话、即时通讯、邮件的干扰，只有静心工作，通常这样的工作方式会比整天的忙碌要更有效率。
会议就象毒药：尽可能的避免会议，如果你突然有个想法需要和大家交流一下，可以先尝试即时通讯或者邮件沟通，因为非面对面的交流思路会更加严密一些。会议会打乱你一天的正常工作流程，一群人在一起通常会为一些无关竟要的想法讨论半天（跑题），而且总会有些人会为一些愚蠢的问题浪费大家的时间。如果实在是要开会，那么坚持下面的原则：
- 将时间控制在30分钟之内
- 只让相关的人员参加（与会人员要尽量少，不然就成了演讲报告）
- 一定要有清晰的议题
寻找并庆祝小小的胜利：在开发过程中作重要的东西就是成员的热情与动力，阶段性的胜利是激发团队斗志的最好方法。如果你把胜利的周期拉的太长，成员的斗志会被消磨，也就不可能开发出优秀的产品。如果你处在长达一个月的产品周期里面，争取每周来个阶段性的成功。当然最好的情况就是每天都能够有个小小的胜利，你可以通过下面的方式来界定阶段性的成功：
- 实现一个小功能
- 增强一个现有的功能
- 重写一些帮助文字来降低客户支持的成本
- 移除一个你不需要的功能特性
持续性的成功会让你的团队保持最高的开发热情！
尽可能少的雇人：其实不需要过早的让你的团队规模膨胀，也许今后也不需要。如果真的需要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
界面优先：很多应用程序的开发都从程序的设计开始，这是一个糟糕的方式。在你编码之前先设计好界面。编码是开发一个程序最繁重的一部分工作，它是昂贵的并且在确定之后难以改变的。而设计相对廉价许多，只需要简单得草稿就行了，当然你也可以用HTML代码来实现你的原型界面。界面优先的另外一个原因——它就是你最终产品的样子，大家都能够看到你将做出什么样的产品。从界面开始你能够感觉到产品是存在的，容易使用吗？能够解决什么问题？大家能够在开始就找到这些答案，你也能够灵活的去调整程序。
核心式设计： 从最核心的页面开始设计，然后延伸开去。这意味着在开始你并不需要去考虑页面导航条、页脚内容、颜色和LOGO之类的，你应该将精力花在核心功能的页面上。例如你设计一个BLOG程序，BLOG文章的显示就是最重要的页面，而不是旁边的分类、页头导航和用户的评论。只有当页面上最核心的元素设计完成了， 你才应该去考虑那些相对次要的内容，然后一步步地向边缘移动，这就是核心式设计。它和那些框架式设计正好相反，先是整体结构，最后才是核心部分。核心式设计让你把时间花在真正需要关注的地方，你能够尽早的与设计师和开发人员交流，而不是等到所有的部分都设计好了再去。
界面的三态：对于你设计的每一个功能页面，你都必须注意它的三种呈现状态。
- 常规界面：用户在正常使用时操作的界面，上面已经有用户的使用数据显示。
- 初始化界面：当用户第一次来到时看到的界面，上面没有任何用户的数据。
- 错误界面：它会在产生任何错误的时候出现
初始化界面： 忽视你的初始化界面将是一个非常严重的错误。它是用户使用你的程序所见到的第一个界面，失去这个第一印象你将再也无法挽回。设计师们通常会把页面模版的所有地方都填充上数据，任何一个列表、表单、缝隙和剩余空间都不会放过，他们认为这样看上去很不错，程序会工作得很正常。在大多数的情况下，程序都是出于缺乏数据的状态的，只有用户长期的使用才会慢慢的填充数据，其实用户都会通过初始化界面的好坏来决定是否使用这个程序。然而很多开发者和设计师都忽略了这一点，因为他们从来都是在一个充满了数据的测试界面下工作的，很少会扮演一个新的用户进入系统去看看。一个成功的初始化界面应该包括下面的内容。
- 显示快速的教程和帮助性内容
- 给一个填充了内容的示例图片
- 向用户解释如何开始以及最终会看到什么
- 回答初次使用者的基本问题，我看到的是什么？我应该如何做？
记住，一定要给你的用户一个好的开始，留下一个好的印象！
防止错误的设计： 在线的操作难免不会产生错误，这一点是我们应该认同的。不管你是多么仔细的实际你的程序，经过多少次的测试，用户总是会碰到问题。那么如何处理这些不可避免的问题呢？使用防止错误的设计。就像预防事故的驾驶那样，开发者需要坚持不懈的寻找那些容易让用户混淆和受挫的地方，并且要提供更加友好的错误的提示页 面，给用户清晰的引导，提高用户体验。
关联性胜过一致性： 应该用按钮还是链接，这取决于要执行的动作；日历是用列表显示还是用网格显示，这取决于它会显示多长时间；是否全局的导航链接要出现在所有的页面上，是否每个页面上都要显示搜索框或者相同的页脚，这些都取决于是否真的需要。当用户需要的时候再给他，用相关联的操作来提示用户，去掉那些没有必要的，不要被那 些生硬的一致性原则束缚了你的设计，用户的体验永远是第一位的。
书写也是界面设计： 伟大的界面是写出来的。你在界面上的用词和像素、图标与字体一样重要。你需要关注那些阅读你的界面的人们想知道什么，以及如何简洁又清晰的表达。你要使用与你的用户相同的语言来表达，千万不要用那些技术化的词汇，不要像工程师之间的交谈那样，用户看起来会觉得是天书的，尽量使用短小而亲切的句子来表达内 容。几乎在所有的地方文字都是设计的一部分，例如图标旁边的文字、表单的示例、带标签的按钮，还有操作的步骤说明，所有这些都是界面的设计。
统一界面： 将管理界面整合到前端的公共界面中去，所谓管理界面，通常都是用来设置一些参数，管理数据和用户的。因为大部分的精力会花费在前端的界面设计，所以可以将管理界面前置，不要分隔成两个不同的操作界面。例如一些常用的编辑、添加、删除操作，放在前端的界面里比较合适。如果你同时维护两个不同的界面，其实是一件痛苦的事情，就像同时交两份税一样，所以尽可能的减少界面的数量，这样才能提高界面的质量。
小巧的软件：随着代码量的增加，你软件的复杂度也会随之增 加，每一次调整和变动的效果都会叠加，所以让你的程序代码尽可能的保持简洁。那么抵制这种代码复杂化的最好方法就是只做小巧的软件，它也意味着更少的功能、更少的代码和更少的浪费。小巧的软件让你放弃对未来功能的规划，将重点放在解决现在的问题上。为什么呢？因为你所担心的未来的扩展通常不会立刻到来。开发小巧的软件会给你带来如下的好处：
- 容易管理
- 少量的代码让你的维护变得简单
- 你可以更灵活的改变功能（代码修改的成本降低）
- 更少的BUGS和更少的客户支持
让你的开发人员敢于向不合理的功能需求宣战，他们知道如何简单的实现一个合理的功能，用最好的方法。
为快乐而编码：一个快乐的程序员会是一个高产的程序员，选择那些能够让你的团队保持激情的工具，而不要选择那些符合业界标准的陈旧的工具。你的成员需要有趣的、富有挑战的、能够让人感到自豪的，能够在8小时的工作内充分感觉到快乐的方式来工作。就像 37Signals 选择了 Ruby 作为他们的开发语言，他们用最大的热情推动了 Rails 框架的发展（在此之前Ruby还默默无闻）。当然不仅仅是开发语言，一个他们喜欢的平台、应用或者是框架，都能够给他们带来快乐。只有快乐的程序员才会写出简单的、可读的代码，他们拥有清晰的思路和一流的解决方法。
倾听你的代码： 优秀的代码是简洁而清晰的，倾听你的代码，它会告诉你哪里存在缺陷、如何去实现新的功能、以及哪种是更适合你的开发模式。你的新功能真的需要数周的上千行的编码吗？你的代码会时刻提醒你，注意他的复杂度和膨胀的速度。你应该尽量用简单的方法在一个小时之内实现需要用十小时才能搞定的复杂思路。遵循简单和廉价的原则，避免那些复杂的实现，留意你的代码，它是你思路的最好监督者。
为你的代码买单： 通常我们理解的债务都是金钱上的，其实也有很多其他的形式，例如你的代码和设计。就像你必须拿出你收入的一部分来纳税一样，在你的代码和实际交付之后，你也必须花时间在他们的修改和调整上面。那些糟糕的代码和不合理的设计会成为你以后维护的巨大债务，你应该只把时间花在代码的小小调整上，而不是将主要部分的开发重新来过。所以你需要认真地对待你的每一行代码和任何一个细节上的设计，不要让他们成为你维护的负担。
使用开放的格式： 你应该使用那些开放的协议和方式来封装你的数据，例如RSS或者标准API的形式，不要为了隐藏而使用一些私有的协议，这样对谁都不好。人们可以通过 RSS来按照自己喜欢的方式查看数据的更新，第三方的开发者也能够使用你的标准API来为你写扩展的应用，这样你就可以拥有一个沟通便捷和接口灵活的系统。千万不要认为RSS只是用作Blog或者是新闻的更新，任何数据的更新同步都可以通过它来实现，还有API，尽量使用标准的格式来封装，例如XML- RPC或者是REST协议。其实你已经有很多成功的例子可以参考了：Google Maps API 和 Flickr API ，网络上有数以百计的扩展应用是通过他们开发的接口实现的，将你的系统开放给用户和开发者，你将会获得许多意想不到的收获。
不需要冗长功能说明：越是详细的功能说明文档就越像是一个空的幻想，你的产品只有在开始设计了、编码了，并让用户使用了，那才是他最终的样子，不然永远都只是纸上谈兵。
- 功能说明只是缓和剂，他让每个人都有设计产品的参与感，但是无法帮你决定如何选择与暴露成本，这些才是开发一个伟大产品所必需经历的过程。
- 功能说明会导致意见统一的幻想，大家讨论制定功能，并且记录在纸上，最终都只是看到纸上写的那些功能列表，但是并不清楚每个人对那些功能的理解。
- 功能说明会强迫你在所知甚少的情况下来草率的决定一个功能