王迎然 | 聚焦互联网产品，用户体验，交互设计。

2012/05/16
1 Comment

需求分析之——衣柜整理法

做交互设计偶一直觉得要＂先考虑人，再考虑像素＂

也就是说要asking first, thinking next, design last.

先从了解需求开始，之后对需求进行分析，最后再进行设计。

需求一般来自产品经理或用研。那么对于设计师来说，对需求进行分析便是第一步，也是非常重要的一步。

如何进行需求分析呢？这里介绍偶的一种方法，也或是一种结构化思考的过程。

衣柜整理法

为啥叫衣柜整理法呢？先留个悬念。我们先来看看从产品拿到的需求是神马样子的吧。

比如某天收到产品经理发来的一份需求。这是一个关于使用照片装扮并分享的app。一张excel表里面包含n种功能列表。（老实说功能并不是需求）需求如下：

刚看到的时候会不会有点头大。这时候就可以使用＂衣柜整理法＂啦。先想下平时是怎么整理衣柜的。

首先，将衣柜里的东西全部取出来，放在床上。

然后，将散落在床上的衣服进行分类，比如哪些是秋冬季节穿的衣服，哪些是最近要穿的衣服，把他们在床上整理好。

接下来，规划好衣柜的空间，那个地方放内衣，哪个地方挂大衣，哪个地方放运动服等等。然后按照这些规划，让所有衣服各归各位。

最后在正确的场合穿合适的衣服。建立了良好的衣柜整理流程，再也不用临出门的时候把衣柜翻个底朝天啦。

但是，这些和需求分析有神马关系呢？

其实，这五个步骤对应着需求分析的五个水平流程：收集、处理、组织、回顾、行动。

step1.收集：清空衣柜

这个就像是之前例子说的excel的需求列表。包含所有功能，没有逻辑和次序的摆在一起，很像摊在床上的衣服。

step2.处理：为衣物分类

之后，将衣服进行分类叠放，每类一叠。就像把需求进行分类。比如上面的例子，我们可以根据用户任务流程画出简图：

把各个需求按照这几项归位。比如：拍照、选择相片属于创建类的；添加胡子、眼镜、套装等等属于装扮类的；而分享到微博、而或是设为手机联系人头像都属于分享处理类。

step3.组织：将分类的衣服重新储存

把衣服按照衣柜不同区域的格子进行放置。就好比把不同功能要素放在不同的页面下。

这个阶段也可以仔细分析：

应该划分为几个页面？每个页面主要是做什么的？应该放置哪些功能点比较合适。

防止出现＂看哪里有地方插空放button＂的囧。

同时，可以按照功能的优先级和重要程度再次进行分析。根据任务流、视觉流进行线框简图的放置。

step4.回顾：对衣物放置寻找是否清晰

回顾下分类和衣物放置是否合理？上下前后位置是否容易理解？

就像需求的功能点是否分配合理？主任务流程是否流畅，符合用户心理预期。
step5.最后，行动：选择最佳方案

重新检视，进行任务和操作的细化。开始高保真线框的设计制作。
就这样，和衣柜整理一样简单的完成了需求分析~利用结构化抽屉思维，慢慢的你会发现再复杂的需求，拆分下来都不会太难~

又到了换季了，一起整起吧~

本文转自雅秋@UCD交互设计 http://www.zhangyq.com/requirements-analysis-wardrobe-sorting-method/

2012/03/28
4 Comments

产品经理不一定要会开发程序，但需要了解一些基础技术，比如会使用原型图工具、会编写简单的SQL语句从服务器读取数据分析、基本的产品功能数据布点监控、搭建产品的基本架构等；在一个产品的开发前期，团队成员基本也都是技术和开发，技术出身的产品经理，更容易控制项目的进度和团队努力的方向。互联网产品需要不断试错，当团队有了一个基本的产品构想后，重要的不是讨论应该有什么功能，不应该有什么功能，而是快速的做一个产品demo给到用户做可用性测试，在未获得批量用户之前，运营和推广相对弱化，懂技术的产品经理在执行力方面相对可控一些。

2、做产品的目的是要解决用户问题

我们很多时候突发奇想，提出一些很有创意的产品，花了几个月甚至一年的时间做出来后，发现用户根本不买单；产品经理一般都会陷入互联网发展趋势的误区，我们总是希望赶上每一波互联网发展的浪潮，视频热的时候，我们总希望做的产品跟视频挂点钩；SNS热的时候，又不断的给产品加入社交功能；B2C热的时候，恨不得把产品的各个位置都加上导购按钮；移动互联网来临的时候，似乎不做个手机版app，都感觉自己out了，不像做互联网似的，总得给自己加个什么O2O、LBS、SOLOMO的标签。产品的本质是要解决用户问题，不以用户为导向，不解决用户问题的产品终将失败。产品经理经常忘记做产品的出发点，做着做着就变成了为公司做产品，为老板做产品，为自己做产品，而不是为用户做产品。

3、忘掉技术，千万不要教育客户

做技术出身的产品经理，也很容易陷入技术的误区，喜欢耍酷，做一些很炫的功能，总是希望跟竞争对手的产品比，竞争对手有的功能一定要有，竞争对手没有的功能更要有，结果做了一堆复杂的功能，用户根本不会用，学习成本也很高。一个好的功能需要把复杂的技术隐藏于无形之中，把最简单的使用体验呈现给用户，不要试图去教育用户，不要挑战用户的使用习惯。另外，我们还经常给产品冠一些很时髦的概念，什么是“第三代杀毒引擎”，什么叫“支持下一代CDMA网络”，用户根本不关心你这些概念，用户需要的只是一款能快速把木马杀光的安全软件，一部上网更快的手机，产品经理需要忘掉技术，做用户看得见的功能。

4、深挖用户核心需求

产品经理经常收到用户的反馈就开始响应，甚至只要用户在论坛里一提需求就开发，我们需要判断用户的真实需求，有时候用户至上只是假象，比如用户说我想要一把锤子，产品经理问你拿锤子干嘛啊，用户说我想在墙上钉个钉子，产品经理问你钉钉子干嘛啊，用户说我想在墙上挂一副画，墙上太空旷了，我想经常变换一些视觉场景，产品经理想了想，立刻给用户装了一台壁挂的液晶电视，用户开心死了。在这个案例中，用户本来的需求只是一把锤子，但其实隐含的需求却是一台壁挂电视，其实有时候用户也搞不清楚自己想要什么，就
像福特说当年如果你问用户想要什么，他一定回答说想要一匹跑得更快的马而不是汽车，这就是用户的需求。做产品经理最困难的就是判断用户的需求是否是真实的，不以用户真实需求为出发点的产品是没有任何粘性可言的，后期的推广成本也很高。

5、从小处着眼，微创新

我们总是希望去做一款伟大的产品，总是希望去做一个大的变革，去颠覆传统，其实互联网产品往往一开始只需要去满足你身边的需求，把最紧急最核心的需求做到极致，然后再一点一点的通过微创新去改进你的产品，丰富你的产品功能。经常出差的同学都会遇到这样一个困惑，住酒店冲凉的时候经常找不到水龙头的冷热开关方向，几乎所有的酒店水龙头都是用绿色或红色表示冷热，而且标记在水龙头开关的最下方，为了改进用户体验，七天连锁酒店就做了一个小小的微创新，直接在水龙头两边贴个告示标签“冷”和“热”，用户再也不用困惑了。做互联网产品也是一样的道理，就是一点一点的去发现用户的问题，然后想办法解决掉，就是一个微创新，几十个微创新的点加起来就会不断逼近用户引爆的点，即“用户口碑”。

6、看懂产品关键数据

做数据分析是任何一个做互联网产品的人必须要做的功课，但是往往数据可以反映问题，也可以掩盖事实，比如我们再做数据布点的时候，我们发现产品的三个功能使用次数在相当长一段时间内变化都不大，我们如何判定这三个功能哪个重要的呢？这个就是功能的连续性和独立性的问题，如果流水性作业的几个连续功能（比如进销存），很可能就是这种情况，收费产品也可能会出现这种情况，反正已经掏钱了，将就着用吧，user和ownership不是同一个人的产品也有可能出现这种情况，反正产品又不是我掏钱买的，管它好用不好用，这些情况下监控功能的使用频次，意义就不大；这时候更多的观察用户对每个功能的使用顺序和时长，改进用户使用功能的顺畅性和输入的便捷性，从而改进用户体验。有时候我们也需要从宏观数据上判断产品的方向，比如一个产品的用户有10%是活跃的，有30%是沉默的，60%都跑光了，这个产品的方向肯定出问题了，所以做产品经理，感觉很重要，有时候需要通过一些关键数据判断，哪些功能需要做，哪些不需要做，什么时候做。

7、不要怕被用户骂，不要把产品当自己的孩子

产品经理最怕被用户骂，被用户骂不一定是坏事，骂你说明你值得骂，说明用户对你的产品有期待，重要的是产品经理需要清醒的从用户的骂声中找到问题的解决方案，并且不断的追问用户为什么骂你？是一个用户在骂你？还是一群用户在骂你？还是竞争对手在骂你？骂得最凶的用户往往都是最高端的用户，一个好的互联网产品，应该是用户边骂边用，说明用户离不开你。产品经理需要每天听取用户骂声，因为骂声意味着用户需求，意味着一个改进用户体验的机会，周鸿祎经常在微博上收到用户反馈后，半夜三更给产品经理去一条短信或者电话，就三个字“看微博”，搞得产品经理很紧张，后来被360产品经理戏称为“午夜凶玲”，关键问题不是用户骂你，而是要知道如何在骂声中去运营你的产品。过去很多产品经理讲，我们要把产品当成自己的孩子，细心照料呵护，这个也误导了很多人，在公司我们靠经验和直觉不断完善产品功能，通过数据分析改进用户体验，这些只是家庭教育，我们还要将产品（孩子）送去念小学、中学、大学，去和其它孩子比，去接受学校教育和社会教育，去经受磨练和挫折，才能真正成长为一个好的产品。产品经理需要对产品批评和自我批评，
把产品放出去，适应社会，满足用户需求，而不是把它当成襁褓中的婴儿；运营是严父，技术是慈母，运营教产品做人，技术教产品做事，二者缺一不可。

8、好的产品是运营出来的

周鸿祎经常讲“好的产品是运营出来的”，但好像很多产品经理对运营的理解都不一样，更多的人认为运营就是做活动，搞用户，做推广，其实不是这样的，运营的本质是通过跟用户交流和数据监控不断改进用户体验的过程。360在启动一个项目的时候，一般都会先做好产品的数据布点，建立起数据监控体系，同时配一个专职产品经理助理或者QA收集用户反馈，产品经理每天看数据和QA整理的用户问题清单，然后召集团队把问题一个一个解决掉，“不让问题过夜”似乎已经成为360产品经理一条不成文的规定，所以更准确的讲一个互联网产品的运营，前期就是解决用户问题和改进用户体验。

9、小步快跑，快速迭代

这一点做互联网的人都在讲，但是真正做到的凤毛翎角，比如一个庞大的ERP是很难实现快速迭代的，一个以收入为导向的产品也很难做到小步快跑，因为你收了用户的钱，你就得对用户负责，安全、稳定、没有重大BUG、没有用户投诉和反馈似乎就意味着是一个成功的产品。即使是一个轻量级的、free的产品也未必能做到，比如产品经理在规划产品的时候，可能想到了50个需求，但先做哪一个呢？有时候我们对用户需求的优先级判定并非那么容易，这个就需要产品经理有很好的产品感，同时还要求团队有很强的执行力。一般360在做一个产品的时候，首先会深刻洞察用户需求，并且排出优先级，先做两三个核心需求，做一个bata版本，通过跟用户交流和数据反馈，一点一点的丰富产品功能，然后快速迭代出一个小版本，循环往复最终推出一个稳定的大版本，所以需求往往都是通过解决用户问题衍生出来的，而不是去创造用户需求，甚至是幻想用户需求。

10、在真实世界里打造产品

以上9点，我们做着做着就会偏离原则，我们总是喜欢站在自己的立场、公司的立场和老板的立场去做产品，而不是站在用户的立场去做产品，说白了就是我们没有在真实的世界里做产品。产品经理需要还原用户的使用场景，需要不断的去观察用户去是如何使用我们的产品，同时把自己假想成真正的用户，天天去用自己的产品，天天去跟用户交流，不断的追问为什么？用户为什么会提出这样的需求？用户遇到的问题我遇到了吗？产品经理首先必须自己就是产品骨灰级的用户，史玉柱在做征途游戏的时候，自己每天至少花2个小时跟玩家去玩游戏，一共至少跟1000个玩家沟通过，最终才取得成功；周鸿祎也经常在机场找用户去装360安全卫士，然后将用户的问题反馈给产品经理，360做产品的信条就是“不放过任何一个跟用户交流的机会”。

2012/03/26
2 Comments

产品经理要怎么写周报？

又到周五了，意味着大家又要开始憋周报了，从@纯银的一个段子开始——

公司有个技术牛人，某产品专员向他提单，牛人一看内容很扯，质问“你觉得这个需求有价值吗？”对方诚恳回答：“没价值，但是我总得写周报啊。”牛人想了一分钟，回答说好吧我帮你做，因为我也得写周报啊。

我想，看这个博客的人，基本上都要写周报吧，更有甚者估计要写日报，但多少人打心底里觉得写的周报没有意义？只是为了写而写？今天，不妨从两个方面，简单说说，如何让周报真正的有意义。

第一个话题：写什么内容。

这个万变不离其宗，其实和敏捷里的站立晨会是一样一样一样的。形式不重要，说清楚3件事即可。

本周做了什么：重点不在于做了什么，而是拿到了什么结果（有共识的）。举个例子，花了半天时间和谁谁开了个什么会不重要，重要的是会上做了什么决定，会后定了什么后续的行动方案。

下周要做什么：同样，重点在于希望拿到什么结果，推进什么事情。不要是“继续优化Q2的产品规划”这样虚的东西，而应该是“与某某老板讨论Q2产品规划，并达成共识，从而下下周可以启动某项目”。

碰到了什么问题：怎么去尝试解决，搞不定的需要什么资源，打算找谁，打算让老板或同事怎么帮你。

然后，针对你的工作内容，细化一下，比如分为“项目、日常需求、其他”几个模块，有的时候再加一点工作感悟，也挺好，比如我，就是从每周500字的感悟渐渐写出一本书的，：）

第二个话题：发给谁。

可能有人觉得这个没啥可讨论的，传统上，周报不就是汇报工作（说白点，方便老板汇总周报）么？发给自己的主管不就行了么，我觉得这是最傻的，这大大浪费了“写周报”这个及其费脑子的工作。

稍好一些，周报可以发给主管和团队同事，团队里的人互相了解都在做什么，可以便于工作展开。

更好的，周报应该发给主管、团队同事、下属、以及有干系的合作方（其他部门的人），并且酌情区分“To”和“CC”，这才是真正的信息流通，发挥最大价值。愿意把周报发给下属的主管是好主管，：）

这位说了，周报里有敏感的内容啊，不方便发这么多人……我说两句：第一，互联网的精神就是开放共享，再想想，你觉得敏感的内容，是不是真的敏感；第二，稍稍做点技术处理，很简单的，可以共享的内容发给所有人，实在敏感的内容，在邮件上再回复一下，补充给对应的收件人好了。

要不，改变从今天开始？

本文转自人人都是产品经理 http://iamsujie.com/3000/3017/

2012/03/23
2 Comments

如何写一份交互说明文档

离开交互圈已经有段时间了。但由于博客还在，还是能够偶尔收到一些邮件，上周有位同学问我：我在求职，我看到很多招聘说明上需要交互设计师编写界面交互设计文档，请问界面交互设计文档是什么文档？怎么编写呢

这让我想起来2009年自己在项目里也大力推行过交互说明文档（在下文中，简称为DRD），格式倒没什么限制，交互设计师自己写到界面上也行，单独文档成文也行，总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来，降低项目里的沟通成本和风险。今天整理电脑，翻出以前的PPT，分享之。

这将涉及到几个问题：

一. 什么是交互说明文档（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。如果使用过程中还是存在问题，那么就想想是否还存在别的解决方案吧～

本文转自 Heidi格物志 http://heidixie.blog.sohu.com/207036464.html

2012/03/15
2 Comments

浅析iPhone平台三种应用类型的布局方式

在手机这样一个小小的有限的屏幕尺寸里，要使界面保持清晰合理、简洁美观，就涉及到产品“框架布局”的设计问题，我们需要根据不同的产品需求及应用场景来设计合理的界面布局。

iPhone平台的标准界面布局为顶部标题栏、中部内容区、底部工具栏/标签栏，设计师们根据不同的应用类型以及不同的使用情境进行着巧妙的布局，其中不乏很多勇于打破常规，精巧合理的布局设计。今天就一起来看看iPhone平台多样化的界面布局方式。

iPhone平台有三种类型的应用：

效率型应用（Productivity Applications）
实用型应用（Utility Applications）
沉浸型应用（Immersive Applications）

每一种类型都有各自不同的特点和应用场景。设计之前要清楚产品的目标、特点以及用户使用产品的动机，以选择合适的应用类型。下面我们分别通过这三种应用来总结一下界面的布局方式。

1.效率型应用（Productivity Applications）

效率型应用几乎包含了从社交网络到手机银行的所有应用。此类应用具有组织和操作具体信息的功能，需要比较精简的用户体验，从而不会阻碍用户的工作，要将用户体验的重点放在任务上，用户可以快速地找到需要的目标，轻松地完成操作。

1)如何设计效率型应用

以任务为导向的设计理念。建立准确的任务模型，将用户可能的任务进行拆解，并逐一设计优化流程。要让用户快速开始，快速找到信息，快速离开。建立清晰的层级关系，便捷准确的检索方式，以便于用户迅速定位需要的信息。

要降低用户的学习成本，尽可能的使用系统的控件和操作。降低噪音，保证高级的功能在用户需要时能够找到即可，在不需要的时候也不会造成困扰。

2)效率型应用的界面布局

A. 九宫格

此类界面通常是用户进入产品后的首屏，为用户提供分类入口，入口通常以图表加文字的形式展现。以格子的形式排列，可以让用户快速地找到入口。此类布局适合用于丰富的内容展现，且内容适合分类聚合。

B. 折叠列表

折叠折表是为避免页面内过长的滚动而做的布局设计，通常需要在同一页面内展示大幅内容时可考虑使用此类布局。内容以两级列表的形式进行分组，每组可以分别展开显示它的子项目。

C. 图片列表

图片列表可以直观地将图片的全图显示出来，方便用户快速检索查看，大幅的图片也为用户带来视觉上的愉悦体验。

D. 旋转木马

旋转木马的布局适用于内容以线性或者循环的形式进行组织，充分利用有限的屏幕空间，更好的来展示一系列图形图像，从而让用户获得更好的聚焦体验，正如欢快奔腾的木马，不停的旋转展示，让每个独立个体都得到表现的机会。这种布局特别适用于屏幕空间有限而又需要展示大量内容。

常用的旋转木马式布局有两种，一种是如上图的全屏的展示，一般多用于首页，用作各个内容的入口。另一种是如下图的应用，带有多个项目的通常用于页面的顶部。

E . 侧滑分屏

侧滑分屏的界面布局是采用三屏模式（左屏、主屏、右屏），此架构具有极好的扩展性。path2.0完全颠覆了iOS guild line的模式，采用这种三屏模式，极简了主页面，主屏仅留下feed展示和添加功能。将导航放入左侧的屏幕，增加了未来的可扩展性，同时也保证了主屏幕清晰的内容。

2. 实用型应用（Utility Applications）

实用型应用完成的任务对用户输入要求很低。用户打开实用型应用程序，是为了快速查看信息摘要或是在少数对象上执行简单任务。实用型应用的特点是最小化安装、简单的流程及布局、标准化的界面元素。

1) 如何设计实用型应用

专注做好一个功能，使其一目了然，将需要的信息展示在一个层级里，让用户快速地获取某类特定的信息或者执行某一具体的任务，因此在开启后无需操作就能解决问题是最完美的。力争使界面简洁，并尽量使用简单的、标准的视图和控件。设置通常在主视图背面，可以设置不同的数据源。

2) 实用型应用的界面布局

界面以平面列表的方式显示信息；易于浏览，只包含了最必要的信息，没有深入的信息层次结构。每一个视图都提供同样的数据组织结构和细节深度。在界面下方显示打开的视图数量，用户可以按顺序浏览，在一个视图后选择另一个视图。

通常一个实用型应用只解决某一个方面的问题，如上图的指南针和温度计，通过拟物化的设计，全屏布局突出应用功能，一目了然。

界面简明地突出了主要功能，没有多余的操作和设置，以使用户快速完成操作。

3. 沉浸型应用（Immersive Applications）

沉浸型应用可以为用户带来极致的娱乐和游戏体验，这类应用和标准的系统界面不同，用户希望这类应用能够给他们带来最大的娱乐。此类应用的特点是聚焦于主要内容及完全个性化的用户体验。

1) 如何设计沉浸型应用

富媒体的表现形式，声，光，色，效，通过丰富的表现力让用户沉浸其中。不拘泥于系统的控件和表现方式，因此，界面设计的自由发挥度比较高，仿真的、可爱的设计风格往往容易出彩。

2) 沉浸型应用的界面布局

A. 游戏类的全屏布局

沉浸式应用通常会占据整个屏幕，包括电池和网络信息的状态栏，让用户聚集于主要内容，以增强用户的参与感。这种全屏界面布局没有多余的任务导向和元素干扰，让用户探索，并在探索中得到发现和奖励，不拘泥于系统的控件和表现方式。此类应用多为以横屏方向进行布局。

B. 媒体类的全屏布局

媒体类最常见的是电子阅读和视频播放，特写内容会占据整个屏幕，界面只显示内容，让用户沉浸其中，当用户点击屏幕时会在浮动层上显示控件。

C. 特定任务类的全屏布局

特定任务类常见的有录音、拍照、图片处理等，界面布局以突出特定任务为主，在界面的下方辅以任务的操作按键，通常使用自定义的界面以配合环境。此类应用程序运行时可能会涉及到大量数据的处理，但是通常不显示这些数据，无须让用户查看。

写在后面

在手机的交互设计中，我们要思考如何在有限的空间内合理布局，更好的展现内容，无论是文字还是图片，都要让内容看上去优雅得体。我们需要根据不同的应用类型、产品定位、用户目标来选择合适的界面布局，还要勇于尝试，敢于打破常规，设计出让用户赏心悦目的产品。

本文转自“百度MUX” http://mux.baidu.com/?p=2950

2012/03/06
5 Comments

WordPress，你好！

博客换程序了，以前的文章也没有了，一切重新开始吧。

之前使用的emlog，使用中只感觉后台体验很差，编辑器不好用，上传图片麻烦，使用一年果断换成WordPress，很多人都追捧WordPress，的确WordPress强大，主题多，插件也多。不过，适合自己的博客系统才是最重要的。

之前开博一年多，写的文章也没有几篇，主要还是不知道写点什么（也很懒），今后此博客要记录我的工作和生活，也算是一种监督吧。

简单自我介绍一下，王迎然，08年到11年从事网页设计工作，今年转型互联网产品设计，如果你也是一名产品人员，我希望和你成为朋友，一起交流！

新浪微博的筒子们可以互粉： http://weibo.com/wangyingran