小站会根据您的关注，为您发现更多，
看到喜欢的小站就马上关注吧！
下一站，你会遇见谁的梦想？
微博：/imddcha&有朋友想一起管理小站的可以留言~~~
如何写一份交互说明文档
这让我想起来2009年自己在项目里也大力推行过交互说明文档（在下文中，简称为DRD），格式倒没什么限制，交互设计师自己写到界面上也行，单独文档成文也行，总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来，降低项目里的沟通成本和风险。今天整理电脑，
这将涉及到几个问题：
一. 什么是交互说明文档（DRD）？
所谓DRD即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。
在项目中，交互设计师的主要产出物可能依次是：site map，page flow，wireframes。有的大型项目前期，交互设计师有可能还会产出用户需求分析文档（与PD产出的市场需求文档不一样的是，URD更多侧重于对目标用户的需求分析）。
DRD则很少有人专门撰写。如果需要对交互设计进行说明，聪明的交互设计师往往会直接标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代修改来确保所有的交互设计意图最终得以呈现。
二. 为什么要写？
DRD非项目必需环节，一般情况下也不会为交互设计师专门留出相应的时间预估。没有这份文档，项目也会继续，但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话，项目的质量也会受到影响。所以写与不写，交互设计师需要做把握，时间被统一包含在&线框图&环节内&&如果你要写，请在评估时预留1-2天的时间。
那么，结合我过去的经历，谈一下此文档的必要性。
下图是一个产品开发项目基本的流程。
敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的FRD已经全部敲定，交互设计师再开始去画线框图，固然会减少沟通成本和返工风险，但是同时意味着交互设计师的很多想法不被采纳。如果产品经理再强一些，他甚至会在FRD里连原始的DEMO也一并绘制出来了，功能性的需求和界面交互的需求有时无法区分太清楚&&比如他会在FRD里直接要求每页条目40条，超过40条即分页。而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和&&所以，我们希望是和产品经理同时开始工作，在术业有专攻的时候相互补充。
同样，开发工程师也希望及早介入需求，在FRD并未确认的时候就了解需求，进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单（这个清单，大部分叫做UC，即USE CASE）,当这份清单由工程师需求分析师&&在过去，这个角色被叫简称为RA，但是目前已经取消此专门的职位，而是由开发工程师代表担纲此环节工作，为了便于描述，在此文里，我仍然将做这件事情的人称为RA&&交付给具体的执行工程师后，执行工程师基本上可以当作一条条的checklist开始高效工作，而不必再思考商业逻辑和需求。同样，测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试，这也是基于UC和FRD去撰写的。
所以，开发需求分析是个很重要的环节。那RA是如何来完成需求分析工作的呢？
前期介入，对PD进行开发需求评估支持；
参与每次的FRD评审会；
详细审阅FRD文档并不断与PD确认。
对于做这件事情的人来说，足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出，但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递，却存在很多问题。除了线框图，没有&详尽的说明性的文档&告诉他们。比如：
一方面，交互设计师对产品经理说：这块由我们来考虑，你的文档不必包含设计上的说明，这随时会调整的。
另一方面，线框图的评审有时会让RA参与，有时却没有叫他们。即使叫上了他们，他们也会发现交互设计的需求变化要比FRD变化快。另外，他们会认为UC不必写太多关于交互设计的需求。
在某个大型项目结束后，作为交互设计师，我进行了一些调研，听听这相关人员是怎么表述问题的：
开发部门的需求分析师：
每次变动都很痛苦，设计变了之后，我就要跟着改UC，改截图，有时候UED改了还忘了通知我们，导致UC有问题&&
页面交互的需求容易漏掉，因为UC里面不可能写太多交互方面的东西。
希望UED能够在提交HTML DEMO给RA时，能同时给出一份页面元素描述文档，需要介绍html demo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多，经常要和UED去确认这些内容。
产品经理：
前期RA和PD沟通过程中，有很多交互点点不能够明确，比如&默认显示多少属性值&，&标题显示多少字符&等。在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求，往往会&越俎代庖&，直接在FRD注明这种需求（对于交互设计师来讲，却又导致没有发挥余地）
走访了一些交互设计师后，他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑：
交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。我经历的一个项目，前端从头到尾更换了三个人，每次我都要重复去讲解下设计需求，讲得口干舌燥。而且做好后，还需要去验收。
DRD做为参考手册，一定程度上避免不吻合的问题发生。
即使有问题发生，也可以作为界面验收时的Checklist。将&我对A说，我对B说，A对B说&，转变为&A和B共同参考同一份文档&，减少沟通成本及信息不对称。
全程影响用户体验（一直到测试，都需要参照设计文档）。
可是以下问题都可以通过一份DRD来解决吗？
三. 写什么不写什么？
要明确文档的定位，从写什么与不写什么开始，划清DRD以及FRD的边界。
1. 不写视觉规范规格标注
这些说明与功能实现没有太大关系，主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图：
2. 不写功能实现逻辑。
如下图所示，作为DRD，你有必要传达清楚Browse by category区域的设计：链接的可点击性，链接的指向，字符与条目的数量限制等，但是具体二级类目排列是按产品数目排还是按字母排，还是人工运营，是FRD要解决的任务。
那么文档写什么呢？
举例子说明下：
1. 字符限制
提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚：1，是否要做限制？2，如果做限制的话，多少字出现截断？截断后是显示为省略号还是不显示？这个汉语设计相对简单，如果英文单词的话，因为是按字符，每个字符的宽度不一致，需要预估，另外还需要注明是整词截断还是词间截断。
2. 链接具体化
很多网站都有对搜索结果的筛选设计（refine search），比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。
类目和属性的不同如何处理
属性以及每条属性显示的属性值的条目是否有显示上的限制？
选中后，被选中的属性值是停留在原地，方便用户记忆，还是放到统一的位置，方便用户统一查看？其他未被选中的属性值是否消失？
要确保这些你设想中的复杂的交互逻辑能够被理解被呈现，除了一页页的线框图，你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互，有的指向你安排的并非PD安排的某个中间页面（page flow是交互设计师的职责）
3. 交互细节说明
相信我，我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图，我会研究用axure制作各种动态效果，达到它足够逼真呈现各种联动&&比如当你选择了下拉菜单中的某项时，页面上其他区域也发生相应的变化。可是，Axure不是全能的。即使能够表达出来，线框图交付出去，也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解，在事后再三检查并敦促修改。
但是当我尝试用下图对这块小小且复杂的区域进行详细说明后，事情变得简单多了。所以我用节省的时间去写了这份PPT.
又如，你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕，标注出与他工作相关的重点，存档并在遇到问题，找不到你人时随时参考。
5. 表单的校验
这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。写文档看似枯燥乏味，反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏，然后及时优化的。
6. 浏览器的兼容性要求
你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须战略性放弃某些浏览器，比如IE6.:D 。 这个决定谁来做？是前端工程师还是产品经理？还是你&&交互设计师？我认为决定权在交互设计师这里，但是他必须和产品经理达成一致，并与前端确认。你要求兼容的浏览器越多，标准越高，前端的工作量就会越大，测试的工作量甚至也会翻倍。
四. 什么时间交付呢？
Heidi的建议：尽可能与你的线框图同时交付，如果你先交付出线框图，在撰写DRD的时候，极大可能会发现问题或产生优化的想法。但是往往写DRD至少需要1-2天的时间，你不可能让所有下游等着你的工作。所以：
你可以交付出线框图供视觉先开始。视觉设计往往会先做风格定位设计，这和交互细节关系不大。
先交付出已经确定的线框图给前端，然后在1-2天DRD后，若有改动，与前端当面一一确认并一起交付。
五. 如何写DRD?
1. 选择最有效率的工具。
我的经验是这个工具最好能够提供清晰的目录导航结构，而且易标注。word确实是个写文档的好工具，不管你信不信，反正我是信了。
2. 建立固定的目录结构下图仅供参考。
具体里面的细节，就不一一罗嗦了。&
六. 重要的原则准备写DRD的朋友，请认识清楚此文档真正要解决的问题是什么？如果是解决沟通偏差、需求遗漏、沟通成本高的问题，你在项目里没有出现过这种问题，各合作方也反馈良好，那么这个文档就无需写。如果是解决对设计需求进行存档，便于后续人员改版时查看的问题，则又是另外一回事（经验证明，过去的DRD确实能够在改版时起到一定的帮助，在我离开原项目很久后，新的设计师还找我要过相应项目的文档，了解过去的设计逻辑）。
不是为了写文档而写文档（而是为了解决问题）
适合于项目、合作方（大项目有大文档，小需求有灵巧的解决方案）
工具不是问题（易传播，易标注，成目录即可）
模版不是问题，大家看明白就可
完美的文档无法取代面对面的沟通（评审会和讨论不会因为文档而减少）
需要在实践中不断改进
七. 谁来写？
我建议由交互设计师发起，但是由前端工程师进行修订，再传递给开发工程师。有很多需求，交互设计师只要求实现即可，但是他可能并不在乎是前端实现还是后端实现。前端工程师对DRD进行把关和修订，能够将设计语言转化为工程师能够看懂的语言，且能够划定与开发的实现边界。
八. 与其他产出物的关系&项目中交付物对应不同的使用角色，如下图所示：&
但是有个问题是，虽然DRD的目标受众有开发和测试，但是让开发工程师同时参考那么多文档是不现实的，所以仍然是开发工程师的接口人，也就是事实上的RA需求分析作为需求整合传递的角色，将商业需求和设计需求，传达给具体的执行开发工程师与测试工程师：
【总结】对于坚持撰写DRD的我来说，DRD的好处自己当然是明白的。但是并非所有人都喜欢写文档，都喜欢看文档。解决问题有多种方案，DRD只是其中一个。不过，当你因为设计需求传递过程中发生了问题，或者你的需求被理解偏差，或者你的需求被遗漏，或者你接手的项目改版，因为要梳理过去的设计逻辑焦头烂额时，你可以试试用DRD。如果使用过程中还是存在问题，那么就想想是否还存在别的解决方案吧～源地址：
硅谷称之为“常识”的网站设计过程原则
编者按：原文作者为Nir Eyal和Katy Fike博士。初级创业者应该搞清楚保持细致与步入主流的区别。以下是网站设计过程中的几个原则，硅谷的人也常不屑地称其为&常识（Normals）&。怎样介绍网站不用告诉用户你网站的&原理（how it works）&或&是什么（what it is）&，当然也无需告诉他们你的公司有多奇妙。你需要抓住重点，完整而明确地告诉用户你提供什么样的服务。新用户需要知道的是，你提供的服务在他们的生活中能起到什么作用。看一下Twitter主页是怎么向新用户介绍的。很简洁，&欢迎来到 Twitter。与你关心的人们一起，探寻变化的大千世界&。Facebook也类似，&联结你我，分享生活，尽在Facebook&。非常有才！现在初级创业者应该知道，采用明确的方式告诉用户什么时候使用、为什么有用。比如通过前面两句话我们就能知道，Twitter是用来探寻世界的变化，Facebook则是用来沟通和分享。确定呈现内容我们知道你可能会这样想：&Facebook与Twitter当然能用时髦语句来介绍自己，因为新用户在去他们的网站前，就已经知道他们的网站是做什么的&。没错，这也是问题的关键。现在的大部分人都是从他人那里听说某个网站，而你的工作就是满足这些人对你网站的期望，服务当然也是越快速、越令人信服越好。怎样才能让新用户爱上你的网站？ 这就需要给他们带来一段难忘的初始体验。建立一个引导式的过程，让他们感觉像是在进行愉快的散步，这样用户就会很高兴地了解当前服务能为他们做些什么。太多的网站在新用户注册后便甩手不管，期望他们自己去摸索和发现下一步该做什么。相反，应该把新用户看成正与你的网站约会，接着通过一个优雅、直观、使人愉悦的引导过程，让他们了解网站的操作流程。对初级创业者来说，学会开始、驾驭并让使用体验个性化都是极其重要的。初级创业者应该正确对待错误，不应害怕冒险或固化行动 ，措施应该灵活且可以在必要时撤消。例如，Twitter在引导用户使用这个服务的同时，也会询问他们的兴趣，然后立即利用这些信息为其创造个性化体验。完成这一过程后，无关的应用将被关闭，这样用户的面板上就只会显示那些自己可能感兴趣的功能选项。独立而不孤立许多网站还未赢得用户信任，就在用户登陆时要求获得他们的Facebook授权。这种做法可能会让新、老用户都产生疏远感。很多新用户的朋友也是网络新手，所以他们在网络中的沟通可能还并不多。另一些人则希望在Facebook之外的网站与他人建立沟通关系；或是更希望在没有Facebook的地方获得一丝&喘息&。另一方面，他们也不想让朋友知道自己正使用Faceboo帐号登陆第三方网站。在越来越多的垃圾信息威胁到自己朋友时，他们也对第三方网站授权变得越来越谨慎。在这种情况下，如果网站强制要求用户创建帐号，或在他们确认自己需要这个服务之前，让其使用Facebook帐户登陆，失去这些用户的风险将比获得的好处更大。这并不是说不应该给用户提供使用Facebook登陆的选项，只是建议先让他们爱上你的网站。对一个还未注册的用户来说，他即使没有朋友使用你的网站，网站对他也应该是有价值和吸引人的。例如，Pinterest允许未注册用户自由地浏览内容。用户只有在决定加入的时候，才会尝试使用Facebook帐户登陆。新用户加入后，不管有没有朋友在使用这个服务，他们都能立即开始发布内容、表达喜爱、发表评论等。化繁为简针对特定用户进行产品设计的关键是满足他们的特别需求。即使你的目标用户不是网络新人，当没有经验的游客来访问你的网站时，也要确保他们能有收获。直观的界面能让每个用户都喜欢，还要能够预测用户的下一步操作。让产品步入主流，它必须要简单，还能满足用户需求。用户往往不关心你的技术能做什么，而只关心你的服务能帮他们完成什么。还有大量尚开发的机遇等着那些能化繁为简的企业家去开发。如果不知是什么，或许你的爷爷奶奶也能给你带来启发。除非注明，本站文章均为原创或编译，转载请注明： 文章来自36氪
产品中图形语言规范化的意义与过程
现在随着互联网企业的发展与业务的拓展，随着时间的推移，一个公司的产品可能将越来越丰富多样，同样每一个产品随不断的功能完善和扩展，随着一个产品的&长大&产品内所需要用到的图标也必然会越来越多，这时候众多产品形象的呈现、产品内图标等视觉原素的表现，如何能与整个产品或公司的战略计划相适应，这时候在图形语言的视觉呈现，语义表达、识别性等层面就需要作一个全面细致的考虑了。我们来看几个典型的例子，回顾一下 Adobe 产品系列的成长过程， 从2005年 Adobe 收购了原最大的竞争对手Macromedia公司后，它的产品线得到了极大丰富， 而后在2002年Adobe确立了&Creative Suite概念后，后续的新产品持续推出，庞大的产品线以一种什么样的展现方式呈现在用户面前便成为了一项非常重要的课题。下图中我大致的列了一下Adobe产品logo的一个进化转变过程：
&产品阵容强大的Adobe帝国在CreativeSuite 3发布的时候为旗下全部产品Logo进行一个色环划分图，很好的呈现出各产品logo的色彩关系和一个完整的用色体系。&
我们再看一个例子，Apple公司在2010年和2011年先后将itunes与App store的Logo作出了比较重大的调整，到Max OS Lion版本时，两大平台级的产品新形象同时展现在用户Mac的Dock上。虽无准确的官方答案，但从一个是整个Apple产品资源应用来源和一个是娱乐内容来源的的两个具有类似性质的商业平台产品来看，它们显然是被Apple寄予相当大期望，在感观上看来，它们在被赋予更厚重、大气的形象这一改变，能够很好的服务于其公司的商业战略。
另外itunes 10的发布后侧栏的图标全部变成了单色，这一变化我认为是为了突出Store的资源核心区域，强调产品的平台性，和上述的分析一样，这个视觉表现层面的调整同样是为了整个产品的资源商业战略服务的。
那现在回到我们自己的产品，现在&我的阿里&作为一个网商用户的得力助手，用户的家，&我的阿里&内容与应用在日益的增长，系统越来越庞大，同样网站的视觉的图形语言的整理，解决原来积累已久的视觉表现&乱象&也日益的紧迫。在&我的阿里&视觉元素整理的第一步，众多应用图标是头一个切入点，我们从图标的含义，分类，尺寸规格、设计规则，风格表现等几个方面进行一个整体方向的规划，总结一套设计指南。&■ 在图标的分类上，我们将网站图标分为以下三类：一& 产品图标 （Logo）它是一款产品在品牌层面上的定义，指一个产品系统形象、定位和诉求的集中图形化表现，产品图标（Logo）起到产品或公司识别推广作用，通过形象的图形标识让用户认识、记住并熟识一个产品。
产品图标设计原则：1 能很好的诠释出该产品所承载的功能 和 所要向用户传达的产品价值和形象；2 图形容易被用户所记忆、熟知，而且有较强的排它性（不易和其它图标混淆）。二& 产品界面中的功能、工具图标在一个产品界面中，用概括精炼的形象来表示某一类功能或操作集合的功能性图形标识，常会有成组有规律的在某一功能模块中出现。色彩造型表现可以精致富有表现力，也可以简洁明了，质感单纯。
功能、工具图标设计原则：1 表意清晰明了，采用大家均已接受的特定含义的元素图形；2 视觉体验统一，视觉语言自成体系；一个功能模块里面的图标尺寸要有较好的视觉平衡性；一功能模块内甚至整个产品的图标的质感、色彩饱和度要统一；成套的多个图标内，图形语义要有较好的一致性。3 需要注意图标各层面意义上的继承性问题，避免让用户造成识别上的困难。三& 图形符号一般表现为直接的操作按钮或标明该操作的辅助标识符号，图形表现为简洁明了，用色简洁、扁平。&■ 在整站图标尺寸规格方面，虽然Web 页面的图标不需要像操作系统或者客户端软件那样，对图标尺寸有着严格的尺寸限制，但为了网站的视觉体验的规范性和统一性，&我的阿里&图标规范中根据以往图标各尺寸的使用情况来约定3种常用尺寸：48&48 pix 、32&32 pix 、16&16 pix，以后整站的图标根据各自的位置和需要，将有序的根据规则加上相应尺寸的图标，这样网站在图标符号展示层面上将会给用户留下一个规范、专业的印象。&■ 在图标的设计过程中还需要注意下面这些问题：
上图第一排蓝色的4个图标看起来会显得大小尺寸参差不齐，这是因为虽然觉得尺寸可以是一样的，但是外轮廓饱满的实心图形在给人的视觉感受上会产生放大效应，而第二排深色的4个图标大小看起来则会更加协调一些。在下图可以看到，外轮廓饱满的图形进行了一定的边缘收缩，来与其它图形达到视觉均衡。
这要求设计图标在符合约定的图标尺寸的同时，需要注意多个图标的视觉均衡问题，在制作成套图标的时候，根据这个规律来选择留白的空间比例。
此外单个图标要很好的把握外轮廓与图形形状的均衡关系，构成图标的图形需要尽量的接近一个正方块，使得图形饱满、平衡。&■ 在我的阿里应用图标风格表现方面为了使原来的各业务、应用图标和将来新增的图标能够实现非常好的统一性，我们做出了包括图标视角、构成元素、光源质感、倒角这些方面的约束：
图标的绘制视角为所组成物体的正前视角，在必要情况下可以有一定角度的俯视角。这样是既在大原则上保证了整体的统一性，但规则也不至于太过僵硬，仍有相当的空间让设计师去发挥创意。
整个 icon 元素为& 3个以下，最多为3个元素构成 ，组合方式以一个主体元素& 配合一个（最多两个）辅助元素。避免众多的图标，各自的图形符号多寡不一，避免在图形组合方式上造成的不统一。
图标的光源方向是正上方，图标颜色渐变方向是垂直方向的线性渐变，颜色从上到下由浅到深。图标的颜色渐变幅度较小，偏扁平感，渐变幅度不要太大以至质感过重。
应用图标约定的三种不同尺寸icon 的倒角的大小，以便在集中展示的时候在细节支出依然有良好的一致性。经过以上这样一套设计指南的规范、约定能尽可能的保证原来老图标和后期新增加的都能有一个规则可寻，对整个网站整个产品的品质方面，用户友好性方面能起到一个积极的作用。这里只从应用图标这一切入点介绍了产品视觉元素统一性的解决方案，当然网站还有其它各类控件模块，同样也需要实现类似的标准化统一体验，后面仍有许多工作需要开展。转自：阿里UED
浅谈商务社交网站的核心应用
选题：关于大街网的某一应用，或者某一功能，发表看法，并回答如果你是该公司产品设计，你会怎么做？为什么？
具体实施步骤：
找出最核心的部分，进行分析。
【1】 整理罗列了目前中国市面上跟大街网同类的产品。
做了如下几点：
1.1 &罗列出各个网站的相关数据如上图所列，包括。全球Alexa排名、日均IP访量、&& 日均PV浏览量、PV/IP等数据。按照全球Alexa排名由高到低依次排列。
其中：豆瓣、人人、Linkedin、Facebook等数据是为了提出一个度量基准。
1.2& 从排名最后一名的经纬网往上，注册反复试用，并记录试用心得。
1.3& 最后挑选各项数据最好，用户体验，产品设计都非常不错的网站，天际网。作
&&& &为重点研究的对象。反复使用。
1.4& 反复注册大街网的马甲3个，不断使用测试该网站的一些功能和相关算法。
&&& 深入了解大街网。
【2】 了解网络上关于关键词&商务社交&&大街&&天际&的相关信息。
2.1& 百度搜过关于&商务社交&&大街&&天际&的相关信息，选择性的浏览，精度。
2.2& 知乎上关于&商务社交&&大街&&天际&的相关信息，选择性的浏览，精度。
&&&&& &2.3 &针对知乎上用户反映的问题，精度并思考，同时加了4个QQ好友，针对其在知乎上有深度的意见深入讨论。同时针对其关于商务社交网站交换意见。
&&&&&& 2.4& 收集整理网络上针对于商务社交，大街等意见。带着意见再次深入了解天际、大街，以及确认是否存在网络上存在的问题等。
【3】& 画天际网、大街网、Linkedin的导航图。更进一步了解这三个网站的间架结构；同时对比的看各网站的主要类目所占的流量比：
&&&&&& 3.1.1& 天际网导航图：
&&&&&& &&3.1.2天极网各子类目的流量占比数据：(数据来自)
3.2.1& 大街网导航图：&&
3.2.2 大街网各子类目的流量占比数据：(数据来自)
& & 3.3.1& Linkedin 导航图：
3.3.2& Linkedin各子类目的流量占比数据：(数据来自)
【4】深度对比发现：一组神奇的数据
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
4.1 天极网的PV/IP=43。这说明网站每个进入该网站的独立IP 都会浏览大约43个子网页。
&&&&& 4.2 &此处，的人均页面浏览量达32.5，说明该页面用户的关注和使用度极高(对比其他来说)。
&&&&&&&&& 这个神奇的子网页是什么？ &同时也确定了本文分析的方向。
【5】 深入研究。页面框架。
&&&&& 5.1& 包含如下三种状态：
&&&&& 5.1.1& 会员登录后自己的页面：
& (以上状态为会员登录状态)
&&&&& 5.1.2& 会员登录后看到自己的好友页面：
& & & 5.3& 会员进入到非自己好友的页面
&&&&& 5.1.4& 不注册登录时看不到这个页面的。
&& & &5.2&& 深入研究 页面框架。
& & & 5.2.1& 思维导航图：&
& & 5.2.2& 内容框架：
&&&&&&&&&&& 1& 个人框架信息呈现(姓名、职业、地点)
&&&&&&&&&&& 2& 个人基本信息呈现(职业概况、工作经历、教育背景、个人信息、附加信息)
&&&&&&&&&&& 3& 好友交互推荐（谁浏览过我、一度好友、浏览过我的人还浏览过）
& & 5.2.3& 交互框架
&&&&&&&&&&& 1& 会员自己的页面：
a. 邀请好友评价
b. 谁浏览过我
c. 一度好友
d. 浏览过我的人还浏览过
&&&&&&&&&&& 2& 一度好友页面：
a. 分享收藏
b. 取消一度好友
c. 撰写评价
g. 分享链接
通过一度好友可以进行2次交互：
a．共同一度好友
b．其他一度好友
c．浏览过他/她的人还浏览过
&&&&&&&&&&& 3& 非一度好友页面：
a. 分享收藏
b. 加为一度好友
e. 朋友引荐
通过一度好友可以进行2次交互：
d．共同一度好友(若没有则不显示该栏目)
e．其他一度好友
f．浏览过他/她的人还浏览过
【6】 通过【5】的分析，是满足了用户的哪些需求？&
&&&&& 在阐述这点之前，我们先看一组调查问卷：
&&&&& 调查结果一目了然：(调查数据开始，21:00 截止，14:00)
调查数据显示：71.43%的调查者表示有强烈的扩充人脉的需求。
&&&&&&&&&&&&& 24.49%的人表示对于扩充人脉的需求还好。
&&&&&&&&&&&&& 37.37%的人通过社交网站扩充人脉
&&&&&&&&&&&&&&&&&&&
其中注册社交网站的主要目的：
&&&&&&&&&&&&&&&&&&& 找工作:&& 22.67%
&&&&&&&&&&&&&&&&&&& 扩充人脉：46.67%
&&&&&&&&&&&&&&&&&&& 学习充电：34.67%
&&&&&&&&&&&&&&&&&&& 其他：&&& 24.00%
&&&&& 用户的第一需求：扩充人脉
& &6.1 关于用户需求找工作
&&&&&&&&& 商务社交网站区别于传统的三大招聘网站，在属性上就有很大的区别点。
&&&&&&&&& 让招聘双方提前发生很多交互，让彼此多更多的了解。
&&&&& 6.2 关于用户需求学习充电
&&&&&&&&& 商务社交区别于传统的学习网站，更多的倡导的是通过认识某一行业里的人，从而了解这个行业的事。更多侧重点是个人从线上到线下。
&&&&&&&&& 当然这点与知乎也有很大的区别。
分析一个行为习惯：
如果这篇文章是：
A& 白鸦写的，我们的认可度就会大很多。
是因为我们知道他过去在产品行业的建树是非常权威的。-我们知道他的简历。
B& 是李三科写的，认可度就会小很多。
&& 是因为很多人都不知道李三科为鸟人？ 没有人知道李三科的简历。
很多人都愿意看白鸦写的，是媒体属性，也是领袖意见属性。
同理， 满足了用户先看别人简历，在发生交互的需求。这个需求正式为什么会有Pv/IP=32.5原因。
同时， 不但可以看到想认识的人的简历，对于现有微博，人人，知乎在内容呈现模式上也是很大的改进。
【7】 综合以上6点，充分说明了商务社交的核心在人，在简历的呈现，必要的用户交互应用。那么我们再过回头来，对比看看大街网&我的档案&页面。
&&&&& 7.1 大街网登录会员页面
&&& 7.2 大街网登录会员进入其好友页面
7.3 大街网登录会员进入非好友页面
&&&&&& 再回到本文的主题：对比给出大街网&我的档案&栏目的建议
& 1 会员用户简历等级制度。(分交换名片，简历对外开放栏目选项等功能)
& & & &2 加强会员用户之前的交互功能。
& & & &3 会员之间的推荐好友功能加强。
&&&&&&其他具体交互细节，就不赘述了。相信会有不断的迭代产品功能推出。
& & &关于大街网，我有很多期待！！
&本文谨作为一个热心产品事业的小兵针对商务社交领域产品提出的小小想法，欢迎讨论
有图片显示不全可阅读原文地址
Marty Cagan谈产品探索的意义和流程
Marty Cagan是享有世界声誉的产品管理专家，曾担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作和经验的总结，分享了探索产品的流程和方法。
产品开发宁缺勿滥有没有见过这样的情形？开发团队刚刚完成手头上的项目闲了下来，可产品经理一想到程序员们自在逍遥，就怎么也坐不住了。为了让他们马上开始新项目，产品经理没日没夜地制作新项目的产品需求文档（PRD），以求速成。这样的事情在产品团队里时常上演，成为产品失败的罪魁祸首。开发团队就像&嗷嗷待哺&的婴儿，胃口特别大，却分不清哪些该吃，哪些不该吃。只要产品需求文档到位，不论产品好坏，他们就马不停蹄地开始新一轮的产品开发。后果可想而知。追根溯源，这种现象的产生是因为产品开发团队里的程序员聘金不菲，公司不乐意看到他们闲着，只有&物尽其用&，才会让公司觉得安心。可聪明反被聪明误，这种短视的行为，给产品的失败埋下了祸根。这种行为还会掩盖开发团队真正的价值。开发团队被公司异化成生产代码的机器，而不是共同探索、打造出成功产品的&战友&。只让开发人员负责软件的开发，明显低估了他们的价值。正确的做法是先通过产品探索定义出基本产品，确定产品是有价值的、可用的、可行的，然后再交给程序员去开发。强迫开发团队满负荷工作的公司，显然是管理理念出现了问题：代码好不等于产品好。当然，这种现象和企业文化也脱不开关系。不可否认，好的项目经理确实能保证产品的交付进度。但不能因此就盲目地让项目管理在公司里唱主角。进度安排合理、资源得到了优化配置不意味着产品就能取得成功。通常，我会建议项目经理在产品探索阶段安静地坐在&观众席&上，等到确信设计的产品值得开发了，再粉墨登场率领团队开发产品。采取这套方案后，收效不错。但如果产品探索阶段，团队里缺少能一统全局的主帅，这套方案就不适用了（在今后的文章中我再讨论这种现象）。如果开发团队闲了下来，而新一轮产品探索还没完成，该怎么办？其实选择很多。
让开发团队利用&余量（headroom）&完善软件架构。
让开发团队着手修复产品缺陷，改善产品性能。
让开发团队参与产品探索活动。产品经理给开发团队预留一个月左右的任务。这样即使手头的项目卡了壳（比如原型测试中，用户的反馈意见很糟糕），在想到新方案之前，你的开发团队都有事可做。开发团队无事可做，还有可能是项目团队里开发人员和产品经理及设计师的比例失衡造成的。如果开发人员过多，那么产品设计团队永远跟不上进度，开发团队必然会&档期&不满。要记住，产品经理的使命是确保团队开发有价值的产品。让开发团队盲目开发未经验证的产品，也是一种浪费。
产品探索计划为了不让程序员闲着，产品经理把本该花在产品探索上的时间都花在了赶写产品需求文档上。可这样的产品探索毫无价值。时间再紧迫，也不能牺牲那些创造价值的关键步骤。而有些公司非常重视产品探索，却没有对这个过程做出合理的规划，不能保证每天做的都是有用功，自然无法快速开发出基本产品。所以，宝贵的时间就这么白白浪费了。产品探索规划是否详细，取决于公司的文化氛围和产品探索人员的能力。很多公司（特别是大规模公司）中，团队需要一个产品探索计划，明确项目必须实现的内容、需要的资源，并给出粗略的进度安排。我将列出常见产品探索计划的组成部分。但这不是模板，不要照着里面的内容生搬硬套，做些不需要做的事情。我列举的每个部分分别解决不同的问题，你可以根据你要解决的问题，选择合适的探索计划。作为产品经理，你要审查这个计划并确保团队按计划执行。
核心探索团队：确认项目的产品经理、首席设计师和主程序员，并且确保这些人员在探索产品的过程中随叫随到。
探索扩展团队：谁将给这个核心团队提供支持？你是否需要视觉设计师？你需要原型设计师的协助吗？需要可用性测试资源吗？需要有特定开发经验的开发人员吗？需要QA团队提供人手吗？需要市场部的人员支持吗？
关键参与人员：这个项目必须得到谁的批准（即谁拥有&否决权&）？此外，还可以写上你认为能够对这个项目发表独到见解的聪明人名单。
客户发展计划：这个项目需不需要特约用户？如果需要的话，谁是牵头人？如果不需要的话，你会请哪些客户（用户）验证你的产品理念？
主要风险：这个项目的主要风险有哪些？你将如何解决这些问题？
用户研究工具：这个项目需不需要创建一些人物角色？需要做网站检查和商业分析吗？
用户测试计划：你打算如何让实际用户测试产品？初步测试计划是什么？
产品战略（愿景）：是否需要在制定项目细节之前，考虑项目所在领域的长期发展？
产品原则：产品的所在领域是否需要独创一些产品原则？
支持文档的程度：核心团队需要在以下方面达成一致意见：在这个项目中，需要哪些额外文档、需要做到什么程度，包括用户故事、用例、测试计划等。制订计划只是产品开发中的一步，更重要的是保证产品探索确实是朝着满足基本要求的产品方向努力。另外，将这两步结合起来后，什么时候能真正开始构建产品也是关键。这个过程的监督工作包括两个部分。首先，我认为，产品的负责人（如产品经理或首席用户体验师）需要对这项活动尽到监督责任，他们积极的监督会对定义产品起到积极的作用。这里要说明一点，这里的&监督&指的是每周至少询问一次产品探索团队下面这些问题。
你这周与什么样的客户和用户进行过比较有效的沟通？
你从你们的讨论中了解到了什么？在你了解它们的过程中，有什么事情使你感到惊讶吗？你有了什么新的见解？
你是否遇到了潜在关键点？【注：参见/your-business-plan-is-wrong】
根据你所了解到的内容，下一次你会进行哪些新的尝试？
开发人员最后一次评估产品设计和客户反馈信息是什么时候？
开发人员在项目可行性和可能的解决方案上有什么意见和反馈？
用户认可这种想法的价值吗？如果不，那么为什么他们不认可？
目前原型最主要的可用性问题有哪些？你打算如何纠正这些问题？
从可行性的角度来讲，开发人员最关心原型的哪些方面？针对这些问题，你有哪些应变措施？
最后，你认为在两周之内完成一个满足最低要求的产品的可能性有多大？如果有困难，那么团队是应该继续努力还是考虑开发其他产品？其次，产品经理也有监督其他事务的职责，比如在项目管理方面，需要确保产品探索计划的实施情况，做好开发的一切准备工作。具体来讲，这包括保证开发团队有足够的资源开展工作，明白项目时间限制及做好时间管理，确保开发者、产品管理者和设计者之间的良好沟通，根据计划从整体上推动进度，以及确保项目中的时间都被有效利用。项目经理的确可以督促大家完成项目，但要确保先确定基本产品，而不能仅写些开发文档。不管怎样实施计划，如果公司很开明，允许你在探索产品上花时间，而不是仅仅撰写需求文档，那么我希望你不要浪费产品探索中的每一天。如果你已经花了很多工夫，但仍感觉到很难开发出好产品，你应该尝试制订产品探索计划。
产品探索日记产品经理和设计师们放弃原有的线性、瀑布式的开发流程，转而采用我倡导的这种更具迭代性、探索性的流程后，通常需要花一些时间才能适应它的快节奏，掌握产品探索的韵律。这篇文章将再现产品探索的情景，让大家了解其核心内容。因为产品的开发过程涉及的因素太多（如产品类型、投入的精力等），做这样的概括并不容易。我尽量使用比较典型和普遍的情景。为了覆盖尽可能多的要点，我构思了以下情景。
为了明确商业目标，我和项目的主要负责人一起进行了产品的机会评估与讨论。
与项目的首席设计师及主程序员开第一次讨论会，制订出产品原则。
紧接着，我们进行了头脑风暴，想到不少好点子。
与首席设计师一起创建第一轮关键人物角色。
和首席设计师继续优化前一天完成的用户角色，确定主要和次要角色；讨论用户使用产品的情景，并列出主要情景和次要情景。
与用户研究员一起明确潜在特约客户名单；通过电话联系特约客户，筛选候选人。
首席设计师根据讨论结果快速创建产品原型。
我、首席设计师以及主程序员一起检查前一天完成的产品原型，看它是否符合我们最初模拟的几个用户情景。讨论非常激烈，原型远比我们设想的要复杂。
我们回顾之前提出的产品原则，再一次明确了重点，之后大幅简化了产品原型。
我、设计师和项目的主要负责人一起查看产品原型。这个原型还在初期，但是已经包含了三个最重要的使用场景。通过讨论，我们意识到我们和项目负责人的想法有些脱节，因为双方对用户的理解不同。
继续电话联系目标客户，确认6家公司成为我们的特约客户。最棒的是，他们似乎对我们的产品将解决的问题有极大的兴趣，因为他们的公司都还没有找到好的解决办法。如果我们的产品能够解决这个问题，那么他们会非常看好我们的产品。
我们和主程序员一起评估修改后的原型。他对主要功能的可行性持谨慎乐观的态度，并提出了两个重要的问题。第一，其中一项功能的开发成本可能颇高，而且执行速度很慢。他需要点时间研究这个问题。第二，他认为我们可以省去一些收集数据的工夫，因为我们需要的数据可以从数据库提取。
咨询有关法律人士，向他展示原型，确保模型没有和法律相冲突的地方。他们认为其中一处需要进行详细评测，检查结果会在下周给出。
早上，我、首席设计师以及项目负责人一起拜访第一个客户，请四位潜在用户试用产品原型。这次测试收获颇丰。可惜原型的表现与我们的期望还有很大的差距。我们发现自己此前对用户的理解还很肤浅，项目负责人的理解也不完全正确。现在我们对用户的理解又进一了步，而且达成了基本的共识。
回到公司后，我们立刻讨论如何修改原型。我们简化了自以为重要的场景，修改了术语，去掉了那些根本不会被用到的高级功能。
主程序员在研究完高风险的技术问题后，确定他之前的担心是有道理的。他提出了新的可行方案，可以实现同样的效果，而且开发难度更低。于是我们根据他的意见对原型进行了调整。另外，他确认了我们本来要收集的数据在数据库中都能找到，这就进一步简化了原型。
下午我们拜访了另一位客户，请三位用户参与了测试。今天的情况比昨天要好很多。我们仍然不确定原型的交互设计是不是足够好，但至少用户能够完成主要任务了。之前去掉高级功能的这一步棋确实走对了，因为用户并不关心它们。我很高兴我们坚持了以客户为中心的价值观。有两位测试用户希望我们第一时间通知他们产品完成的消息。
与首席设计师、主程序员碰头，讨论目前的成果和接下来的工作。主程序员又提出了一项针对关键流程的优化建议，恰好解决了首席设计师面临的几个棘手的问题。
我和首席设计师向视觉设计师提出了我们对视觉设计的几点想法。经过先前的用户测试，我们认为必须将产品中的两个基本概念用某种方式清晰地传达给用户，并且给出了关键状态和用户可能做出的动作。视觉设计师说她已经有了可以表达这些概念、提升产品价值的想法。她会在接下来的一两天内给我们一些具体的方案，之后我们可以为这些方案提建议。
我们仍然在努力定义基本产品。我们相信已经把最关键的功能都涵盖在内了，但不确定到底要不要再加上一个比较酷的功能，不知道它是不是必需的。我们计划暂时从模型中删除这个功能，看看测试的效果如何。
下午，我们拜访了另一位客户，请三位用户测试了产品原型。原型的可用性已经很棒了，但删除了之前说的那个功能后，原型没有得到用户的热烈响应。我们又展示了之前的版本，这次他们表现出了极大热情。我们得出的结论是，这个功能确实非常重要。我们的原型中已经尽可能地删掉了所有不需要的部分，但仍然能激发人们的购买欲望。我们去除了很多高级的功能，简化了关键流程，应该能在主程序员估计的时间内完成开发任务。
我、首席设计师与可视化设计师一起讨论了她设计的方案，我们特别喜欢其中的一个方案。稍做调整后，我们把它用在了原型上。
主程序员根据现有（也可能是最终）的原型估计出了产品开发的周期。这个时间可以接受，并且有风险的技术问题已经排除。
我们将包含最新的产品原型展示给项目负责人，并且总结了最终的产品设计（包括最新的界面设计），以及所有来自测试客户的反馈。她很喜欢这个产品，希望旁观下午的测试。她也想就价格和定位询问客户的意见。
下午，我、首席设计师以及项目负责人带着最终原型去见另一位客户。我们请4~5位用户进行了测试，得到了理想的反馈&&没有遇到使用问题，对功能和价值的反响也很好。所有用户都很期待这款产品的问世，也愿意推荐给朋友或者同事使用。
继续完善原型，并将这些天来了解到的关键点录入项目维基。
向给更多的项目参与人展示了产品原型，包括法律顾问、市场部、产品管理和工程方面的副总。他们提出了一些问题，但都认可用户测试的反馈。
我、首席设计师以及主程序员碰头，讨论如何撰写产品文档，方便开发人员、测试人员、部署人员开展工作。
我和首席设计师分工撰写文档，我们将各自负责的部分写到项目维基里，并添加了一些对产品原型的链接和注释。
看完以上日记，希望你能明确以下10点。
在项目开始时，确定你对目标有清晰的理解（产品机会评估）。
从产品探索最开始时就建立和首席设计师、主程序员的密切合作。
注重真正的协作交流，而不仅仅满足于写那些没人看的文档。
迅速将关键的产品理念融入到原型的制作中。
设法验证自己对产品的假设，不要纸上谈兵，尽快判断哪些假设正确，哪些不正确。
尽早反复地将产品原型提供给目标客户测试，及早发现问题。
记住要确定基本产品。
产品探索的目标：确定产品是有价值的、可用的、可行的。
在产品探索的过程中不断保持和相关部门的信息互通，向大家展示不断更新的产品原型，让他们了解进度。
不要把时间花在为开发人员写文档上，等到产品确定后再写。当然了，实际项目不一定完全与我的描述相同，我希望传达这样一种观念：在把产品理念展示给真正的用户之前，不应该花两周时间撰写产品文档，更不能花三周时间制作初期产品原型。产品探索有特定的节奏和规律，它以构思产品设计、原型制作、用户测试，以及最重要的一点，反复学习为基础。如果你还没有亲身体验过探索产品的过程，那么我希望这篇文章可以让你大致了解产品探索是什么，以及它与直接开始撰写产品文档的做法的区别。
Marty Cagan，作为负责定义和开发产品的高级经理人为多家一流企业工作过，亲历了个人电脑、互联网、电子商务的起落沉浮，致力于通过写作、演讲、培训帮助客户打造富有创意的产品。
本文节选自华中科技大学出版社《启示录：打造用户喜爱的产品》一书和作者的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢华中科技大学出版社与Marty Cagan先生授权。
站长在关注