白鸦，以用户为中心的设计

线索：http://ucdchina.com/topic/78

1、老冒承认了他的留言设计在本位思考。他认为自己才是blog的第一用户，这一点我们不同。
即使我会把我blog的第一用户定位为我自己，也不会把“留言”功能第一用户定义为我自己；即使我会把“看留言”的第一用户定位成我自己，也不会把“写留言”的第一用户定义为我自己。
每个功能的主用户群定位，不一定要符合产品的主用户群定位，不同功能主要面对的用户群不同。

给老冒两个建议： 即使你当自己才是第一用户，也要考虑其他用户的感受；即使“看留言”你是第一用户，“写留言”你也不应该是第一用户。 起码在文章的底部加两个链接吧，例如：“现有回复xxx条，我要回复”。

2、UCD大社区能否做成社区，其实根本无所谓。 因为社区只是我们的第三目标。 只要能做成”知识库”足矣，做成“媒体”更好，要能做成“社区”就太幸运了。
只要能达到我之前说的“以后你在互联网的产品设计中遇到任何问题，都可以在这里找到别人的观点”。足矣。
3、 我们理论，但很现实。而且不追求技术。
UCD大社区可以理解成完全人工编辑的一个网站。从第一天开始，我们就定下铁律：“审核。人工审核。每一条”。
原因只有一个：“质量”。

很多人担心我们的编辑能力，和人工成本。但，我们自己不担心，原因如下：
1》 现在中文内容就这么点，搞的过来。 内容增加了，我们的人员也在增加。总之，行业太小，UCDChina的团队相对不小。
2》 80%的人关心20%的内容，我们只追求20%的内容。 我们定位很小，不希望做到什么都包容，那样会给我们玩下去的压力。
3》 我们会逐步的加入先进技术来帮忙。但只是帮忙，技术可以给分类、话题的建议，我们只要审核。这样会省掉一半以上的工作量。

4、在做UCD大社区之前我向郑昀和他做语义的搭档请教了很多，基本上所有语义和聚类相关的网站都研究过。最后认为：Google新闻的语义方式，对blog来说不现实，而且技术我们做不到；TMM通过链接分析的方式可以借鉴；
但，所有这些，放到我们整理的几百个产品设计相关博客身上，都不现实。最现实的做法只有一个：人工。 先人工，慢慢让技术加进来帮忙。可以用链接、语义分析话题和分类，但在这个仍在告诉成长和学习的产品设计行业，唯一可靠的只有人工。

5、 我们选择人工还有一个关键的点：UCD大社区不是商业项目，是所有人团队成员的业余兴趣。人工玩才有兴趣，玩不了太大才能延续兴趣。 这很关键。
UCD大社区表现出来的观点和性格，就是团队的性格。我们在按照自己的性格玩。

分类：UCD | 14 条评论 »

这是回复老冒关于留言的探讨。

1、短留言有没有价值？
我从来不会把一个原则拿到所有地方通用。任何设计原则，一定是有自己的适用环境的。
老冒说他的blog上有价值的留言多数是短留言，而老冒没有来看我blog的留言，我这里有价值的基本都是长留言。（我甚至考虑过：我blog上所有关于产品设计的文章，应该取消留言）
我之前说“短留言没有价值”，是说了个前提的（老冒大概没有注意到）：“UCDChina主要是在很对产品设计领域，在这个领域讨论一定要有深度。”
当然，这个做法会把一部分的留言挡在外面。但，应该不会把大多数真正希望讨论的人挡在外面。因为，我们其实是可以“留言”的，那就是我们非快照页面右侧都会出现的“我来发布信息...”，在这里可以发表你的“长篇大论”。

2、UCDChina的社区是不是纯内容的？
这个问题很有趣，我们一直也没有对外说过UCDChina的详细定位。因为，我们认为互联网产品刚开始有个大方向就够了，真正的详细定位一定是边做边出来的。
但我们的思想其实已经分享过好几次。比如，很早以前我就说过“社区应该是液态的”（实际上，写这篇文章的大背景就是我那个时候已经在构思UCD大社区了），不久前tony也解释了“大社区的作用”。

3、在这里我可以明确一下“UCD大社区”目前的详细定位：

1> 互联网产品设计知识库。
我们期望，以后你在互联网的产品设计中遇到任何问题，都可以在这里找到别人的观点。而且是经过我们审核被认为有一定道理的观点，而且这些观点已经被我们聚合成了“话题”。
任何一条信息我们都会审核。审核的人都是国内比较顶尖的产品设计师，如果他们认为观点有明显问题会交给专家团（现在由我、anglea、junchen组成）复审，复审不通过不被录入。
注意：通不通过的原则不是观点是否和我们的观点一致，而是“是否有明显错误”。

2> 互联网产品设计领域的专业媒体。
所有我们抓取到的（包括自己在大社区提交的），认为产品设计人员应该关注的内容，都会被录入到大社区。包括行业评论，和重大的行业事件。
但是，和产品设计不是直接相关的行业评论等内容我们会放到“设计之外”。“设计之外”不会再首页出现也不会输出到主要的RSS里面。
行业事件我们也只是做到简单的“告知”，没有详细报道，没有评论。也就是我们认为产品设计师应该知道这些事情。

3> 产品设计师的“社区”。
这个社区是非常虚拟的，内容是非常技术的。大家互相通过blog讨论，通过UCDChina给话题聚合到一起，把用户领到你的blog去阅读和“点评”。比如，我和老冒现在这种行为就被UCDChina认为是一种社区行为，我们就是这种液态社区里面的“发言成员”（看的人都是潜水的，他们忍不住或者有深入观点也会写文章来讨论。在我们看来“写文章”是“发言”，简单回复是“点评”。）。

4> 除了大社区，UCDChina还有很多很多事情在做，但基本都是在辅助大社区。
比如，我们为了提高让更多同行看到更多精彩的文章，专门付出了大量人力和资源去做“UCD翻译小组”，并配合了详细的翻译和审核机制。
（在这里，必须特别感谢“翻译小组”里那些无私的翻译人员，你们造福了整个行业。包括这个英文极烂的白鸦。谢谢你们，我会找时间私人给你们送一份礼物的。）

4、关于对个人blog留言的“follow”我觉得很值得做。 事实上我也一直想在我的blog上做。 但，没有时间也没有技术做。
那些公开的和私人的、发送到twitter、RSS里输出留言的做法，很有意思，很值得去尝试。

5、老冒把自己blog的留言放到了页面右侧，我认为是一个错误的做法。
原因：
用户的浏览轨迹是从上到下的，看完了文章再去看留言，才能真正明白留言的意义。而把留言放到右侧最上面，用户看了文章是找不到留言的（点开文章时的心情是“很急迫的要去看文章具体内容”，根本不会关注你右边的“辅助内容”）。
特别是，基本上老冒的文章都超过了两屏，那个时候屏幕上没有留言也没有写留言的地方。（至少你也要给个链接让用户可以点到屏幕上面看看）。
当然，把留言放到右侧方便了老冒自己。但不方便读者。这家伙在本位思考…

6、总结一点：“UCD大社区”是一个“互联网产品设计的‘大社区’”，我们欢迎有深度的讨论。不欢迎简短的点评。
点评，去文章源地址。
问问题，去我们的邮件组讨论。
线下讨论，参加书友会。
看更多好的产品设计网站，收藏“UCD网址导航”。

.
广告：UCD大社区现在遇到了很大的技术瓶颈，盼望牛逼的技术朋友能给我们一些帮助。

分类：UCD | 14 条评论 »

（图1，阿北很早时候的豆瓣截图）

如上图，阿北的豆邮有1206封未读。（如果是邮件处理的，算特例，在此不做分析。其实邮件处理对于普通用户来说是把双刃剑…）
注：豆瓣的站内信最早包括关注通知、站内信等信息，现在“在九点的关注”还阴魂不散的出现在这里。

（图2，UCDCHINA的百度站内信截图）

如上图，UCDCHINA的百度站内信有50封未读。（前面一百多封的时候我还在百度，有信息就处理，粘度高的不能再高。后来交给UCDChina的团队用，这些站内信就都懒得处理了…）
注：百度的站内信是整个百度线的沟通渠道，包括所有百度可能需要发给用户的信息、站内信，甚至新用户注册的时候也有几封信。最早的时候这些信息在站内信里面连分类都没有，现在有了。

在豆瓣、百度、facebook、Flickr、5Gme.com…，你的站内信有多少未读？

为什么这些站内信失去了作用？ 原因很简单：欲废此功，必先自宫。

别指望用站内信来教育新用户。
新用户不会对“站内信”产生很大的兴趣，如果不是有相对迫切的“需求”，用户不会专门跑到你的网站看站内信和听你用机器说一句“欢迎光临”。给新注册用户默认发“欢迎”的信件，坏多于好（具体得看你的用户层次和产品性质，“欢迎”是最俗的主题，可以想想有没有更好的主题）。
发一封，并同时给用户提供方便删除的途径，有时确实可以起到提醒、教育用户对“站内信”的认知作用。但，某些网站在一注册就收到“欢迎”“系统通知”“申明”“密码安全”等四五封站内信。无异于自毁城墙，对于大部分非“初级网民”来说，他们看看标题就直接离开了。留下”站内信(4)”这个烙印，永不再用。（有些是为了推卸“法律责任”，这么干是最没有出息的行为）

清零。让用户清除压力。
已读、删除功能很重要。如果必须发，没有必要的话不要默认预览太多内容。一封看了标题就能明白大致内容的信，如果不是很有兴趣或者必须要处理，用户不会打开同时也懒得随手删除。两封、三封、四封.. 人都有天生的“懒惰性”，再无聊的用户，看着数字到了两位数，就失去了感觉，对站内信产生了天然的“免疫力”。
必须很突出的展现给用户很方便的“清零”功能，让他们很熟练的运用“清零”手段。甚至不惜以牺牲体验为代价，设置一定的阅读门槛（比如，默认预览内容少）让他们“打开”（打开=清零）。

最好把“系统通知”和“信件”分开。
繁复的不停更新的“系统通知”会让用户失去对站内信的兴趣，进而影响对真正“信件”的兴趣。在重要界面上（往往是首页）开辟一个“通知”区域很有必要，这样可以增强用户对“通知”的重视，也会降低系统对于“信件”的干扰。因为，站内信一般情况都只是在导航上有一个“未读数字”的提醒，用户可以很快的视而不见；而通知在首页上会是一块内容，相当于“眼中钉”，“清零”动作也变成了随手的“任务”。某种意义上“通知”就等于“任务”。

“站内信”不是取之不竭的“金矿”。
最害怕给网站添加站内信功能，因为每次添加站内信功能的时候，最重要的工作就是“谈判、立军法”。不立“军法”，不敢开战。
因为，站内信一出来，肯定是没完没了的“这个活动需要给用户群发…”“这个促销需要群发..”“这个新功能需要群发…”
没完没了、没完没了、没完没了… …

特别是一些根本不懂互联网运营（大部分运营人员还是很强的，少部分如此）的人，特别是一些只知道盯着PV看自身网站资源能割多少肉，根本不去管产品会不会废掉的运营人员，特别是一些只知道眼前KPI的人。 他们真的想象力匮乏，站内信对他们来说就是一个“金矿”、“救命稻草”，甚至不停的告诉你“打开率很高、效果很好…”
就算你不停的给他解释“打开率肯定随着活动的越多在不停下降，这个打开率的下降就是站内信这个功能的慢性死亡的征兆”，他们也一样熟视无睹。只知道不停的说“老板要KPI…”
如果没有军法，如果你的运营搭档很XX。你必须的得罪他们。或者你死掉。

当然，我不是反对完全不可以用站内信去做运营和营销的事情。只是“必须有节制”，必须把这些内容当作“对会员有用的增值服务”，不附和这个标准的就是在屠杀产品。

很显然，当一个网站技穷到只能在自身产品核心功能，或者核心和用户的沟通渠道上，附加大量多余营销内容的时候，这个产品/渠道（包括短信通道，给用户的通知邮件等等）已经患上了慢性癌症，死亡的征兆已经来临。
往往运营一段时间以后发现功能已经无法运转了，不是因为“产品有问题”，而是我们在市场运营、产品运营的时候给这些基础功能强压了太多，他们本不该承担的“责任”。 最终导致夭折…

只要是对用户有价值的功能，用户不会嫌弃。绝大部分时候，是你，是你逼着用户嫌弃它们。欲废此功，必先自宫。

.
最后，附图一张：

（图4，我的的5Gme.com站内信截图）

未读信息为0。这是我站内信利用率最好的一个网站。因为除了私信就是私信。不是因为他是sns，而是因为他抄的和facebook一样，分开了处理，没有干扰。）

分类：UCD | 22 条评论 »

实际上，“交互设计”可以分成两个部分：用户使用流程的交互设计、界面呈现的交互设计（我往往叫他单页面交互）。印象中，最早Cooper在解释“交互设计”时，说到的也是这两个部分。

所谓“用户使用流程”，源于“业务逻辑”，又不同于业务逻辑。因为业务逻辑一般都更偏向于技术模型，对于实际的用户使用来说会过于繁复，易用性很差。
这份工作，一般由产品设计师(负责功能设计、信息架构、‘交互设计’)来完成。比如，
（下面的例子，有兴趣的同学可以给画成流程图，理解起来会更形象）

这里有一个Push Mail添加帐户的“业务逻辑”（不包括错误判断）：
1》进入“系统设置” ，
2》进入“帐户管理(帐户列表)” ，
2.1 选择“添加帐户” ；
3》输入邮箱名称，
4》输入邮箱地址和密码，
5》填写手机号和签名，<可选择“跳过”>
6》设置邮件服务器，
7》最后提交、完成。

评估：如果把这个流程直接作为用户的使用流程，所有用户要完成这个添加帐户的过程需要7个步骤，至少8次提交。

经过“用户使用流程的交互设计”之后，这个“业务逻辑”应该变成更合适的“用户使用流程”。可以是：
1》进入“系统设置” ，
2》进入“帐户管理(帐户列表)” ，<如果现在一个帐户没有，直接跳过帐户管理开始添加帐户>
2.1 选择“添加帐户” ；
3》输入邮箱地址和密码，
3.1填写邮箱名称、手机号和签名，<可选，默认邮箱名就是邮件地址，签名就是邮箱前缀，手机号可以不填>
4》设置邮件服务器，<在第3步就判断“该邮件后缀，服务器上是否已有配置记录”，如果有，直接到完成界面，同时提供更改配置的入口。>
5》最后提交、完成。

评估：7个业务逻辑上的步骤在这里变成了6个。用户的8次提交变成了最少3次。且80%以上的时候可以少于4次（数据显示，使用量最高的10个邮件服务商拥有了80%以上的用户）。

后，经过讨论，我们考虑到“安全问题”和“商业价值”等多个因素，认为：“有必要相对牺牲一点体验，已达到‘让大部分用户主动填写手机号’的目的”。
于是最终的方案改成了：
1》进入“系统设置” ，
2》进入“帐户管理(帐户列表)” ，<如果现在一个帐户没有，直接跳过帐户管理开始添加帐户>
2.1 选择“添加帐户” ；
3》输入邮箱地址和密码，
4》填写邮箱名称、手机号和签名，<默认邮箱名就是邮件地址，签名就是邮箱前缀，手机号为空。可以选择“跳过”>
5》设置邮件服务器，<在第3步就判断“该邮件后缀，服务器上是否已有配置记录”，如果有，直接到完成界面，同时提供更改配置的入口。>
6》最后提交、完成。

评估：7个业务逻辑上的步骤变成了6个。用户的8次提交变成了最少3次，常规4次。

当然，这个“用户使用流程的交互设计”提交物不只是业务流程图，而应该是“带界面的使用流程图”。如图。

.
所谓“界面呈现的交互设计（单页面交互）”，实际上是“UI设计”（也就是，我在建议“取消用户体验部门”中说到的“视觉设计”）所做的工作。对于“界面呈现的交互设计”来说，“使用流程图”的每个具体页面的“页面内交互”都只是“建议”，有权更改每个页面的“交互方式”。

还是上面的例子，
“使用流程的交互设计”已经规定好了，“填写邮箱名称、手机号和签名”必须“由一个单独的页面完成，而且默认不跳过”，但进入这个页面后“光标默认到什么地方？”，“界面呈现的交互设计”应该思考。
在“使用流程的交互设计”时，或没有考虑到光标默认停放的问题，或放到了“邮箱名称”上，都是不合理的。“界面呈现的交互设计”应该在这个时候给优化成成“光标默认停留在‘手机号’的输入框里”。

这个例子里，“界面呈现的交互设计”表现出来的作用可能并不够强，再比如，

(图1,Google短信提醒的手机验证)

在这个页面中，用户往往输入手机号以后不知道“验证码是什么？ 哪里有？”
事实上，也许我们把“获取验证码”作为一个更突出的内容会更合适一些。

简单优化如下：

(图2,Google手机验证的简单改进)

这样一来，输入手机号码虽然还是在一个页面中，但用户在输入手机号码的时候只能有一个“获取验证码”的操作，不会再疑惑。

总结：
简单来说，“用户使用流程的交互设计”是站在产品和体验两个角度，更合理的进行产品设计。即保证完整的业务逻辑和产品利益，又用最小的交互成本让用户完成任务；“界面呈现的交互设计”更多是站在易用性的角度优化“人机交互过程”，让交互成本再小，易用性更强。

在成熟的团队，或者交互更复杂的产品中，有人专门做偏向于产品的“流程交互”，有人做偏向于UI的“页面交互”更合适些，因为你经常会发现你的产品人员不懂界面设计，你的界面设计人员不能产品流程…
还是那句话：团队中如何分工无所谓，有什么样的职位无所谓。不一定非得分开“流程交互”和“页面交互”，但这些事情都是要有人做的，分不分开要看你的实际情况。

本文，只是为了解释：“交互设计”不只是“单页面交互”，更不只是“流程改进”。
好的视觉设计师/UI设计师应该担负起“界面呈现的交互设计”的任务，不能只做视觉；偏产品的“用户使用流程的交互设计师”，并非“必须具备视觉设计能力”。

分类：UCD | 42 条评论 »

我的PPT，下载地址：http://uicom.net/uf2008_WhyUDesign.pdf
有效期致2009年1月1日。

分类：UCD | 39 条评论 »

如今，CTO下面带三个部门：研发、产品、用户体验设计（UED），几乎成了成熟互联网企业的标准配置。在整个行业对于“用户体验”认识还不够的时候，这样做比较有利于产品体验的提升。

但，随着用户体验工作不断的深入，问题逐渐呈现。

1、关注并参与到产品的用户体验设计，应该是整个公司的责任。但，往往正因为有了UED这样一个部门配置，导致其他角色冷眼旁观，或者被凉到了一边。
用户体验，不是一个部门的事情。

2、无论从权利还是能力的角度来讲，对UED都是很大的压力。很多时候产品体验不好，不一定就是设计的原因，更不一定是用户体验设计师的原因。但，只要体验不好就是你不好，谁让你叫UED！

3、用户体验设计一直在深入，我们从最早的UI到人机交互，又到信息架构、内容设计，不断的切入到呈现层的每一个环节。
虽然看似并没有触及到“产品方向/策略”的事情，但，对于呈现层甚至重要于结构层的网络产品来说，UED的工作和产品团队的工作重合度越来越高。矛盾也越来越大。当一个UED去讨论UI之外的设计时，从“身份”来讲就已经被别人不认可了，直接影响对“设计”本身的接受程度。

4、对于产品部门，这也是一件特别痛苦的事情，产品的工作范围具体到什么程度，是否需要涉及具体的呈现，同样是个头痛的问题。因为，后面的界面设计影响了产品的效果，也是经常发生的事情。

5、总得来说：UED责任和压力太大，而且做事束手束脚；产品既要制定战略/方向又要设计呈现层，不能专心深入做事。

产品应该更专心的去考虑商业、市场，更专心的去把握和主导产品大方向；设计应该更加尽情的去设计产品呈现形态。用户体验，是大家的事情。
所以，我认为，“用户体验设计部”这个叫法是错误的，应该取消。将产品和设计两个部门重组，CTO带研发，产品的VP带产品和设计。

1、产品市场部：
工作内容：商业和数据分析、产品方向制定和架构规划。工作从商业开始，到需求分析止，连“功能设计”都只是作为建议方案。
角色如：数据分析师、产品经理架构师、(用户和商业)需求分析师、等；
人不要多，要精，决定方向和策略。

2、产品设计部：
工作内容：内容设计(主要是功能)、信息和交互、视觉设计、前端开发。工作从功能设计开始接手，到前端开发止，包括技术类的需求分析。
角色如：产品设计师（内容设计、信息架构、交互设计）、(技术)需求分析师、视觉设计师、用户研究员、前端开发、文案创意、等。
负责所有呈现层的设计、具体执行。

当然，如JunChen所说：“重要的不在于叫什么名字，而在于是什么人在做什么事”。但，事实证明叫法确实形成了很多阻碍；而且，不把产品设计师放到现在的UED队伍，会导致重复越来越多。
这个想法由来已久，虽不是很成熟，但好处有坏处也有。这样做，以”产品市场”为主导，以”产品体验”为核心。对于产品和体验非常重要的企业，好处多于坏处。

PS：
对于小企业、非互联网企业、不需要产品主动的企业，此法不可行。

.

.

为了保证回复质量，以后我的所有设计类文章将彻底关闭评论。 回复，请到UCD大社区发表你的观点。

分类：UCD | 4 条评论 »

1、目前来看，百付宝仅仅只是C2C的一个支付后台。他的内容只集中于“钱和订单”两个环节，没有其他干扰信息。

2、百付宝的界面表现很简单。因为简单，所以清晰。
每一个界面，你都可以很清晰的看到主要有什么，可以干什么。每一个点击、每一步，你都知道自己在干什么，下一步会是什么。

3、在百付宝，你不会混沌，不用反复的问自己“我是在哪里？我在干什么？我该怎么做？这一堆信息和内容都是什么意思？”。
更不用反复的不停的输入各种密码。

4、在这里，简单就是清晰，清晰就是易用，就是好的体验。

5、相对而言，支付宝现在有些臃肿。
瘦身？有必要。

。

6、目前来看，百度有啊借鉴ebay的痕迹比借鉴淘宝的多一些，商品管理上还差很远，界面设计上很简单。

7、在淘宝，琳琅满目，满眼花花绿绿，热热闹闹；挑的眼镜累、手软；你甚至不知道到底该买哪一个。
在淘宝，你很爽。

8、在有啊，区域切割整齐，规规整整，冷冷清清。冷清，不只是因为人少、货少，还因为货架小。
在有啊，你没欲望。

9、如果说淘宝是一个热火朝天的大集贸市场，有啊给我的感觉就是一个冷冷清清小门市店。
（再强调：这种冷清不只是因为人少货少，而是因为界面风格就这样）

10、有啊的简单，到了简陋。简单到了没有购物欲望。

。

11、简单，一向是百度的信条，Robin.LI一直强调：“简单，可依赖”，从郭宇进百度到离开一直遵循“多余的，都去掉”。
但，简单，就是好？
不，易用才是好。

12、当我们觉得某个产品很简单，感觉体验很好的时候，认为好的原因是“简单”；
其实，是我们感觉好的真正原因是易用，不是简单。

易用不等于一定要简单。

分类：UCD, 电子商务 | 37 条评论 »