导航是网页设计中不可缺少的部分，它是网站访问者获取所需内容的快速通道和途径。导航让网站的层次结构以一种有条理的方式清晰展示，并引导用户毫不费力地找到并管理信息，达到有效传递。同时，导航一般位于网页的中上部分，也是视觉中心的区域内。在保持其合理的功能作用的同时，一个好的导航设计，往往能够成为整个网页设计的点睛之笔！
一个设计师在布局和整体规划网页设计时，导航总是一个重要的元素。我们会思考，导航以什么形式呈现？是否能够最大程度地发挥其梳理网站结构、有效传递信息的功能？是否能够烘托和配合整个页面的设计风格？是否能够别出心裁润色和体现该网站的特点又不影响其功能性？是否能够精益求精成为整个网页设计至关重要的一笔？那么，就让我们一起分享和浅析一下一些让设计师们花费心思精雕细琢的导航设计吧。
导航的设计会根据网站的基本类别、属性和各自特点而有所定位。在这里，我挑选了一些非系统、门户等类型，有明确特点、用户定位、产品及品牌特色的品牌类、专题类网站。对于这些网站来说，导航的设计将突破我们常见的横向长条导航或者竖式导航，会更加有意味、趣味和玩味，是能让设计师们尽情拓展设计创意和思维的“有点儿意思”的导航设计！
材质类的导航，是润色导航、增加导航意味最常用的设计方法。在有特殊定向和用户指向的网站设计里是广被设计师们使用的手法。这种快速、简单、效果直接的设计方式，能够迅速将产品的特性和设计师的巧思呈现出来。并且材质类的导航设计往往都可以不必打破导航的基本形态，能够很好的保持导航的功能性，页面排版的整齐感。因此可以在固定的网页原型的结构和位置上，灵活地表达产品的特性。设计师们可以随心所欲雕琢内部的材质，从而打造不一样的意味导航，成为整个页面的小小亮点。
如何让一个页面看起来如身临其境融入了该网站产品的世界？那么就要让用户的视觉体验真实地感受到该产品特性的存在。这个时候，一个普通呆板的导航，远远不能满足页面的设计需要。即使产品图片再诱人，一个毫不融入氛围的冷冰冰的导航，在页面上不仅让人失望更加破坏了应该有的气氛。所以，越来越多的设计，让导航成为了烘托、增强网页及产品氛围的振奋一笔！拟物类的导航，就像变色龙，在不同定位的网页设计中，捕捉和适应环境的特点，从而化身为环境的一部分。拟物类的导航，可以是抽屉，可以是布条、可以是树木，可以是任何你能想到和创意出来的东西！打破一切既定的规则，不必一定要是长条四方，不必一定要是整齐划一的排版，拟物类的导航可以将设计师的能动性发挥到极点！这样的导航设计，在整个网页中可以达到另外一层的功能性，那就是辅助提升产品给用户的强大视觉认知度，还未见其产品的详细信息，你就能提前感受到它是干什么的，有什么样的风格，有什么样的追求。让导航不仅仅只是导航！
若问到导航是什么样的，大多数人都会立刻浮现出几种基本的形状和样式，顶部的横栏、侧边的竖栏。即便是高矮胖瘦、颜色各异、材质各异，大多数的导航都不会跨出基本的界限。那么导航是不是一定要遵守形状这个“规矩”呢？答案肯定是否认的。用户虽然习惯了导航的“规矩性”，但是另类形态的导航设计却无疑给了用户们一个新的视角，原来导航也可以“没规没距”！那么是否可以随意改变导航的形态设计呢，答案也是否定的，设计师们始终都要记住导航的根本属性和用途，让导航始终都不能脱离它在页面设计中的核心作用。如果你是一个大胆的设计师，又有新颖的设计理念和产品诉求，那么不妨尝试做一次大地调整，换个形状设计导航！
有雷厉风行抢风头的导航哥，也会有为人低调注重和谐的导航们。在某些网页设计中，需求的导向性会要求将导航一定程度的削弱，从而来突出产品的主体内容。那么对于这部分的导航设计，设计师们该如何取舍呢？是简单地罗列文字？还是将导航舍弃在边角的位置？如何才能使得被削弱的导航仍然不失设计感，甚至能够辅助主体内容的突显？这个时候，对导航的处理和设计就能更加体现出一个设计师对宏观大局的把控，以及对细节局部的掌控，让局部服从整体，但又不是粗糙对待，反而精致得恰到好处！削弱并不是不需要设计，和谐并不是隐藏和消失。很多优秀的设计作品，在处理这类情况时，通常将导航和网页主体背景进行关联性的融合。从色彩的恰接、风格感受、背景图片的关联、线框等多方面都可以进行处理和设计。让导航自然地呈现，仿佛为主体的一部分，又退而求其次，把更多的视觉焦点留给了主体内容。从而完美地保持其功能性，又能与整体页面“和谐共进”！
文 / Marty Cagan 译 / 林航，王烨，吉绚
Marty Cagan是享有世界声誉的产品管理专家，曾担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作和经验的总结，分享了探索产品的流程和方法。
产品开发宁缺勿滥
有没有见过这样的情形？开发团队刚刚完成手头上的项目闲了下来，可产品经理一想到程序员们自在逍遥，就怎么也坐不住了。为了让他们马上开始新项目，产品经理没日没夜地制作新项目的产品需求文档（PRD），以求速成。这样的事情在产品团队里时常上演，成为产品失败的罪魁祸首。
开发团队就像“嗷嗷待哺”的婴儿，胃口特别大，却分不清哪些该吃，哪些不该吃。只要产品需求文档到位，不论产品好坏，他们就马不停蹄地开始新一轮的产品开发。后果可想而知。
追根溯源，这种现象的产生是因为产品开发团队里的程序员聘金不菲，公司不乐意看到他们闲着，只有“物尽其用”，才会让公司觉得安心。可聪明反被聪明误，这种短视的行为，给产品的失败埋下了祸根。这种行为还会掩盖开发团队真正的价值。开发团队被公司异化成生产代码的机器，而不是共同探索、打造出成功产品的“战友”。
只让开发人员负责软件的开发，明显低估了他们的价值。正确的做法是先通过产品探索定义出基本产品，确定产品是有价值的、可用的、可行的，然后再交给程序员去开发。强迫开发团队满负荷工作的公司，显然是管理理念出现了问题：代码好不等于产品好。当然，这种现象和企业文化也脱不开关系。
不可否认，好的项目经理确实能保证产品的交付进度。但不能因此就盲目地让项目管理在公司里唱主角。进度安排合理、资源得到了优化配置不意味着产品就能取得成功。通常，我会建议项目经理在产品探索阶段安静地坐在“观众席”上，等到确信设计的产品值得开发了，再粉墨登场率领团队开发产品。采取这套方案后，收效不错。但如果产品探索阶段，团队里缺少能一统全局的主帅，这套方案就不适用了（在今后的文章中我再讨论这种现象）。
如果开发团队闲了下来，而新一轮产品探索还没完成，该怎么办？其实选择很多。
让开发团队利用“余量（headroom）”完善软件架构。
让开发团队参与产品探索活动。
产品经理给开发团队预留一个月左右的任务。这样即使手头的项目卡了壳（比如原型测试中，用户的反馈意见很糟糕），在想到新方案之前，你的开发团队都有事可做。
开发团队无事可做，还有可能是项目团队里开发人员和产品经理及设计师的比例失衡造成的。如果开发人员过多，那么产品设计团队永远跟不上进度，开发团队必然会“档期”不满。
要记住，产品经理的使命是确保团队开发有价值的产品。让开发团队盲目开发未经验证的产品，也是一种浪费。
产品探索计划
为了不让程序员闲着，产品经理把本该花在产品探索上的时间都花在了赶写产品需求文档上。可这样的产品探索毫无价值。时间再紧迫，也不能牺牲那些创造价值的关键步骤。而有些公司非常重视产品探索，却没有对这个过程做出合理的规划，不能保证每天做的都是有用功，自然无法快速开发出基本产品。所以，宝贵的时间就这么白白浪费了。
产品探索规划是否详细，取决于公司的文化氛围和产品探索人员的能力。很多公司（特别是大规模公司）中，团队需要一个产品探索计划，明确项目必须实现的内容、需要的资源，并给出粗略的进度安排。
我将列出常见产品探索计划的组成部分。但这不是模板，不要照着里面的内容生搬硬套，做些不需要做的事情。我列举的每个部分分别解决不同的问题，你可以根据你要解决的问题，选择合适的探索计划。作为产品经理，你要审查这个计划并确保团队按计划执行。
核心探索团队：确认项目的产品经理、首席设计师和主程序员，并且确保这些人员在探索产品的过程中随叫随到。
探索扩展团队：谁将给这个核心团队提供支持？你是否需要视觉设计师？你需要原型设计师的协助吗？需要可用性测试资源吗？需要有特定开发经验的开发人员吗？需要QA团队提供人手吗？需要市场部的人员支持吗？
关键参与人员：这个项目必须得到谁的批准（即谁拥有“否决权”）？此外，还可以写上你认为能够对这个项目发表独到见解的聪明人名单。
客户发展计划：这个项目需不需要特约用户？如果需要的话，谁是牵头人？如果不需要的话，你会请哪些客户（用户）验证你的产品理念？
主要风险：这个项目的主要风险有哪些？你将如何解决这些问题？
用户研究工具：这个项目需不需要创建一些人物角色？需要做网站检查和商业分析吗？
用户测试计划：你打算如何让实际用户测试产品？初步测试计划是什么？
产品战略（愿景）：是否需要在制定项目细节之前，考虑项目所在领域的长期发展？
支持文档的程度：核心团队需要在以下方面达成一致意见：在这个项目中，需要哪些额外文档、需要做到什么程度，包括用户故事、用例、测试计划等。
制订计划只是产品开发中的一步，更重要的是保证产品探索确实是朝着满足基本要求的产品方向努力。另外，将这两步结合起来后，什么时候能真正开始构建产品也是关键。这个过程的监督工作包括两个部分。
首先，我认为，产品的负责人（如产品经理或首席用户体验师）需要对这项活动尽到监督责任，他们积极的监督会对定义产品起到积极的作用。这里要说明一点，这里的“监督”指的是每周至少询问一次产品探索团队下面这些问题。
你这周与什么样的客户和用户进行过比较有效的沟通？
你从你们的讨论中了解到了什么？在你了解它们的过程中，有什么事情使你感到惊讶吗？你有了什么新的见解？
你是否遇到了潜在关键点？【注：参见http://www.svpg.com/your-business-plan-is-wrong】
根据你所了解到的内容，下一次你会进行哪些新的尝试？
开发人员最后一次评估产品设计和客户反馈信息是什么时候？
开发人员在项目可行性和可能的解决方案上有什么意见和反馈？
用户认可这种想法的价值吗？如果不，那么为什么他们不认可？
目前原型最主要的可用性问题有哪些？你打算如何纠正这些问题？
从可行性的角度来讲，开发人员最关心原型的哪些方面？针对这些问题，你有哪些应变措施？
最后，你认为在两周之内完成一个满足最低要求的产品的可能性有多大？如果有困难，那么团队是应该继续努力还是考虑开发其他产品？
其次，产品经理也有监督其他事务的职责，比如在项目管理方面，需要确保产品探索计划的实施情况，做好开发的一切准备工作。具体来讲，这包括保证开发团队有足够的资源开展工作，明白项目时间限制及做好时间管理，确保开发者、产品管理者和设计者之间的良好沟通，根据计划从整体上推动进度，以及确保项目中的时间都被有效利用。
项目经理的确可以督促大家完成项目，但要确保先确定基本产品，而不能仅写些开发文档。
不管怎样实施计划，如果公司很开明，允许你在探索产品上花时间，而不是仅仅撰写需求文档，那么我希望你不要浪费产品探索中的每一天。如果你已经花了很多工夫，但仍感觉到很难开发出好产品，你应该尝试制订产品探索计划。
产品探索日记
产品经理和设计师们放弃原有的线性、瀑布式的开发流程，转而采用我倡导的这种更具迭代性、探索性的流程后，通常需要花一些时间才能适应它的快节奏，掌握产品探索的韵律。
这篇文章将再现产品探索的情景，让大家了解其核心内容。
因为产品的开发过程涉及的因素太多（如产品类型、投入的精力等），做这样的概括并不容易。我尽量使用比较典型和普遍的情景。为了覆盖尽可能多的要点，我构思了以下情景。
第一周
周一
为了明确商业目标，我和项目的主要负责人一起进行了产品的机会评估与讨论。
与项目的首席设计师及主程序员开第一次讨论会，制订出产品原则。
紧接着，我们进行了头脑风暴，想到不少好点子。
与首席设计师一起创建第一轮关键人物角色。
周二
和首席设计师继续优化前一天完成的用户角色，确定主要和次要角色；讨论用户使用产品的情景，并列出主要情景和次要情景。
与用户研究员一起明确潜在特约客户名单；通过电话联系特约客户，筛选候选人。
周三
我、首席设计师以及主程序员一起检查前一天完成的产品原型，看它是否符合我们最初模拟的几个用户情景。讨论非常激烈，原型远比我们设想的要复杂。
我们回顾之前提出的产品原则，再一次明确了重点，之后大幅简化了产品原型。
周四
我、设计师和项目的主要负责人一起查看产品原型。这个原型还在初期，但是已经包含了三个最重要的使用场景。通过讨论，我们意识到我们和项目负责人的想法有些脱节，因为双方对用户的理解不同。
继续电话联系目标客户，确认6家公司成为我们的特约客户。最棒的是，他们似乎对我们的产品将解决的问题有极大的兴趣，因为他们的公司都还没有找到好的解决办法。如果我们的产品能够解决这个问题，那么他们会非常看好我们的产品。
周五
我们和主程序员一起评估修改后的原型。他对主要功能的可行性持谨慎乐观的态度，并提出了两个重要的问题。第一，其中一项功能的开发成本可能颇高，而且执行速度很慢。他需要点时间研究这个问题。第二，他认为我们可以省去一些收集数据的工夫，因为我们需要的数据可以从数据库提取。
咨询有关法律人士，向他展示原型，确保模型没有和法律相冲突的地方。他们认为其中一处需要进行详细评测，检查结果会在下周给出。
第二周
周一
早上，我、首席设计师以及项目负责人一起拜访第一个客户，请四位潜在用户试用产品原型。这次测试收获颇丰。可惜原型的表现与我们的期望还有很大的差距。我们发现自己此前对用户的理解还很肤浅，项目负责人的理解也不完全正确。现在我们对用户的理解又进一了步，而且达成了基本的共识。
回到公司后，我们立刻讨论如何修改原型。我们简化了自以为重要的场景，修改了术语，去掉了那些根本不会被用到的高级功能。
周二
主程序员在研究完高风险的技术问题后，确定他之前的担心是有道理的。他提出了新的可行方案，可以实现同样的效果，而且开发难度更低。于是我们根据他的意见对原型进行了调整。另外，他确认了我们本来要收集的数据在数据库中都能找到，这就进一步简化了原型。
下午我们拜访了另一位客户，请三位用户参与了测试。今天的情况比昨天要好很多。我们仍然不确定原型的交互设计是不是足够好，但至少用户能够完成主要任务了。之前去掉高级功能的这一步棋确实走对了，因为用户并不关心它们。我很高兴我们坚持了以客户为中心的价值观。有两位测试用户希望我们第一时间通知他们产品完成的消息。
周三
与首席设计师、主程序员碰头，讨论目前的成果和接下来的工作。主程序员又提出了一项针对关键流程的优化建议，恰好解决了首席设计师面临的几个棘手的问题。
我和首席设计师向视觉设计师提出了我们对视觉设计的几点想法。经过先前的用户测试，我们认为必须将产品中的两个基本概念用某种方式清晰地传达给用户，并且给出了关键状态和用户可能做出的动作。视觉设计师说她已经有了可以表达这些概念、提升产品价值的想法。她会在接下来的一两天内给我们一些具体的方案，之后我们可以为这些方案提建议。
周四
我们仍然在努力定义基本产品。我们相信已经把最关键的功能都涵盖在内了，但不确定到底要不要再加上一个比较酷的功能，不知道它是不是必需的。我们计划暂时从模型中删除这个功能，看看测试的效果如何。
下午，我们拜访了另一位客户，请三位用户测试了产品原型。原型的可用性已经很棒了，但删除了之前说的那个功能后，原型没有得到用户的热烈响应。我们又展示了之前的版本，这次他们表现出了极大热情。我们得出的结论是，这个功能确实非常重要。我们的原型中已经尽可能地删掉了所有不需要的部分，但仍然能激发人们的购买欲望。我们去除了很多高级的功能，简化了关键流程，应该能在主程序员估计的时间内完成开发任务。
周五
我、首席设计师与可视化设计师一起讨论了她设计的方案，我们特别喜欢其中的一个方案。稍做调整后，我们把它用在了原型上。
主程序员根据现有（也可能是最终）的原型估计出了产品开发的周期。这个时间可以接受，并且有风险的技术问题已经排除。
第三周
周一
我们将包含最新的产品原型展示给项目负责人，并且总结了最终的产品设计（包括最新的界面设计），以及所有来自测试客户的反馈。她很喜欢这个产品，希望旁观下午的测试。她也想就价格和定位询问客户的意见。
下午，我、首席设计师以及项目负责人带着最终原型去见另一位客户。我们请4~5位用户进行了测试，得到了理想的反馈——没有遇到使用问题，对功能和价值的反响也很好。所有用户都很期待这款产品的问世，也愿意推荐给朋友或者同事使用。
周二
继续完善原型，并将这些天来了解到的关键点录入项目维基。
向给更多的项目参与人展示了产品原型，包括法律顾问、市场部、产品管理和工程方面的副总。他们提出了一些问题，但都认可用户测试的反馈。
周三
我、首席设计师以及主程序员碰头，讨论如何撰写产品文档，方便开发人员、测试人员、部署人员开展工作。
我和首席设计师分工撰写文档，我们将各自负责的部分写到项目维基里，并添加了一些对产品原型的链接和注释。
看完以上日记，希望你能明确以下10点。
在项目开始时，确定你对目标有清晰的理解（产品机会评估）。
从产品探索最开始时就建立和首席设计师、主程序员的密切合作。
注重真正的协作交流，而不仅仅满足于写那些没人看的文档。
设法验证自己对产品的假设，不要纸上谈兵，尽快判断哪些假设正确，哪些不正确。
记住要确定基本产品。
在产品探索的过程中不断保持和相关部门的信息互通，向大家展示不断更新的产品原型，让他们了解进度。
不要把时间花在为开发人员写文档上，等到产品确定后再写。
