产品设计流程参考 - UCD大社区

设计流程：官方流程VS.实际流程

sherrydodo — 2010-06-26 15:08:46

今天看到这两个图，真的是非常形象：

先是官方设计流程：

然后是实际感受到的流程：

原文链接作者：Brandon Schauer

从“产品需求文档”（PRD）到“产品设计文档”（PDD）

心弦 — 2009-12-22 20:56:27

传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。一般一个产品都包含乃几十个乃至上百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。

自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人－通常是设计师和程序员－能够在最短的时间内领会产品的设计。

原来做UI设计师的时候，我创造了一种用流程图来表示产品交互的办法，这个方法受到了很多人的欢迎，这篇文章也引起了一定的反响。其实当时在实际使用的时候，我不仅产出这样一份流程图，还利用网页热区，把流程图中的界面元素（蓝色的元素）和原型网页（HTML文件）给结合起来了，这样设计师和程序员在看流程图的时候，只要用鼠标点一下界面元素，就可以连接到原型网页，非常方便！这个办法我一直都在用，只是当时没有写在文章里罢了。

后来随着工作性质的变化，我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章，我就开始寻找把用例整合进前述方法的可能。在经过了一段时间的摸索和实践后，我逐渐形成了自己特有的一套产品需求文档的写法，为了表示区别，我称之为“产品设计文档”，简称PDD。

本文就是对PDD的介绍。

PDD的组成部分

PDD有三个组成部分，它们分别是用例、流程图和原型图。

用例

用例从整体脉络上定义了产品所具有的功能。比如对于一个邮件系统来说，“写邮件”、“发邮件”和“删除邮件”等功能都是用例。

用例比较流行的写法，是在每一个用例中标明它的前后置条件和异常情况等属性。不过在PDD中，我完全放弃了上述属性，只保留用例的名称和简要描述。因为“用例”的出发点就是“用户”，如果你站在一个用户的角度来思考产品的功能，你会发现那些属性你根本就不会考虑。并且，各种前后置条件和异常情况，完全可以放在流程图中，这样更清楚。

流程图

流程图是对用例的细化，它可以清晰地表现一个用例所有相关的前置、后置和分支条件。流程图的画法我在“画Web流程图的一点心得”一文中已经说得非常清楚了，在此不再赘述。唯一值得注意的是，我以前并没有意识到流程图本身也是有ISO标准的，因此“画”中使用的流程图元素并不符合ISO标准，也和一些已经成型的系统（比如这篇“描述信息结构和交互设计的图示词汇表”）有出入，因此元素在使用上还存在一些问题。在日常工作当中我已经对元素使用做了修改，以后有时间我会更新“画”一文的内容，也有可能直接把模板放出来。

原型图

原型图是对流程图中“界面元素”的展现。这个东西没什么可说的。

PDD的表现方式

用例、流程图和原型图一般都是产片需求文档（PRD）中已有的东西，PDD在这点上和PRD没什么区别。而下面要说的表现方式，则是PDD的精髓。我比较孤陋寡闻，还没看到过有人像我这样组织这三块内容，所以姑且认为这是我的首创吧。

用例和流程图

首先把用例和流程图整合起来。方法很简单，利用网页的frame标签，新建几个帧：

index.html－另外两个帧的容器，不用解释吧
navigation.html－导航帧，用于存放用例列表
main.html－默认情况下的主帧，用于存放文档简介、作者、版本和更新日志一类的东西

然后新建一大堆网页，把所有的流程图都放在这些网页里，每个流程图（即每个用例）放在一个网页里，最后修改navigation.html，把用例名称和其对应的网页链接起来。完工以后，页面应该是下面这个样子：

PDD文档首页

左侧为用例，右侧为流程图

好了，左侧为用例，右侧为流程图，这样就把用例和流程图整合了起来，并且结构清晰，查看方便。

流程图和原型图

整合流程图和原型图的重点在于，提供一种方便的方式，以让读者能够在看流程图时方便的看到其中包含的原型图。为了达到这个目的，我的做法是：

在用OmniGraffle画流程图时，选择界面元素（蓝色的那个），然后在“检查器”－“属性：动作”中选择“打开文件”，然后按“选择文件”，找到你的原型图文件并按“确定”，这样你这个元素就和原型图链接起来了。如下图所示：
在OmniGraffle中输出这个流程图文档时，不是选择图片，而是选择“HTML图像映射”，这样在生成出来的网页上，蓝色的界面元素都是可以点击的，点了以后就链接到原型图。很方便对吧？但这还不够；
用Lightbox，把所有图片链接都改成弹出图层，这次再点刚才那些链接看看，效果是不是更棒？

好了，通过这样的方法，产品设计文档（PDD）就将用例、流程图和原型图这三块内容有效的整合了起来。

看到的alibaba和听到的Google

犷野西风 — 2009-05-06 23:48:50

今天有幸听了“谭校长”的分享，有些观点感觉非常有意思：

1、没有流程 - “自上而下”与“自下而上”

非常有意思的一个话题。据说在Google的项目的“流程”多是自发性的“自上而下”发生的，员工的一个idea，只要能找到志同道合的朋友，几个人就可以简单地开干了。所以一个产品从idea到上线最短的时间可能只需要一天的时间！并且，任何人都可以发起项目，只要能有1%的数据的证明和通过每个项目5分钟的产品会议就可以上线。而在阿里巴巴，这个过程却是自上而下的，产品要上线必须有PD来做规划，然后是kickoff，FRD，产品会议，交互设计稿，视觉设计稿，前端 Demo，UC，TC……中间必须流经pd，用户研究员，交互设计师，视觉设计师，前端开发工程师，后台工程师，测试工程师等多个角色，还有那个漫长的众多专家和老大的资源抢夺战……诚然，Google的模式并不一定适合alibaba，开发和设计人员的能力以及资源的情况是完全不一样的。但Google 的模式却告诉我们了一个以前几乎没有想过的事: 快速迭代的互联网领域可以没有开发流程 。idea-找人付诸实践-产品会议-上线，需要流程吗？唯一一个在可以归在阿里巴巴流程中的就是产品会议了吧。

突然又想到了博鳌论坛上康辉在David和李开复在博鳌上的访谈，David谈到创新的时候说Google的创新是“自上而下”的，由精英工程师主导推给用户，而alibaba的创新是“自下而上”的，从用户的需求出发来创新。两家公司在创新的源头上不经相同，而在实施过程中确有倒了个个儿，呵呵，有点意思……

2、教育者 - 设计师的角色

Google中国的UX团队一共只有13个人2种角色（设计师和研究员），相比于阿里巴巴中文站UED30多人4种角色（用研，视觉，交互，前端）的团队显然是“少的可怜”。但不可否认Google的产品在体验上非常地不错，简单、易用。据了解Google设计师在工作中还需要扮演了一个教育者的角色。带着工程师去市场直接感受用户的行为，让工程师参与用研测试……让工程师本身就有用户体验的意识，这样很多时候一些产品都不需要设计师的参与。而在 alibaba，ued的同学似乎往往是站在PD或是运营对立的方面，去接受一个又一个挑战，我想这也不能简单地归于Kpi的原因吧？

或许我们真得可以换个思路，想想怎么让需求方更好地了解ued方面的专业知识，这样才能更彻底地解决问题。

3、快速解决问题 -设计效率

互联网开发周期短，迭代时间快，早一步可能就占尽了先机。所以如何提升设计和开发效率是一个很现实的问题。这方面Google的一些做法还是挺值得学习的。一个是Google在做用户调研的时候一定会叫上工程师，在得到反馈意见的时候立马作出修改然后马上再推给用户再反馈，甚至工程师不参加就不开展调研了。而在阿里巴巴，这个流程基本上是用户测试-研究员的反馈报告-开会讨论解决方案-再修改-再测试……无形中增加了很多沟通和时间成本。另一点，Google也认同经验，设计师或是研究员的经验有时候就是答案。而我们在对外推我们思想的时候，却总是受到这样的质疑，“你们的想法就代表用户了吗？作为用户我就认为……” 不可否认的一方面Google工程师的能力确实很强，能在极短的时间里迅速完成产品的修改，这一点我们自叹不如；也不可否认Google设计人员庞大的数据支持很很强的业务能力也是现阶段我们还不能完全达到的，但如果ued每一个决策都必须有足够的依据和论证的话，这个成本有多大？大家可以想一下。

……

这样的区别还有很多，黑格尔说过“存在即合理”，对应于各自公司不同情况不可能简单地评判哪个更好。不过正如“谭校长”所说，互联网的交互设计方面起步比较晚，大家都还在探索，或许更好地方式会在明天自己长出来！

相关话题：产品设计流程参考源地址：http://f2e.me/200905/ali-google/

从一幅涂鸦谈设计

yusen — 2009-05-01 23:34:19

今天我冒着感染猪流感的风险暂时摆脱宅男状态，在Los Alto的一家星巴克门外采访了Damien Newman，设计公司Central的创始人。他之前在Frogdesign做过Director of Strategy，然后又在IDEO任Brand Strategist。现在他自己开了个名为Central的设计+战略咨询公司。

1个小时的采访中Damien介绍了很多关于设计咨询公司的经验。这些我想之后整理好了专门介绍一下。这里先提到的是他多年前画的一副涂鸦。如下图。

source: http://www.centralstory.com/filed/squiggle/

设计是什么？我认为这幅图很好地表达了出来，那就是：
- embrace the uncertainty at the beginning
- focus on a single point of clarity in the end

各位用户体验设计师可能有和我一样的经历，当别人问你是做什么的时候：“噢，我是设计师”。然后对方很有可能就会很佩服地说：”噢那你美术一定很好了！“

实际上呢，拿起铅笔画画基本上是我最不擅长的事情之一。

设计师实际上要做的事情有两个，第一个是识别问题，第二个才是解决问题。很多人对设计师的理解停留在第二个事情上，也就是解决问题，这样的设计师不叫设计师，应该叫设计匠。

匠：Crafter。何为匠？客户要你设计一个瓶子，你说OK，我给你设计一个瓶子，这就是，请拿好，再见。

师：Master，Teacher。何为师？客户要你设计一个瓶子，你说别急，我们先来一起弄清楚为什么我们要设计这个瓶子，它要满足用它的人什么需求？它要解决什么问题？目前的解决方案缺点在哪里？如何改进？最后你设计出来的可能完全不是瓶子，说不定是个电灯泡呢。

设计第一阶段：研究
在设计的初期，事情是复杂的，并且我们也要把事情弄复杂。因为通过探索不同的可能性，我们能更加深刻地了解我们所面对问题的实质。在这个阶段，我们要采访用户、发放问卷、请教专家；我们要成为所在领域的专家，我们要了解这个问题的来龙去脉。在这个研究阶段，整个事情就像是一团乱麻一样。只有敏锐的问题解决者（problem solver），才能从中抽丝理续，进入到第二个阶段。

设计第二阶段：概念/原型
在这一阶段，通过之前的大量研究，你摒除了那些不重要甚至是误导的信息，真正抓住了什么是重要的，迫在眉睫的，值得解决也能够解决的问题。这样形成了设计的概念（concept），或者在斯坦福设计学院，叫观点（point of view）。此刻你知道了你是在为谁设计（Persona），接下来你开始围绕这个概念或观点，产生出一系列的原型（prototype），并且加以验证和迭代（Prototype and iterate）。这个时候复杂度已经大大降低，但是仍然存在多种可能性和不确定性。

设计第三阶段：设计
在这个阶段，通过前面的研究和原型测试迭代，你已经很清楚设计应该是怎么样了，接下来很简单，运用各种工具，把这个设计做出来吧！

不幸的是，我们太多次都直接从第三阶段开始了。原因是多种多样的，内部的外部的。好一点的情况下，我们对自己说：用户应该喜欢这样的设计因为……，更多更坏的情况下，我们对自己说：我要这样设计因为我喜欢这样……

Damien说，好的设计团队里面有各种各样的人才，人类学家、心理学家、计算机科学家、营销专家、机械工程师、信息架构师等等。而我们平时认为的设计师（illustrator），只是完成最后一步的一个专才而已。设计应该是多学科紧密合作的（Multidisciplinary radical collaboration），这也是IDEO和Frogdesign等设计公司如此成功的重要原因。

相关话题：产品设计流程参考源地址：http://www.lanrenux.com/?p=222

互联网设计操作参考v2

千鸟 — 2009-03-24 06:01:35

除对概念部分的细化、对方法引入层级外，还有如下小调整：

优化图形并分级；
完全以角色为出发点，调整了箭头方向；
不再乱用颜色，调整并减少、统一了关系色彩；
更正并清晰了几个措辞；

很早已意识到理念部分有问题，但是没有明确答案，太多了、之间而且还有重叠。搞清楚一两个容易，每个都有基础认识，并且建立联系很困难。与朋友探讨概念，都是看对方的理解能否促进自己某些方面的认识。如果有分歧不用争论，因为这种东西光说是没用的，一千个人眼中就有一千个哈姆雷特。

以用户为中心的“用户”仅仅是个代名词，代表一种哲学理念。整理前对目标的理解长期停留在“用户友好、开发者友好、搜索引擎友好”之上，无论如何都无法完全对应“实现”指标，后来Realazy这篇07年的观点给了我很大启发。

在理解用户友好、开发者友好的前提下，再次对照大量Search Engine Friendly（以后简称SEF）技术参考，基本上可以搞清楚所有小伎俩的来龙去脉。老是有家伙把SEO, SEM等名词与之混淆，目地是做概念的打包营销，然后忽悠土鳖老板“效果老好了”。

完全可以清晰看到，网络上流传的所谓“SEO技巧”入门内容基本都属于SEF技术范畴，而且对于专业设计师&工程师来说没什么技术含量。另外，圈内比较有影响力的几位“SEO高手”，我承认他们是有SEM丰富实践经验的营销行家，但对设计&工程的理解并不入流。因此我对利用SEM概念推动设计的说法特别排斥，随着对曾经质疑的深入了解，做出如下补充：

所谓SEM职能是做市场&销售（网络营销）；
准确SEF职能是做设计&工程（搜索引擎友好）；
真正SEO职能是做研究；

对终端用户的体验友好指标，很多朋友受Peter Morville在04年的观点影响较大，但我认为Paul Veugen在Peter观点基础上于本月的总结更简炼。层级部分大体参考JJ Garrett在00年的观点，但我更认同Peter Morville在07年的总结。有兴趣的同行，还可以参考Richard Dalton在JJ Garrett观点基础上于07年的总结。

初学避免追求概念，但随着自我积累在认识方面的提高，多参考同行总结是条捷径。当然，具体能否理解、能理解多少，得看我们各自的实践经验，学习本身就是个分享、提炼的迭代过程。

互联网设计操作参考v1

相关话题：产品设计流程参考源地址：http://blog.rexsong.com/?p=5359

小心，别让你的产品出轨了

kent.zhu — 2009-03-09 07:03:47

       让产品设计人员最郁闷的事情莫过于眼睁睁的看着自己的产品出轨而无能为力。在产品讨论会上你激情的描述完你规划的产品蓝图，但是执行中各个部门经常不断跟你抱怨按照你这么做有困难，他们希望偷工减料或者走“捷径”，最后，你刻画的小乔被做成了芙蓉姐姐……总结一下最近产品设计中遇到的问题，觉得产品设计应该具有以下5种感觉：

       框架感
       从构思一个产品开始，在产品设计人员的脑海里你的产品就应该是一个完整的小乔。她的秀发、俏脸、粉颈、香肩、酥胸、楚腰、翘臀、美腿、玉足，这一切都应该是完整的。眼光要放长远，不仅要看到幼年小乔娇小的身段更应该想到老去的小乔应该如何粉饰才能让她美艳不衰。
        就一个产品人员而言必须具备良好的系统观念，你现在开发的产品和你目前的产品线应该是配套的，眼光要放长远一点，不仅仅看到目前只有数百付费会员数千信息时候的样子，更应该想到当发展到数十万会员数百万条信息时候如何管理，如何规范，如何运作的样子。贪图目前的方便，随意对信息不加分类的录入到最后只能让系统混乱不堪。

       重点感
       我觉得做产品应该往最多功能里想，然后再往最少的功能上做。头脑风暴列出这个产品可以具备的所有功能，甚至是某个很边缘的功能也应该列举出来。然后我们来一个个的考量，这个是否是被需要最多的？这个是否是跟我们现有的产品线最匹配的，找出我们最应该做的功能，OK，这就是产品需要具备的最核心的功能。
       接下来需要做的就是偏执的执行和坚守住这个最核心的功能，不管遇到什么困难我们都不应该放弃掉这个功能，一定要保证这个最核心功能不能被破坏,这样产品才不会轻易就出轨。小乔的头发可以稍微黄一点，但是俏丽的脸庞一点不能出现粉刺！

       节奏感
       懂运营的人不一定能做好产品，但是，不懂运营的人一定做不好产品！产品人员应该试着每周去做2天的客服，这样才能知道我们的用户最需要什么，才能知道我们现在最需要上哪一部分产品。
       只有数百会员的时候就冒然的上社区，网站的内容质量还没有上去就先想着收费，这样只能是吓跑用户。上去就捉住小乔的手说“愿与吾同床共枕否？”，排除小乔被下了迷药等因素，你得到的应该只有一巴掌……

       好习惯
       尊重用户的习惯，遵守设计规范，保持整个产品的一致性。
       不要试图去用挑战用户的习惯来标新立异，用户也是很固执的！可能仅仅因为你把登陆入口从右上角移动了一下，他们就会说他们找不到登录入口，于是离开。

       细节观
       从大局观念到上线节奏最后落脚会是在细节上。细节之处见真功夫，看看目前以用户自居的同学批评各个网站的文章你就知道了，他们通常都是抓住某一个小东西就开始一顿劈头痛骂的！
       脸上长着粉刺的小乔的美艳肯定会骤减的，同样的，如果你在产品的文案上发现很多错别字或者图标都切的不标准你的产品的用户体验肯定会很差。

产品人员的目光应该再放远一点，偏执再多一些，变通再灵活一些，不要让技术和市场的几句抱怨就让你的产品出轨了！有框架感才能有大方向，抓住重点才能掌好舵，把握节奏才能走的平稳，养成好习惯才能不违章，注重细节才能走的又快又稳。

相关话题：产品设计流程参考源地址：http://www.ikent.me/blog/1331

主流互联网公司的产品项目流程

ryansigma — 2009-03-01 14:09:44

偶然看到的阿里巴巴一张产品设计流程图，对比了一下目前mtime的产品流程设计，发现基本上是一模一样的。看来国内主流的互联网公司的产品研发流程基本一致。我也简单讲解一下，说不定可以帮助到有志成为互联网UED设计者的后来人。

点击看完整大图

这套流程不知道是不是从美国人民那引进而来的，记得好几年前看了一本书，叫《用户体验的要素》，当年看完了可以说一头雾水，不知所云。作者说的“战略层、框架层……”云云，最后还画了一张类似楼房设计图的画，来解释整个UED的设计流程，现在回想，实际做下来，也不过就是上面这张图的流程而已。

首先，需求分析

需求来自于多方面，比如公司的战略目标，UV或是P/V；也可能是商业需求，比如放入购物车的转化率或是活动参与率；更有可能来自一些用户的呼声，某些活跃用户慨叹“有了XX功能就好了”之类的。但是最有可能的还是需求还是来自于历史数据的总结，比如某产品明显没人用，或是用户不活跃，那么这个产品就是需要优化的。有时候需求甚至来自于“XX网火了，它的模式是否能复制？”这样的理由。总之，作为一个产品设计者，不要幻想你就是在那想最牛的设计是什么样的，然后画个原型出来一鸣惊人一把，绝大多数的时候，新产品或是优化的需求都是跟着公司的大方向在走，有时候需求的收集甚至是挺痛苦的事情。当然也不尽然，如果有用户访谈的话会有趣不少，从中收集的需求也往往会让你很是吃惊，用户访谈的问卷设计也是一门很大的学问，有时间可以再详细的写写。

总而言之，经过需求分析，并且拿出历史数据来证明你的论点，你可以提交一个新产品或是产品优化的报告了，这个报告可以是PPT，也有可能是个流程图，拿着这个报告去跟团队PK吧。

原型设计

有了需求，就可以真正开始着手设计了。最开始的原型设计是低保真的，可以拿纸画，但是只能给你自己看看；大多数情况下还是使用visio、fireworks等，这些家伙有个缺点就是只能展示一下样子，没办法展示交互；最新的解决方案是Axure RP，一个可以实现链接、弹出层等交互功能的web原型设计软件，最大的缺点应该就是不好用，不方便。如果是重展示的产品，比如门户网站的频道页，还是使用fireworks这种高视觉仿真的；如果是人机交互性特别强的产品，比如“群组里发帖功能”，那最好还是Auxure RP，画的时候是费点力气，开会讨论的时候可以省不少口舌。

原型设计的方法和哲学，基本就可以讲一本书了，这篇文章只讨论流程，不追求细腻了。

画完了以后团队内部讨论，再跟领导PK，也就是所谓的专家意见，经过一番激烈的辩论和修修改改之后，终于拿出了一个产品部内部满意的高保真交互原型作品。这还没到松一口气的时候，比较重要的产品的话，还会要求你要拿着这个原型去跟用户开体验会，会上你需要观察用户，并向他们提问，提问的问题大致就是“第一感觉是什么？第一个想要点击的是哪？最让你感到迷惑的是哪？”，这个对一个UED设计师是一个比较大的挑战，你需要足够的洞察力和判断力。其中还有一个经验之谈，受访用户大都会根据自己的经验乱提一通建议，然后自己略感洋洋得意，这时候一定要记得体验会的目的是收集用户的体验，而不是专门去听取非专家们的意见。选择性的摘取了用户的反馈后，你需要提交一个用户体验测试报告，报告中会提到这个设计最大的问题，哪里是流畅使用的障碍。之后再按照此报告对症下药，对原型做出修改。

再经过一番PK和讨论，恭喜你终于拿出了大家都满意的作品，作为产品设计师的你，最大的任务就算完成了。

视觉设计

拿着沉甸甸的原型，交给UI设计师，确保他们领会了你的精神，并且嘱咐任何疑问随时来找你。这里又有一个经验之谈，就是GUI设计师往往会对你的产品加一些他认为比较美观的东西，这个时侯一定要毫不手软，坚决砍掉。一定要秉持的一个理念是，GUI设计师不应该在原型体验基础上，增加任何附加元素，这是对最初的用户体验的一种伤害。举个简单的例子，你写了一个栏目名叫“粉丝群”，他为了美观又在栏目title下加了一个英文的“fans club”，这个就是增加了不必要的附加信息。

视觉设计肯定也要经过一番讨论和PK，UE设计师在其中的角色就是把关者，一定要捍卫自己的体验设计，这时候对自己产品的深刻理解非常重要。

html切割

对UE设计师来说乏善可陈，这个时侯最好是开始着手为开发组书写需求文档。

开发

文档写好了就和开发组的同仁开需求确认会，把你要实现的功能讲清楚了。开发过程中，UE设计师要做的就是答疑。

内测版上线

测试组的同事测好了，就会交给你验收。你需要做的是看看开发的同事是不是真的按照你写的需求文档上那样，弹出窗口，或是向下展开。

注意这个环节中有可能再来一次用户体验会，你需要做的也和之前差不多，可能唯一多的一样就是真诚的祈祷，不要提出很致命的产品流程缺陷，那就前功尽弃了，虽然不至于推倒重来，但是需求变更确实是件麻烦事。

产品上线

终于上线啦，欣喜的看着用户讨论它的同时，你有可能需要配合业务部门组织一下新产品的推广，当然只能作为辅助啦。

然后再开始观察历史数据，收集用户需求，提出优化……循环啦。

可用性工程的生命周期

波希米亚 — 2008-12-10 05:20:04

下载PDF: the_usability_engineering_lifecycle_1_0.pdf (190k)

最近看了一些有关可用性工程方面的文章,包括一些方法和思想.
总结下来有几点,我们还是缺乏归纳.为什么这么说,举个例子,我现在问”可用性工程的生命周期”是什么?估计很多人一下就蒙了.说实话,我刚看到这个问题的时候也蒙了,确实没有仔细的想过.

其实我们这些从事可用性相关方面研究的工作者们,在日常工作中都是遵循这样的规律进行的.如果我换个方法来问”平时做可用性方面工作时,流程怎样,分哪几部分来进行?” 这会问题就好答了”大概分三块,先是进行需求分析;然后是设计,测试,开发;最后是安装部署,发布上线.” 大同小异,总之会按这种流程走下来.

我们每天都在按照这个路子做事,只是缺乏归纳,这样对经验的积累和专业性的提高来说是不太好的.
这个图我从<>找到(找不到?看看如何在Google上看书),画了两个晚上,顺便翻译成中文.希望对可用性工作人员的日常工作能起到一些辅助作用.做用户体验一部分靠事实,另一部分真得凭经验.经验来自平时的归纳总结.

查看图片格式:

用户体验设计指南的引入

Tenk — 2008-12-16 21:58:40

实际上这样子的一个指南我是完全没有能力去创建的，但是在工作的过程当中，确实又感觉到因为规范的缺失导致沟通困难和协作不顺利，所以我思考这个问题的目的实际上更多的是为了帮助自己理清思路。

以我浅薄的认识，这样一个指南某种程度上类似于阶段性的总结，引入的目的主要为了以下几个方面：

人文环境的营造，思想上的共识，理解做产品的目的
沟通的顺畅，尽量避免在各个环节中信息传达的误解和误差
尽量避免为自己开发，为自己设计，为了美丽而美丽
促进团队的学习和分享，整体战斗力的提升
概念的建立，然后在实践中发现并慢慢理解

这样一个指南的建立必须切合实际产品，要尽量避免概念的铺呈描述，而这需要一定量的经验和产品开发的积累，而我相当缺乏。

以下这张图是根据我平时的学习积累和一点点产品设计中的总结展开的，并没有实际意义，仅做为砖头晾晒，希望各路高手可以分享一点这方面的经验。

看大图

1. 用户体验设计指南介绍
对产品是什么和为了什么进行整体概括性的宣导，指南的完善实际上是促进成员进行阶段性总结，同时发现团队存在的问题。

2. 设计思想与原则
宣导以用户为中心的设计，把用户和产品关联起来，建立对产品的基础框架和整体性认知，进一步理解产品是什么和为了什么，以及产品在客观层面的需求。

3. 我们的沟通
对产品设计过程中的文档及流程图等进行一定程度的规范，加快分发时的浏览和理解，尽量避免信息传递的误解和误差，并建立沟通氛围，保持和促进团队的和谐融洽。

4. 品牌延续性设计
建立对产品感官层面的认知，同时规范整体上的设计元素应用。首先加深品牌在团员成员中的认知，这样才更有利于把品牌通过设计传达给用户。

5. 界面设计
建立和总结具体设计过程所应用的大部分元素，并提取共同模块，组成部件以供快速调用，以提升多人协同开发设计的流畅性并保持一致性。对于界面设计，可能还需要面对多终端，比如Web端、Wap端、手机软件等。

6. 人机交互
这里的人机交互是比较狭义的人机交互，可以理解为人与机器的直接接触，当产品包括手机软件的时候，需要考虑的人机交互就会比较多些。

7. 首次体验
首次体验设计即用户第一次使用产品的特殊流程设计，做为第一印象扮演着很重要的位置，而这部分通常碰到的问题也最多，所以需要花一定的时间考虑各种各样的场景并进行权衡设计。

8. 产品概貌
在产品开发到一定阶段的时候对产品进行总结，并提取最主要的和最突出的功能对产品进行概括性的介绍，这部分通常也作为对外分发的一部分。

9. 产品测试
除了专门的测试人员以外，产品需要团队所有成员参与进行测试，那么需要提交和整理发现的问题，再进行定期讨论解决，这除了可以解决产品本身的问题外，还可以提高成员对产品的关注度以及问题的扩散发现，建立一个良性的过程。

10. 我们自己的体验
调动所有成员参与用户体验，加深对用户体验的认知，同时亦可作为沟通的范本，定期整理然后开展讨论会等周期性活动，一切都是为了在认知、沟通中不断的进步。

以上这些似乎都没有涉及到程序，但实际中我们应该认识到一个拥有良好用户体验的产品首先是对用户有价值的，其次是扎实而强悍的技术层面实现，所以作为主管人员及研究人员需要把这种价值感传递给每一个参与人员，而用户体验设计指南是可以起到一点作用。在行为和外观上，每一个团队的成员实际上都可以尽自己的力量共同参与，这需要宣导和调动。实际上一个和谐而奋发的团队是需要某种文化的支撑以及价值观的共建。

相关话题：产品设计流程参考源地址：http://www.fivex.cn/ux-guidelines.html

互联网设计操作参考

千鸟 — 2008-11-11 10:36:15

很多时候，往往以为自己理解了概念，却只有等再理解下个概念之后，才明白以前认识还不够。我们都是在某个点出发，逐渐放大试图了解全局，然后才可能正确认识自己的位置，并找到适合自己的突破口。

长久被专业名词困扰和误导，我知道它们肯定是一体的，但如何分类、组织、建立联系，让整个框架立体化，合理解释似乎并不是那么容易。基于自己现阶段知识结构，以及同行们反馈的各种观点，重点介绍新突破。

组织理念并分层

思想信仰——以用户为中心的设计
实现目标——良好用户体验
具体指标——可访问性、兼容性、可用性、标准化、搜索引擎友好

接受来自IBM的概念定义启发，依次分为思想、目标、指标三大逻辑层面。关键在于指标问题上，我认为web-based产品因为客户端多样性原因，远不止可用性这一项，经过补充排序结果如下：可访问性、兼容性、可用性、标准化、搜索引擎友好。

可以看到可访问性、兼容性、标准化、搜索引擎友好都是web-based产品独有的，这也是做web比做soft麻烦的根本原因。相对来说，我处理可访问性、兼容性、标准化、搜索引擎友好，比可用性更得心应手，这与我的背景、经验和兴趣有关。因此我不会去做soft-based的事情，并且完全有理由相信，可用性不是最重要的指标。

理念只是贯穿全局的方针原则，并不具有明确的指导意义。虽然理念都有独立中心思想，但操作层面有交集，所以容易引起各种争论。在做事角度，任何理念角度深入下去，都可能不同程度见到效果。但要把事情做到极致，需要平衡各项指标。

组织流程和方法

概念阶段——用户研究、信息架构
设计阶段——交互设计、信息设计、界面设计、视觉设计
制作阶段——原型制作、客户端编程

曾在纵深协作方式中提出扁平结构协作初步设想，减少沟通环节避免理解缺失，用灵活性来适应互联网的快速产出和快速迭代，整个流程就分概念、设计、制作三大阶段。《用户体验的要素》所提的战略、范围、结构、框架、表现五层对理解帮助很大，但我认为不适合操作。

同时，书中观点对应提出来的各专业方法，我认为还缺少对web-based原型工作的支持，因此容易造成与开发之间的断层。这部分俗称“前端开发”工作一直都处在前后不搭的尴尬地位，补充两个关键点，第一属于产品设计范畴，第二还有原型制作、客户端编程两个层级。

组织角色和交付物

产品经理——蓝图
产品设计师——文档
产品工程师——原型

曾在模拟高效团队中提出标配三人团队的初步设想，也是Google的行事作风。

交付物部分值得商榷，按照《Communicating Design》的总结有需求、设计、策略三类，但我认为有两大问题，第一把所有产出都叫documents欠妥，第二缺少对web-based产出的指导。按属性分为蓝图、文档、原型三类比较恰当，把蓝图从文档中独立出来，原型则是必要补充。

去年曾提出过使用页面线框图提速设计流程，也不止一次公开分享其成果，核心指导思想是提高灵活和可控性，用web的方式做web-based产品设计。最近更有Prototyping with XHTML作者称之为“一个伟大的方式从xhtml原型开始。”

a great way to embark on that journey is to start prototyping with XHTML.

关联理念、流程和交付物

思想信仰——概念阶段——蓝图
实现目标——设计阶段——文档
具体指标——制作阶段——原型

理念都是前人花时间花精力总结出来的、带有哲学观点的清晰表达，是做知识传承的重要参考。肯定都是虚的，实际的东西没资格叫理念。理念只可能“引导”做事，而不具备实操指导意义，易学难懂也最无趣。但为避免混淆，和更有针对性的引导做事，还得努力搞清楚。

典型如标准化，针对客户端开发提出了一系列颠覆性思路，但目前互联网还是个市场占有率确定标准的时代。从操作层面看，四年前我认为太过理想化，现在依然保持此观点。

各层级概念应该对应到做事流程，并有阶段性的产出。在结合流程、交付物后，从这条纵向线索中很容易看清“以用户为中心的设计、用户体验、可用性”之间的区别。同理，迭代也应尽量保证在各阶段内完成。上线后的产品，再去试图更改概念阶段的游戏规则，基本等于推倒重来。

关联交付物、角色和方法

蓝图——产品经理——用户研究、信息架构
文档——产品设计师——交互设计、信息设计、界面设计、视觉设计
原型——产品工程师——原型制作、客户端编程

曾在用户体验的误解中提出角色对应方法初步设想，我非常不赞同专业“用户体验团队”的协作方式，难道产品经理们做事不考虑用户体验么？还是说把用户体验先留着，等某些人来做？显然不可能，因为方法一旦脱离具体业务就成了学术论证，方法不可能创造结果，只可能加速。

根据专业方法制定角色，或走设计流程，我觉得都不可取。做互联网设计，应该学会身兼数职。况且所谓的专业方法其实就那么点东西，上手很容易，现在全球知识共享又几乎没门槛，学会做事太容易了。在人才培养角度，懂方法再熟练业务的难度，肯定要超过懂业务再学方法。

最好的Producer，有人可以带领大家做的更好，没人自己也能抗下来。

产品设计流程

indigo — 2008-10-20 22:36:48

产品开发流程和项目管理流程时常被大家关注，合理的过程是团队协作的基础。在大家把产品的功能和特性放在第一位的时候，开发和项目的管理至关重要，而产品的设计却往往被忽视，开发团队会为了那些晦涩难懂、令人费解的功能而夸夸其谈，复杂的产品特性通常会迫使产品团队放弃优雅简洁的设计，用户体验永远是可能是项目过程中最不重要的环节。如果你和你的团队希望重视产品的设计，就应该首先从团队架构和项目流程上来进行改造，我们的目标是设计优先、用户至上。当然技术团队和产品开发还是至关重要的环节，你需要将设计和开发的流程无缝的整合起来。

下面的团队架构和流程应该适用于各种产品、软件和网站的设计（如果您有好的建议或者不同的看法，可以直接留言或者邮件给我）

产品设计团队的六种逻辑角色

你也许不需要六个人来组成团队，但每个人的职能必须清晰。《Getting Real》中关于 “团队组织” 的建议值得参考，他告诉你了在这个快速的软件开发时代如何去组建一个高效的产品团队。

业务负责人（business owner）

通常是你的BOSS、产品最初的策划人或者是整个产品的业务主管，他们会分析产品的市场、定位客户、定义品牌、提出想法，同时拿定主意，产品团队里面的万金油

产品经理（product manager）

对产品负责的人，产品主管，他们会提出概念、收集确定需求、制定计划、控制进度并保障产品质量。在很多团队里面“业务负责人”和“产品经理”通常是同一个人。

产品设计（ui/id/ia design）

user interface design（人机界面设计）, industry design（工业设计）and information architecture design（信息架构设计）。将这三种职能混合起来，因为他们并不能孤立存在，我们统称为产品设计。他们决定产品的所有功能细节，配合产品经理制作产品原型，与视觉设计师和用户研究人员共同完成产品的详细设计。产品设计过程中最重要的产品功能说明文档将由他们来跟踪完善。

视觉设计（visual design）

产品团队中最有艺术细胞的人，他们完成产品的外观和界面设计，是否好看由他们说了算，他们作为产品团队的艺术设计权威指导。

用户研究（user research）

最接近用户并了解用户的人（不需要技术高手或者是逻辑人），他们从产品的原型阶段就介入，配合产品设计师们做典型用户分析和用户目标分析，并对原型进行可用性测试，并制定最终的可用性测试计划。在很多产品团队里面，产品设计、视觉设计和用户研究通常会由一到两个人来担任，UI设计师会做用户研究，视觉设计是会做信息架构分析。

产品开发（production）

产品团队中的技术开发人员，网页制作或者程序开发，他们是产品的最终实现者，他们开发并进行单元测试，控制产品的最终品质。

产品从设计到发布的六个阶段

产品开发的过程可以看作是整个产品设计环节的最终实现部分，对于非技术人员来说它是一个把理想变成现实的神秘阶段

1. 概念阶段（concept）

一切从有了一个想法开始！

需要做的事情

业务负责人与产品经理沟通商业需求以及产品品牌的定义
产品经理针对这个想法提出自己的问题和需求，并提供解决方法与好处
产品经理从各方面收集信息并制作概念文档
业务负责人、产品经理、产品设计还有视觉设计们做到一起，来一场头脑风暴，证实这个想法并确定实现一个什么样的原型
产品设计负责完成最初的产品原型

阶段交付物： 概念文档（concept document）或者是概念原型（concept prototype）

2. 探索阶段（discover）

那个伟大的想法已经得到了证实！

需要做的事情：

在获取了多方面的意见之后业务负责人与产品经理进一步沟通商业需求以及产品的定义
产品经理需要分析产品的战略、商业案例、财务计划、应对策略以及执行方案
产品设计需要分析上一个版本的用户反馈和竞争对手的产品近况，将这些信息提交到产品经理那里
产品设计和用户研究小组共同做用户案例分析，理清用户的使用目标并分析用户的使用流程
产品设计、视觉设计和开发负责人预估自己的投入，并将这些信息提交给产品经理
产品经理从市场分析（报告）、产品设计、视觉设计和开发负责人那里收集尽可能详细的信息，用来制作提案（可行性）文档

阶段交付物： 提案（可行性）文档（Proposal Document）

3. 定义阶段（definition）

大家的建议已经通过，产品经理来负责制定计划

需要做的事情：

业务负责人要确定产品的最终定位（必须的）
产品经理进一步分析产品团队提交过来的各种信息，开始制作产品需求文档
产品经理宣布项目启动
产品设计对产品概念设计进行进一步的完善，细化功能，制作一些具体的用户使用场景
视觉设计开始为产品的视觉表现收集意见、寻找灵感
用户研究小组在概念设计的基础上进行用户使用调研，问卷在白板上模拟用户操作都行
产品对团对概念设计进行评审

阶段交付物： 需求文档（Product Requirement Document），产品概念设计（Concept Design Meterials）

4. 细化阶段（refinement）

开始按照需求的定义来细化产品的设计

需要做的事情：

业务负责人需要对产品的推广和市场需求进行评估
产品经理需要制定产品的路线图，并确定最终的发布时间和计划
交互与视觉设计进入一个迭代的设计阶段，一次又一次的设计修改，直到最终的设计方案得到确认
- 产品设计制作产品线框图、完成特性清单，并以 HTML、Flash 或其他的形式拿出产品的最终原型设计
- 视觉设计配合产品设计细化产品外观的设计
- 用户研究小组使用现有的原型进行可用性测试

阶段交付物： 产品线框图（Wireframes）、产品特性清单（Feature List）、最终的原型设计（可以是任何版本的，例如 HTML、Flash或者是专用的原型制作工具）

5. 开发阶段（development）

产品团队会在这个阶段与开发团队进行融合，双方对需求和设计进行充分的沟通，组成一个强大的产品开发团队

需要做的事情（产品团队）：

业务负责人要去进行商务拓展、寻求合作伙伴并规划市场
产品经理需要制定详细的推广计划
产品设计开始制作产品功能说明书，同时按照用户研究小组的测试来完善产品的UI设计
视觉设计对产品团队进行艺术指导，同时要确认最终的产品外观设计
用户研究小组进行原型测试
产品经理对所有的设计进行确认，正式进入开发阶段，接下来就祈祷成功吧
产品设计把最终确定的产品功能说明是提交给开发团队

这里有一点需要强调，你不需要去写冗长的功能说明和毫无意义的文档，因为原型设计已经帮你完成了很多流程和功能描述性的工作，如何做好你的产品文档，可以参考一下《Getting Real》中的 “关于文档”。

产品交付物 产品功能说明书（Product Functional Specification）

需要做的事情（开发团队）

产品设计加入到开发团队里面，继续维护产品功能说明，同时帮助开发阶段的产品测试和质量监控
用户研究小组也参与到开发团队之中，随着开发的进行去来更新他们的用户测试计划
开发人员在一个接一个的小小胜利中拿出第一个 Beta 版本。

这里有几个原则需要铭记，保持小巧的软件、让开发人员为快乐而编码、倾听你的代码、使用开放的格式。关于编码的详细建议可以参考《Getting Real》中的 “关于编码”。

开发交付物： 产品的第一个 Beta 版本（Beta Launch）

6. 发布阶段（launch）

邀请用户参与你的 Beta 版本测试，直到产品正式发布

需要做的事情：

用户研究小组收集用户的使用反馈，为下一个版本的改进做好准备
产品设计维护现有的UI设计
视觉设计继续修正现有的产品外观
用户支持是产品团队中所有成员都应尽的义务，善待你的用户，从自己做起。

如何做好用户支持以及产品发布的维护，您可以参考一下《Getting Real》中关于对 “用户支持” 和 “产品推出之后的工作” 的建议，必定受益非浅。

参考的资源

Information Architecture Institute’s Tools - 这里有丰富的产品设计文档和资料，还有各种做线图和原型的模板
Urlgreyhot | Resource - michael angeles 的 blog，这里有丰富的产品设计文档、资源与素材
Getting Real - 37Signals 的这本书讲述了产品从构思到上线的全部构成，一个成功案例的教程，无论你是自己创业还是给人打工，都应该看看这本书，希望快速领悟其精髓的，可以看阅读一下 indigo 的《Getting Real 学习笔记》
一叶千鸟同学的阅读收藏站上面也有大量关于产品设计的文章

相关话题：产品设计流程参考源地址：http://indigos.cn/archives/199

XHTML原型开发－用代码说话

Douis — 2008-11-15 19:05:35

作者：Anders Ramsay and Leah Buley
译者：UCD翻译小组，Li Douis
原文地址： http://www.boxesandarrows.com/view/prototyping-with

如果你正在给标准的网页和应用程序（比如用XHTML/CSS/JS开发的）设计用户体验，那就有充足的理由把XHTML原型（prototype）开发加入你的UX工具集。也许你已经发现传统的线框（wireframes）图功能有限，也许你正在寻找更强大的方法去制作并说明你的设计方案；也许你现在的工作是基于传统的瀑布模型（waterfall model）的（比如，首先创建线框图，然后交给设计，然后交给开发，等等），但你需要更加同步的方法，比如敏捷迭代开发（agile and iterative development）。不管用什么方法，通过XHTML开始你的原型设计将帮你更好的踏上这一旅程。

那么，用XHTML进行原型设计开发到底是什么意思？实际上，它就是使用XHTML及其相关技术去生成并确定你的设计方案的过程。那么一个XHTML的原型看上去什么样呢？这个问题，就像我们后面会看到的，其实取决于原型开发所在的步骤，一个XHTML原型通常看上去跟其他使用XHTML制作的网页是一样的，带有一些演示性的链接和特性。换句话说，也就是你用XHTML开发的东西，不管是客户网站还是企业应用，都可以用XHTML来制作原型。后面我们还会看到，这种方法相对于线框图或其他原型工具来说，都有着很多的优势。

一个迭代的过程

由于XHTML原型开发不是绑定到某个具体设计环节的，使得迭代开发大大增强了它的效果。原因有很多，但也许最显著的原因是原型及后来的程序这两者共同构成了设计说明。我们还会对这一点稍加解释（见“XHTML如何兼作设计说明”），但首先让我们看看XHTML原型开发的全过程。让我们从一个更宏观的设计进程的角度开始。

在这种（迭代）方法中，不会在开发之前对整个应用程序进行设计，而是先设计程序的一个节点（unit），然后使用这个节点充当其他程序节点的起始点。与其他的设计方法一样，整个设计过程始于草图（sketching），草图对原型的开发起到了重要作用。

草图法：一件形式自由的事情

“草图”这个词在这里指代那些不受特定技术限制的、自由的开发形式。包括制作线框图（通常要多次重绘），以及使用特定的工具来修改草图。当使用草图法来帮助思考、或演示给领导看的时候，一旦你的设计思路有了新的改进，你自然会放弃那些已经过失的线框图。但这时候往往已经开发出来一个原型产品了。在我所在的设计团队里，我们发现当使用XHTML开发原型时，线框会显得多余，而且，把草图直接变成原型会省事得多。

原型法：一个明确的回答

原型与草图有着对应关系。借用比尔巴克斯顿的话说，草图会带来一个问题：“这是一个好的创意吗？”－原型会告诉你答案。藉由对创意的具体表现，原型法综合了现有产品开发技术的实际情况和所能达到的用户体验水平，并且提供了一个方法，对你的设想进行明确而清晰的质量评价。

原型开发/打造关联

使用XHTML进行开发的时候，特别是在一个迭代模型中，开发和原型制作往往会纠缠在一起。如果你正在制作一个新应用或新产品的原型，XHTML原型实际上只是未来实际产品的一个草案。但是，当对现有程序进行升级设计的时候，现有产品的版本就能作为新的升级方案的一个起始点。

三个综合层次：结构(Structure)，行为(Behavior)，基础(Foundation)

XHTML原型开发的模型基于实际网站产品的最佳实践模型：首先用XHTML进行基础开发，然后用CSS添加表现层，接下来用JavaScript加入行为层，然后迭代。

我们从结构层开始讨论。

结构层：建立页面的基本结构

XHTML原型开发的第一步是建立一个基本结构。与线框图的制作类似，我们首先要表现出页面上的主内容区，不同的是我们用基于文本的XHTML语言来进行标记。

如果我们的草图或线框貌似这样…

我们的XHTML可能貌似这样：

…
XYZ Application

My Account


Account options


Account details


Account Help


[footer]

… 
(We're only displaying the relevant snippet of the XHTML here.)

接下来，我们添加预先定义好的详细内容元素，为相应的内容使用恰当的XHTML结构。

比如，如果我们的详细草图貌似这样…

我们会把AccountHelp主题列表显示成一个无序列表（比如使用ul标记）：


…

Account Help


     How do I lorem ipsum?
     
 How do I dolet amet?
     
 How do I lorem ipsum?
     
More help…


…

通过继续给页面添加详细的内容，我们实际上制作出了一个该页面的结构化的内容目录。它可以作为其他原型产品的一个基础。线框主要是在一个特定的布局形式之中体现页面的信息架构，但我们的方法则是纯粹的结构和层次，依我看来，能更好的表现一个网页上的真正的信息架构。

通过使用XHTML来直接定义信息的架构，我们还可以轻松的定义出与可达性（accessibility）相关的属性。比如发现那些使用屏幕阅读器来遍历网页的用户是怎样体验网页以及相应的内容区块的。另外，我们也更容易定义那些在线框图中容易忽视掉的元素，比如表单中的标签（Label）标记。

如果想要在浏览器中查看这个结构层，那基本上会看到一个非风格化的网页，而且会看上去比较无趣。虽然基础层并不以支持表现层见长，但基础层的质量会影响它所支持的表现层，所以结构层的质量也会严重影响网站的整体质量。但事实上，对样式的忽略却恰恰是使用XHTML的重要优势所在。

改进表现层

有了一个恰当的结构，我们就可以开始侧重于如何展示内容了。再看看以前的那些草图，我们已经具备了一定的布局概念，那么就可以开始往结构里面添加内容了。在不同的团队里，开发和制作外观（look and feel）的方法有很大不同。当你使用设计样稿（design comps）开始尝试外观设计时，特别是当你也同时负责整体的品牌设计时，重新设计样稿是比较划算的，就好像重绘线框图一样。正如草图有利于线框图，设计样稿也利于最初的外观设计。但现实工作中那些制作完整的表现层往往脱离了技术实际，最后不得不进行剪裁并批量的应用到网页上，就像给建筑物的外墙刷漆。而且这种静态的绘制软件外观的方法难以兼顾到网页上所有的动态元素。但是，如果使用XHTML来开发原型，则可大大提升外观实现的水平。用户可以参加到设计中来，用户提供的快速而丰富的反馈意见，可以帮助我们逐步改进页面的表现层。

以前在绘制（illustration）软件的时候，有些问题是难以显露的，但现在则会变得很明显。包括那些设计方案与浏览器之间的问题。比如设计是否应当居中这类基本问题，以及那些更复杂的问题，比如如何设计以适应不同窗口尺寸和浏览分辨率的问题。举例来说，对于较小的窗口尺寸，是否允许部分内容跑到视图外面？或者让内容自动适应窗口的尺寸？当使用绘制法来处理外观问题时，这类问题常常无法发觉，从而损害到用户体验。

添加行为层：少作无用功

用XHTML开发原型时，你是在整个网站的大环境下进行设计。这些设计会不断的加入你的实时更新的UI库。你不再是面向一个具体的功能点进行设计，而是由Google来通知你哪些人已经设计开发了类似的东西，并使用这些已有的东西作为你的解决方案的出发点。这些东西可以无所不包，从日期选取器到WEB控件，再到那些刚刚诞生的顶尖级UI创意。此外，XHTML原型开发可以很轻松的集成或模拟WEB2.0功能，比如内置控件和内容聚合（syndication）。如果你不懂JavaScript或其他相关技术，你可以跟开发人员合作来集成你的方案。当然，有时从网上找不到符合你的设计需求的解决方案，这种情况下，还是回过头来画草图，并且跟你的团队好好合作吧。

迭代：发现，改进

原型法的真正强大之处是在迭代过程中发挥出来的，也就是用户与你的原型产生交互的时候。在最近的一个项目中，我们设计了一个草图方案，用户可以从一个库中拖拽视频文件放入播放列表。看着那份静态的草图，貌似简单又简练。但是当用户真正开始使用的时候，拖放视频的缩略图时，他们却发现这种动作极为不爽，尤其是拖放大量视频时。换句话说，原型让我们得以发现那些隐藏在线框图后面的设计问题。

随之而来的核心问题，就是使用静态图形来讨论交互方案。静态图形等于是强迫用户用自己去想象，在想象中一切功能都极为完美。但是用XHTML，我们则把这种对用户认知能力的挑战降到最低，让他们去实际体验和感受一个几乎就是真实产品的东西。

只要用户作出了反馈，那么团队就开始进行下一次迭代。另一个在原型法中用于评估质量的角色加入进来：迭代的速度有多快？迭代耗费的时间越长，原型的价值就越低。用XHTML做原型开发时，迭代可以近乎神速，这首先是由于原型易于呈现给用户，因为它仅仅是一个发布文件然后发送URL的问题。其次，XHTML是基于文本的，它的迭代（比如修改文本或更新基本功能）仅仅需要几分钟。就算高级的设计修改，通常也不会超过几个小时。

XHTML如何兼作设计说明

XHTML的一项最牛的本领，就是自描述性（self-describing）。XHTML标记在告知浏览器如何显示数据的同时，还可以变成程序员的设计说明。举例如下：

这个标记

会被读作

用时髦的话来讲，我们写的是“语义有意”标记（semantically meaningful markup）。也就是说我们选用的标记、命名的ID和Class是可以传达其实际意义和功能的。

注释仅对个别人可见

XHTML作为设计说明的另一个好处在于，ID和Class名可以兼作注释参考。换句话说，在你的说明中，ID为“账户选项” 的内容区的注释将会显示在标题“账户选项”下面。

使用线框图时，常见的做法是在页面的顶部按编号列出模糊、杂乱的注释。这种注释会给非技术性读者造成困扰和负担。但XHTML的注释则只放在标记中，只有感兴趣的程序员才会看到。而且由于XHTML文件自身的信息很丰富，实际上注释只需写成简短的要点即可。

更标准，无干扰

线框图的最大缺点之一是缺乏标准的标记。也就是说你和我彼此看不懂对方的图。这就迫使视觉设计师和程序员们不得不去翻译我们的大作，其结果就是作者与读者间产生了误解。为了弥补这个问题，我们需要制作极为详细的线框图，还得添加长长的注释去解释图的含义，说明图的元素如何工作。这样，慢慢地就会累积起大堆的说明文档，而且变成无法维护的极端“劳动密集型”工作。一旦无法及时更新，整个团队就会放弃这种设计说明，接下来就会发生各种糟糕的事情。与线框图相比，XHTML提供了标准化的注释，任何了解XHTML的用户都可以直接阅读。更重要的是，你的读者（开发人员）是使用流畅的日常语言来阅读的。而且那些不关注XHTML的读者也可以只选择阅读他们关注的部分，要做的就是打开浏览器而已。

使用标准的注释也就意味着你不会被限定在特定的线框软件或原型软件中，你可以用各种方法，不管是一个简单的文本编辑器还是各种各样的XHTML编辑工具。同时XHTML语法精炼，不象线框图那样繁琐，再加上你只需要编写文本文件即可，只需要通过浏览器就可以看到效果，这就能够帮助你工作的更快捷、更高效。

事半功倍

如果你是XHTML新手，你将会发现XHTML能让你事半功倍。只需要花费几个小时，学习一下网上众多的在线教程，你就可以立即开始书写XHTML。（有两个好推荐：htmldog.com / w3schools.com）而且更妙的是，你不必耗费心思钻研那些时髦的UX工具，就可以深入的领会这种帮你实现创意设计的技术。

分而治之

从蓝图到草图，对线框图的一次次重绘将导致一系列连锁效应，页面或程序设计的工作分配和时间计划都将受制于它。当一个粗糙的设计描画出来后，团队中的一个人就不得不独自奋斗一阵子，把每个页面的草图设计都制作成细节丰富的线框图。但XHTML模式则提供一种分而治之的方法。在我的团队中，我可能负责初始部分的XHTML以及一部分CSS，而其他成员则在我的基础上修改XHTML，加入更多的高级CSS，还有JS。如果解决方案是团队共同提出的，那为什么不让团队所有人来共同设计呢？换句话说，与其用某人的观点来代替团队方案，为什么不让团队每个人都贡献自己的专业知识呢？通过使用XHTML，我们能够利用密切集成的CSS和JS，帮助团队成员使用一套整体思路来贡献自己的能力。

何去何从

当然，本文仅仅是在刺激那些对XHTML原型法感兴趣的人的欲望。如果你想更深入的探索这种方法，特别是那些正置身于传统瀑布模型进程中的人，我建议你们采取一种“小步走”策略。也就是说，先用这种方法做原型，然后与你的团队一起试验一个小型项目，以此作为基础。如果你的经验跟我差不多，你也会发现它对你的UX工具箱是一种异常强大的补充－一个跨越“体验vs技术” 鸿沟的更有效的方法！

UED团队合作与开发流程优化

波希米亚 — 2008-10-31 21:34:18

今年对我来说真是折腾的一年，年初3月份到被调到杭州去封闭开发（就是如今的雅虎口碑分类信息），半年后，9月末又回到了北京雅虎，投身于火热的“雅虎关系”中。可以说08年一半的时间在杭州做项目，感触颇多，也有很多要总结的。

谈到UED（用户体验设计）团队合作，就得先从团队的组成讲起，（接下来的描述都使用字母简称）
雅虎的UED团队配置包括：ID（交互设计师），UR（用户研究员），VD（视觉设计师）和WD（前端开发工程师）
口碑的UED团队配置包括：ID（交互设计师），VD（视觉设计师）和WD（前端开发工程师）

角色大概就是这样了，在实际项目中如何安排出场顺序就有些学问了。

在开发保姆分类行业化的时候，角色进入开发流程的情况是这样的：

PM（产品经理）编写PRD文档，并与交互设计师讨论，由交互设计师产出产品原型，得到产品确认后，召集VD，WD，ENG（后端工程师）开kickoff，宣布项目启动，接下来就到真正实现的阶段了。

从上图可以清晰的看出VD的介入点，原型完全结束后才开始视觉设计，产出一些效果图经确认后交有下一环节WD开始切页面、制作交互功能，WD完成所有页面后交给ENG套程序，最后联调，测试，上线。

到项目后期时间很紧张，因为项目实现一共就2周左右的时间，WD和ENG联调是占时间比较多的环节，所以经常加班到很晚。项目总结会上分析了一下各环节的配合和运转情况，ENG的工作是前松后紧，项目后期很疲惫，原因有以下两点：

前期一段时间拿不到UED方面提供的交付物，没法套页面；
与WD联调要占很多时间，WD交付时时间剩下不多，就得加班赶了。

UED成了瓶颈？还是其中哪个环节拖延了时间？
其实都没有。我们再来review一下上图，发现如下图这个区域似乎很空闲，那能否把这块利用上呢？

这块属于UED团队内部合作，当然我们可以想办法改变这种流水线般递推式的流程，并行开发，立体使用这块时间。来看下图：

我来解释一下，前期PM和ID的配合基本不变，但ID在这种开发方式中，所要承担的工作变的更多。
在与产品确认了原型之后，VD和WD同时加入开发，根据产品原型，前者做表现，后者做结构和行为，这也是起初“Web标准”所倡导的“表现与结构相分离”的思想，各做各的，互不影响。

注意，这次UED的伙计们玩的时候，可别忘了ENG，我们优化工作流程不就是为了帮助ENG改善开发前松后紧的状态吗！ID可以去与ENG交流：
ID：“你们要从什么页面开始做起？”
ENG：“我们先做表单逻辑，请先为我们准备表单原型、效果图和静态页面。”

ID这时候是半个PM（这只是与PM频繁换位中的一次），去协调VD和WD，并告知我们制作页面的优先级，这个优先级可以以ENG开发顺序为指导，并更快的给出相应页面经确认过的原型。
Tips：我把原型发布在局域网服务器上，可以通过浏览器访问到，这样可以方便PM确认，也便于VD、WD、ENG实时查看最新确认的原型。这样做还有一个好处就是，ID是产品原型的唯一出口，大家都到我指定的地址查看最新原型，避免因邮件传来传去，造成版本混乱，VD，WD做完一看“呀，咋都对不上呢？”

优化后的流程在做交友分类时得到使用，并收到很好的效果。同样的项目，不同的方法，可能带来的就是更高的效率。不要在项目结束以后抱怨“如果能再多给我3天，一定能把它做的更NB……” 。从项目开始时就找一个适合团队合作和项目实现的好方法，要比事后诸葛更着人喜欢 =）

参考：
1. 看千鸟整理的一个图，其中DEV应该对应我们的ENG，其中DEV应该对应我们的WD(Web Developer)：

2. 还有一个小软件，能帮你快速建立起局域网共享——迷你Web服务器

敏捷开发项目和可用性

萧小小 — 2008-11-30 20:13:44

作者： Jakob Nielsen

译者：萧小小 UCD翻译小组审校：Jarod

原文地址: http://www.useit.com/alertbox/agile-methods.html

摘要：

敏捷开发意在解决传统开发方式中存在的可用性问题，但是却对用户体验带来了新麻烦。然而，不少公司通过改造敏捷开发方法，在实现目的的同时避免了这些麻烦。

快速应用开发流程如敏捷开发和Scrum（译注：scrum是敏捷开发的另一种方式）是提高还是威胁用户体验质量，这取决于是如何运用这些方法。

敏捷开发的优势

敏捷开发解决了长期困扰可用性专家们的三大问题：

· 以过去50年的经验看，传统瀑布式开发导致了差的用户体验。原因很简单：需求说明书从来没对过。

o 理想情况下，如果严格执行，需求是可能反映用户想要的东西的。但是更通常地反映的是离操作层太远以至于不知道操作细节的“典型”用户们的要求。一般而言，用户想要的和用户需要的是完全不同的，这就是“观其行而非听其言”一直成为首要可用性指南的原因。

o 如果从撰写需求到交付产品需要很长的时间，用户的需求将非常可能发生变化，致使撰写的需求和用户实际的需求之间距离越来越大。

o 在过去的25年中，可用性工作中提高设计质量的最好方法之一是观察用户和该设计进行交互（through either a functional or mocked-up screen ）。假如开发者们在时间溜走之前没有这样做，那他们的大部分的开发工作可能是围绕错误的设计在进行。

·同样，在瀑布开发后继阶段，按照文档苟且行事会带来诸多问题，更糟糕的是让开发者对照文档逐条逐字实现。很多问题出现在实施交互设计细节之中，在陈旧的设计和用户体验专家也已经早已离开的情况下，让开发者解决可用性问题，有点不现实。

· 自1989年以来，因为其易操作性，在开发过程中可以被开发者经常使用的“简化的可用性工程”（discount usability engineering）被认为是提高用户体验的最佳方法。然而，在严格的瀑布开发流程中，这个方法根本不可能操作，原因在于无法在流程中获得用户反馈。

敏捷开发有望解决传统开发方法对良好易用性造成的系统障碍。

敏捷开发带来的问题

敏捷开发对系统质量最大威胁在于它是由开发者提出，主要针对系统实现的方法。结果，交互设计和可用性问题经常被低估，而被认为是开发过程的附属结果。这显然和过去30年的经验相矛盾，用户体验在系统开发中的重要性随着我们从大型机发展到个人电脑再到网络的过程中稳步增强。随着用户增多和使用范围的扩大，现实世界对搞可用性的需求日益增大。

为了建立好质量的用户体验，开发团队需要交互设计和可用性方法。对于小一点的团队，并不一定需要专门的设计师和可用性专家。让开发人员自己做交互设计和可用性考虑最为合适。但是，不管设计或可用性人员是专职还是兼职，重点在于在开发中要将交互设计和可用性设计作为单独明确的开发活动来实施。

对于一个认真做交互设计和可用性的项目，必须和编码一样平等分配“story points”（译注： Story point是用于评估完成每个Story所要付出劳动，使用相对尺寸来估计）。

另一个问题是，在开发中把一个产品分解成了更小的模块，让每人一次完成一个模块。此方法就冒了这样的风险：破坏了一个完整的用户体验概念——不同的部分始终如一的表现，帮助用户建立起一个完整的系统概念模型。最糟糕不过的是，界面设计成了修修补补的大杂烩。

为了解决这个问题，团队可以设计包括用户界面架构的“storyboards” 和“原型”，以这些工具为参考点来设计单独的模块。为了避免在前期花费太多的时间，团队可以设计如纸面原型（不用编码的）的低保真原型，就像我们一直提倡的那样。

敏捷开发团队通常在相当短的“sprints”中完成所有功能，一般就持续3个星期。以如此紧迫的期限，开发者们可能会绕过可用性设计，因为他们觉得没有时间去做测试或其它用户研究。

解决方案包含三个部分：

· 用几天时间来做一些可用性活动，比如用户测试。一个富有成效的方法是在确切知道测试时会用到的东西时就提前做好准备。每周一次测试是非常可行的，且提供了一个整合多个用户反馈轮回的极好方法，甚至在最短的“sprint”里。

o 我们有一个关于“怎样操作一回完整的用户测试”的3天课程，课程真实地就团队自己的项目进行测试。你可以在一天之内完成这种类型的快速测试，而且准备测试的时间和分析结果的时间总共不到一天。

·大部分成功的团队都采用了“并行工作”（parallel track）法，用户体验工作在开发编码之前就连续地进行了。因此，到开始开发一个模块的时候，该模块原始的用户体验工作就刚好完成。

· 最后，我们需要全面的用户调研（foundational user research），而不是单独针对功能点的设计开发。比较理想的是，公司应该在一个项目开始之前做这个工作。当然，大公司应该具备一些关于用户工作流程、人物角色和可用性指南的基本知识，这样以后的很多项目都可以参考使用。

让敏捷和可用性相得益彰

很有理由相信可用性和敏捷开发方法是一定可以并存来提高用户体验质量的。

· 敏捷开发提供了很多机会来克服传统开发方法中长期阻止可用性的一些问题。

·作为程序设计方法而不是系统开发方法狭隘地使用敏捷开发可能会摧毁近10年来在整合可用性和开发方法的进展。但是，正如上文所说，每个问题都有相应的解决方法。只要团队把它们当成明确的问题来解决，就不会有损产品质量。

互联网设计敏捷迭代

一叶千鸟 — 2008-11-20 01:08:57

Web-based Product Design Process - Spiral Model.pdf

做互联网设计最重要是为了运营，蓝图和文档好比做作业打草稿、画画先描白，经验丰富可以考虑先省下这步骤。因为如果不表现在具体web-based原型上，蓝图、文档再好也无法快速切入开发流程，做为有大局观的Producer应该尽快意识到这点。

UED团队合作与开发流程优化是以前在雅虎做产品同事写的，雅虎团队的产品工程师们技术好，而且有来自美国团队的协作经验传承，做前端编程一直是他们的强项。但传统瀑布模型进程必然要面对“前松后紧”问题，根源在于设计、技术团队要互相等。因此，如果规避必须从观念上做出调整：快速产出、快速迭代，也就是软件工程里的Agile and Iterative Development。

以前我也常抱怨做互联网设计没谱，一是资源紧、二是变化快。项目周期和人手似乎永远都无法满足，来自内部考虑不周、外部竞争压力双方的需求变更频繁。其实这就是互联网设计的常态，接下来提到的方法，分为三个大步骤，版本仅供参考。

Alpha.快速完成核心功能开发

这里“蓝图”只是个代名词，也许只有些蓝图片段，或规划片段。曾经我们在老板办公室开会，根据头脑风暴结果、会议记录直接做原型。这么说可能有点一觉回到解放前的感觉，事实如此，第一步很关键，但质量不重要。

因为开始就期望得到完善想法是不可能的。比如，你开会描述个东西，让同事提意见，可能大家什么都说不出来。但只要你动手做出具体原型，同事亲自测试体验之后，意见噼里啪啦一大堆就来了。在这层意义上，绝大多数原型是炮灰也应该。

最初工作用自己最熟悉、最快速的手法完成，别让开发团队等。当然，这部分代码质量将直接影响以后的迭代工作量，根据时间灵活安排。不要考虑的过于复杂，总结起来有三点：

尽早用web原型评估设计质量
制作避免过早陷入web结构和表现细节
设计避免过早陷入功能细节

每个业务都会有核心功能，也就是用户的核心需求，基本上做产品前都会考虑清楚。可能核心功能内还会有核心模块，意思就是逐步提炼，找准关键点下手，这样才能搭好框架。也许经过几次迭代后，这部分工作已经是个可以跑起来的低保真产品，颇具alpha版本规模。

Beta.迭代完成固化需求功能开发

搭框架不要下手太狠，别自以为经验丰富把盘子搞大。因为刚才说了，互联网产品灵活最重要，虽然需求变化是经常的事，但我们要把风险控制在最低点。接下来在已有框架内，用同心圆放大的模式，按优先级实现辅助功能迭代，直至需求固化。

与此同时，产品设计团队除了对低保真原型的继续支持，还应并行完善和提炼高保真原型，并且着手对产品规范中复用模块的持续化整理，主要分为三部分：

web呈现效果迭代。先做图再切效率太低，因此我是直接用css美化低保真原型，通常这步可以把效果做的很得体。实在有必要，最后再截屏用photoshop处理细节并完善css。
web结构和表现迭代。我自己可以完成html framework, css framework两大块。
web行为迭代。需要工程师协助完成javascript framework。

也就是说，在包括beta版本以及之前，重中之重是实现功能需求层的良好用户体验。可访问性、兼容性、可用性、标准化、搜索引擎友好这些具体指标不要过早引入到应用开发中，让它们都在高保真原型的迭代内准备就绪。

比如可用性，做低保原型时尽量用最容易的方式解决问题，不要过早追求“用户体验”玩花样。大量的js互动效果和ajax异步加载会给原型维护、迭代测试带来大麻烦。

再比如标准化，良好结构的web页面，很受应用开发工程师欢迎，样式表则无伤大雅。因此我们可以多花功夫先处理html结构，节省时间让css样式表与功能开发并行迭代优化。

Release.模块化迭代提升用户体验

至此如果一切顺利的话，应用程序已经模块化并测试通过，设计规范也已经模块化、并有针对性的给出了高保真原型界面标准。用户体验的具体指标，已经在高保真原型的迭代中测试通过。

经验丰富的Producer可能都了解，成熟网站真正模块化后的内容其实不多，无非头、尾、导航、页签、表格、列表、搜索等等。传统方法流程的没有把操作体验与功能体验割裂开来，以至于来回折腾，反复做了大量工作才让产品模块化。根据设计规范迭代提升用户体验有两步：

先处理界面视觉效果，比如分情况美化数据表格、文章列表等。
再处理界面交互效果，比如可以把某些跨页流程改为层异步加载等。

永远记住不可能一步到位，花本钱的创意设计要用保守方案，用户体验是奢侈的。对多数应用开发工程师来说，使用样式表控制表现是件神奇而时髦的事情。光秃秃的一个架子，加上css马上就能风光起来，并且还不影响已经开发出来的程序，有点不可思议。

其他

敏捷设计思路同样来自前辈们总结过的软件工程思想，只不过换在了设计支持角度。真正的敏捷设计必然与开发绑在一起，只在产品阶段的砍掉文档、砍掉步骤、砍掉管理对全局影响不明显。

对产品团队来说，应该不断利用等待空闲调整规划，用任务分解、故事板等专业手法出文档优化结构。敏捷设计关键不在技术有多高深莫测，而是动作要跟得上节奏，前后衔接得当，才可能把时间一点点抠出来。不墨守陈规，把专业方法打散使用，融会贯通于每个思考点。

UCD翻译小组的同学们已将Boxes and Arrows的这篇Prototyping with XHTML译成中文，操作细节和心得很丰富，关于快速迭代总结的相当好。类似方法我们也已实践近两年，并且主导执行过两款大型产品，核心思想超过90%重合，以上补充了部分本地化快速产出经验。

原文说“只需要花费几个小时，学习一下网上众多的在线教程，你就可以立即开始书写xhtml。”事实上即使计算机背景的同学，没有两三年功力，要实现兼顾前后的无缝协作都很困难，搞不好还会返工增加工作量。但长远来看，这样的训练很有意义，用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。

Spend just a few hours following any of the innumerable online tutorials and you’ll be writing XHTML markup in no time.

团队成员越少，沟通效率越高；每人承担越多，整体风险越低。这是行云流水的产品、技术并行迭代的优势体现。总之，除对瀑布模型进程深刻认识，方法流程得靠团队的内力来推动。

相关话题：产品设计流程参考源地址：http://blog.rexsong.com/?p=2365

互联网设计瀑布递推

千鸟 — 2008-11-19 11:15:11

Web-based Product Design Process - Waterfall Model.pdf

递推流程有明显的阶段划分僵化劣势，优点缺点显而易见：

适合技术较弱或缺乏经验的设计团队。
适合容易理解但很复杂的产品，易于组织和管理。
适合稳定的产品定义和很容易被理解的设计解决方案。
适合对产品规模的升级和架构扩展，质量容易保证。

与软件工程思想并无二致，基于以上特点，递推流程尤其不适合互联网产品的创新设计。虽然经过江湖前辈的努力总结提炼，我们在处理并发和迭代实践上已经有了不少突破。但我个人认为，都没有从根本上脱离“递推”的思路，简单搜集整理如下：

需求 > 设计 > 构建 > 测试 > 发布

基础调研 > 产品分析 > 交互设计 > 原型设计 > 详细设计 > 设计维护

概念阶段 > 探索阶段 > 定义阶段 > 细化阶段 > 开发阶段 > 发布阶段

可行性评估 > 产品原型 > 界面设计 > 规范整理、功能实现 > 上线 > 分析报告、优化方案

需求定义 > 快速原型 > 交互式模型 > 开发与上线

相关话题：产品设计流程参考源地址：http://blog.rexsong.com/?p=2633

我们的设计流程

承志 — 2007-08-13 22:28:49

淘宝面试的最后一个环节，是请应聘者向面试官提问，使面试官有机会解答应聘者对公司、团队以及工作等等方面的疑问。在我面试过的设计师当中，大约有三分之一会问我：“淘宝的设计流程是怎么样的？”我不是很了解问这个问题的人为什么会有如此高的比例。也许这是一个“安全”的问题，不会对面试有什么危害；也许目前设计师在工作中普遍碰到“流程”问题或“没有流程”的问题；也许这个话题涉及各家公司的“机密”，确实无从找到相关的资料。

总而言之，虽然来面试淘宝的设计师人数有限，但我斗胆假设：目前国内所有网页设计师中的三分之一想了解更多关于“设计流程”方面的知识，而我们也不认为这是什么“机密”的话题(我了解的各公司设计过程都八九不离十，名称不同，本质上是一样的)。所以，就在此简单介绍一下淘宝UED的设计流程，期望对这三分之一的设计师有所帮助。

Step 1：原型（Prototype）

设计的第一个阶段，我们称之为原型设计，主要是设计产品的功能、用户流程、信息架构、交互细节、页面元素等等。如果你觉得听上去这些概念都比较悬的话，我就用大白话来说：原型设计，就是完全不管产品长得好不好看，只把它要做的事情和怎么做这些事情想清楚，把它怎么和用户交互想清楚，而且把所有这些都画出来，让人可以直观地看到。

至于怎么画出来，那就随你了。用纸笔画，用白板水笔画，用Photoshop画，用Visio画，或者像我们一样用Axure画，都可以。只要把上面提到的这些都事无巨细地表达出来。

在原型的交付物（Delivery，也就是某个阶段的产出物）中，最重要也最常见的就是线框图（Wire Frame），这玩意儿不用多解释了，看下面这张图就明白：

在画线框图的时候，要把握好细节的刻画程度。有些东西只要画个框就行了，而有些东西需要把文案都设计好。以免你的老板或是需求方揪住角落里的广告banner该有多大这种问题与你纠缠不休，而忽视了最重要的页面主体部分。

此外，还要牢记：原型就是用来让人改的。它存在的价值就体现在被修改了几次，被更新了几次，以及它的下一步被少改了几次。

Step 2：模型（Mock-up）

在原型被大家接受之后，就该关心产品长得好不好看了。我们以“模型”这个词来统称该步骤的交付物。和原型相比，它关注于产品的视觉设计，包括色彩、风格、图标、插图等等。

要清楚的是，这不是一步由“美工”来“美化”的工作。视觉设计师需要对原型设计有深刻的理解，对交互设计和尚未进行的HTML/CSS/JS的 Code都要有充分的了解。如果不能从全局的角度来做视觉设计，则只能是做做把水晶效果改成金属效果这样的“自娱自乐”，而对产品本身没有任何有价值的帮助。如果原型说：“在这个页面上，A比B重要。”，那他的脑子里就要有十七八种可以表现“A比B重要”的视觉语言可供选择。这是对设计模型的视觉设计师的基本要求。

更高一些的要求，才是视觉设计的“原始功能”。“倒底是选水晶效果还是金属效果？”，“这个按钮选什么颜色好？”等等。这一类的思考和选择，应着眼于产品的气质、品牌等等，在各种产品间保持一定的统一，在用户心里打下视觉的烙印。其实要做到这一点是很难的，特别是还要满足上一点的要求。一般来说，如果能90%的把交互设计的成果和品牌形象表达出来，已经是很好的结果了。从我自己来说，就常常很郁闷不能用好的视觉语言来表达自己在原型设计中的想法，总是做完模型就打个七折:(

更更高的要求，有些问题用交互设计是很难解决的，这时就需要一个有创造能力的视觉师，可以从视觉设计的角度来创造性地解决问题（一时还没想出好的例子，想出来再补上）。

总的来说，模型设计是件非常困难的事情。它的工具是感性的，但设计过程又要求非常理性，必须在各种约束条件中解决问题。而目前能从较高的角度来来看“视觉设计”的人还不多，大多还停留在“效果”、“风格”等表面议题上。个人以为在“Web标准”和“用户体验”之后，视觉设计是Web设计专业化运动的第三波，市场的需求已经存在，只差有人推动一下。

模型的设计一般来说都是用Photoshop了，下是是个例子（与原型的例子对应）：

Step 3：演示版（Demo）

这步我就不多说了，Demo就是按照原型和模型用xHTML/CSS/JavaScript等等前端技术实现出来，以便后端的开发工程师可以接手编码。这个过程让小马、正淳专门起个新帖来详细介绍吧。只提一点，前端开发在有些公司是不放在设计团队的，而我们认为前端开发从很大程度上来说是对用户体验的提升和保证，开发只是它的一个手段和形式。所以就把这块工作一直留在我们团队，现在看起来这样很棒：）

把上述原型、模型转为xHTML/CSS之后就是这个页面了：

http://favorite.taobao.com/collect_list——-g,nrxwy2lumhgozsvz2cq3tk6w64-.htm

Step 0.5/1.5/2.5/3.5

居然还有半个半个的步骤？是的，这是我们的用户研究过程。在各个阶段的前后，我们会根据具体情况选择是否投入精力到用户研究上。用户研究的形式也很自由：给会员打个电话，旺旺上随便找人聊聊，到公司来做可用性测试，到会员家中访谈……怎么方便怎么实用就怎么做。我们还没有精力放在太多的“学术”性质的理论研究上，对研究方法也是不拘一格，“能抓老鼠”就行。关键的关键，研究的结果如何表现到产品上，如何吸收单个用户的意见来服务所有用户。

在这一点上，我们做得还很不够，积累也很薄，需要向同行们多多学习，也请大家多多指点。

最后……

关于流程，要注意：

设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”；
“100分”的完美作品，很有可能没有遵循流程，而是天才地融合了创新、传承和执行力的作品；
“流程”这种东西，只有与环境相匹配才能带来正面的作用。

以上是我们UED团队目前的设计流程，也许你也发现了，它和大多数公司的设计流程是差不多的。我们也在不断地修改和发展这个体系，有不足的地方也请大家多指教。如果你借鉴了我们的流程，在工作中发现有什么问题，也请回来告诉我们，谢谢大家！

阿里旺旺产品项目UED流程图

周强 — 2008-10-08 11:03:25

相关话题：产品设计流程参考源地址：http://www.zhouqiang.com/post/459.html

UCD 流程解析

Moond — 2008-09-21 14:41:07

细心的读客应该会发现，在昨天 Making Life Easy - 使生活更容易里提到一个英国的Flow Interactive 交互设计咨询公司，今天继续阅读了他们的网站，发现了他一些对UCD（User-centred Design 以用户为中心设计）的实施流程，觉得很有代表性，也很清晰，所以简单整理了一下，给自己和大家学习备份：

他们大概把UCD的流程分为了下面几个阶段：

Research stage 调查研究阶段
Concept stage 概念定义阶段
Iterative design stage 迭代的设计阶段
Implementation stage 执行阶段
Launch stage 发布阶段

图片来自Flow Interactive

下面是图片内容的解析，连接都有相应的安例解析，很有帮助。

Research (调查研究)

Context studies(背景研究)
Focus groups 关注群体
Competitor comparisons (竞争对手对比)
Depth interviews 深度面试
Questionnaires 问答
User personas and scenarios 用户角色与场景了解
User goals 用户目标
Usability goals 可用性目标

Concept (概念定义)

Concept models 概念模型
Usage scenarios 使用场景
Paper prototyping 简易原型
Usability testing 可用性测试
Expert evaluation 专家评估

Design (界面设计)

Product structure diagram 产品结构示意图
Process flows 程序流程
Wireframes 框架
Interactive prototypes 交互原型
Card sorting 卡片分类排序－就是把关键流程用卡片形式定义下来，然后不断组织，了解和挖掘最佳的排序模式
Usability testing 可用性测试
Accessibility evaluation 易用性评估
Expert evaluation 专家评估
Functional specifications 功能型详述

Implementation (执行测试)

Launch (发布)

Usability testing 可用性测试
Expert evaluation 专家评估
Accessibility evaluation 易用性评估
Focus groups 关注群体
Competitor comparisons (竞争对手对比)
Metrics 测量

因为UCD或一些新兴的用户研究课题，对于大部分设计师或研究员来说总是觉得概念模糊，难于掌握或不知如何着手，所以，我想不断尝试用简单清晰的方式来定义这些概念，使我们未来的工作有律可依，并更有效的完成手上的项目。如果有问题的请提出来一起讨论学习。谢谢。

相关话题：产品设计流程参考源地址：http://www.moond.com/lab/?p=29

人机可视化可用性规范流程

saidy — 2008-09-19 10:53:10

这篇ppt是好几位同事一起合作完成的，关于ppt的内容，讲的是人机组工作所涉及的流程“规范”。谁都可以制定规范和流程，而最最最重要的，是要“执行”！

供大家学习和参考！点击下载：youshang-20070216

产品设计流程参考 - UCD大社区

设计流程：官方流程VS.实际流程

从“产品需求文档”（PRD）到“产品设计文档”（PDD）

PDD的组成部分

用例

流程图

原型图

PDD的表现方式

用例和流程图

流程图和原型图

看到的alibaba和听到的Google

从一幅涂鸦谈设计

互联网设计操作参考v2

相关文章

小心，别让你的产品出轨了

主流互联网公司的产品项目流程

可用性工程的生命周期

用户体验设计指南的引入

互联网设计操作参考

组织理念并分层

组织流程和方法

组织角色和交付物

关联理念、流程和交付物

关联交付物、角色和方法

产品设计流程

产品设计团队的六种逻辑角色

产品从设计到发布的六个阶段

参考的资源

XHTML原型开发－用代码说话

一个迭代的过程

草图法：一件形式自由的事情

原型法：一个明确的回答

原型开发/打造关联

三个综合层次：结构(Structure)，行为(Behavior)，基础(Foundation)

结构层：建立页面的基本结构

XYZ Application

My Account

Account options

Account details

Account Help

Account Help

改进表现层

添加行为层：少作无用功

迭代：发现，改进

XHTML如何兼作设计说明

注释仅对个别人可见

更标准，无干扰

事半功倍

分而治之

何去何从

UED团队合作与开发流程优化

敏捷开发项目和可用性

互联网设计敏捷迭代

Alpha.快速完成核心功能开发

Beta.迭代完成固化需求功能开发

Release.模块化迭代提升用户体验

其他

互联网设计瀑布递推

我们的设计流程

Step 1：原型（Prototype）

Step 2：模型（Mock-up）

Step 3：演示版（Demo）

Step 0.5/1.5/2.5/3.5

最后……

阿里旺旺产品项目UED流程图

UCD 流程解析

Research (调查研究)

Concept (概念定义)

Design (界面设计)

Implementation (执行测试)

Launch (发布)

人机可视化可用性规范流程