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

这是为了跟keso的《继续跟白鸦抬杠：真正的需求》抬杠。虽然他所说的其实根本和我的观点没有冲突，是很好的补充。

事实上keso说“看看自己能做什么菜”，一定是基于“需求”而产生的。
任何一个产品价值的基础在于“有没有用？”，而不是怎么用。没有需求，或者需求搞错了，做什么菜都白搭，这是基础。就算福特没有“内燃机”这盘菜，只要他能确定“更快”的“更好的交通工具”，并从中发现其对用户的价值。他依然可以搞出另 外某种工具，需求会满足，期望可能有所降低，但产品依然会有价值。

但，如果不去了解真正的需求，只一味的盯住“内燃机”这件事，搞出来什么不靠谱的东西，天知道。这样的错误，乔布斯在搞“牛顿”的时候就犯过一次。很多纯技术研究者依然在犯…

当然，需求和期望包括keso所说的“用户愿意付出多少钱”等。
比如，在支付宝，我的产品经理只需要告诉我：“这些货物，200公斤，2两内从杭州到北京， 客户预算大概在50块，用火车运送”。我拿到信息后会还先过滤掉“用火车运”，因为这是“功能”，对我没太大价值，其他的信息才是真正的需求和期望。然后，我要做的事情就是去设计，如何满足需求，超越期望，获得利润，甚至是引导新的需求引发更多预算 …  这就是我，一个基于用户体验的产品规划者所做的事情，除了产品设计还要考虑成本、定价、利润。

keso另外一个关于音乐的例子，其实正好是一个反例。
如果可以确定：“消费者购买音乐，他实际购买的不是歌曲，而是娱乐，是休闲”，那我就一点也不会晕，答案很肯定：“卖歌曲只会是功能/方式之一，但真正的目的应该是满足娱乐”。
一家专门制造音乐产品的公司，转型做“游戏机”、“聊天室”显然跨度太大，“卖歌曲”、“彩铃”就相对合适些。 如果没有搞清楚“卖歌曲”的目的是娱乐，而去打什么“文化牌”，无论再清楚自己的能力，一样没戏。

我的思考轨迹很简单：有什么可做？（需求、期望） 》 能做什么？（我的实力） 》 什么更合适（各种环境）？ 》做什么？（功能）

原因很简单：期望值是可以商量的。
如果能力不够，但需求很迫切价值很大，那就换个方式减低期望来满足需求。 就好像史玉柱卖脑白金一样，可能期望是“面子”和“保健”两个，但他搞不出来真正的保健品，那就用褪黑素加自来水，只满足“面子”，一样可以搞定问题，赚 到钱。虽然没有给用户带去更多的真正的价值 …

《Design IT. (5)，有什么可做？》，会详细说这个思路。

.
ps：继续关闭评论。

分类：Design IT., UCD, 电子商务 | 发表评论 »

这是《Design IT.》系列的第8篇，因为年前大家对于“装不装用户”和“创业，管哪个事最重要”讨论的比较热烈，所以跳到前面来写。

先来看一个老掉牙的故事：福特说，我在设计汽车之前，到处去问人们“需要一个什么样的更好的交通工具？”，几乎所有人的答案都是 ── 一匹“更快的马”。
“更好的交通工具”代表用户的“需求”；“更快的”是用户对于解决这个“需求”的“期望值”；“马”是用户对于解决这个“需求”的自假设“功能”。

一个初级的设计者，被用户牵着鼻子走。听到“更快的马”以后，会马上去设计一匹“马”。这个时候，无论在“马”上如何做创新，思路已经框死，结果很难突破。最终只能出来平庸的设计，很难长久很容易被模仿和超越，实现不了多大的商业价值。

一个合格的设计者，和用户一起走。听到“更快的马”以后，会考虑“更快的”这个“期望值”，围绕着它突破“马”的局限，去做设计。最终可能会出来很好的设 计，但他们把“需求”本身跑道了脑后，最终只能简单的满足期望实现需求，而无法引导需求。他们可以做出来成功的产品，但随着用户期望的增长，这样的产品很 难有取得用户的长久青睐，也很难取得商业上长久的成功。

一个卓越的设计者，自己会作为用户的一部分深入了解他们，并带着用户一起走。听到“更快的马”以后，他们会先去考虑需求是“更好的交通”工具，然后再结合 “更快的”这个主要期望。用对用户最有价值的方式在满足期望的超越期望(把“马”这件事抛到脑后)，从而引导需求，并获取更丰厚更长久的商业利益，和用户双赢。

不可否认，史玉柱是一个商业的天才。
他发现了“送礼”这个大需求，并发现了送礼的期望在于“面子”而非“ 实用”。于是他通过“广告”在推广的同时增加产品的“价值”，而非在产品质量上增加“价值”。春节，杭州人告诉我：“我们春节送礼都是送保健品，广告播什么就买什么，因为有 知名度”。但他忘记了，这样是否可以给用户带来真正的长期价值。生活层次相对较高的行州人又告诉我“我们不买脑白金和黄金酒，那些都是骗人的档次低。我们买灵芝、鹿茸、人参、…”。
他发现了“砍人”的需求，并发现了“花再多钱也要砍死他”这个期望，最终使用了“网游”这个功能，用最简单粗暴的商业设计获取暴利。但他忘记了，这样做不能给人带来真正的价值，于是最后他在利用互联网社区引导需求的时候遇到了问题 …

福特是一个商业的天才，更是产品的天才。
他可以发现人们需要“更好的交通工具”这个大需求，并肯定了这个需求的渴望程度会随着社会交往的扩大会越来越强。同时他肯定了“更快的”这个用户的首要期 望，结合这个期望开始思考。然后，他又判断出汽车比火车有更低的成本，而且对于用户更有价值，会替代火车。最后，他用“汽车”而不是“马”来实现需求、满 足并超越期望， 同时引导用户往下的进一步需求和期望… 于是，他的商业回报自然而然的产生了。

用户的真正需求是什么？ 》 用户的期望值是什么？ 》 如何实现才对用户最有价值，并让企业获利？ 》 如何超越期望并引导需求，获取更高更长久的商业利益？
这是一个必然思考逻辑，违背这个逻辑出来的产品势必难以获取长久的成功。从某种程度上来说，产品模式是“用户真正需要的是什么？”，产品设计是“主要满足 什么期望值，给用户带去什么价值？”，商业模式是“用什么功能，如何赚钱？”，创新设计是“如何超越期望，获取更高更长久的利益？”。

所以，我在同意邵亦波所说“创业者更应该注重‘产品’”的同时，主张一个产品的主导者甚至是一个企业的领导者，更应该注重：
产品模式的设计：用户真正需要什么？
产品的设计：主要满足用户的什么期望，给他们带去什么价值？
创新设计：如何超越期望，获取更高更长久的成功？

至于单纯的商业模式设计，当你做好了产品模式的设计、产品的设计、创新的设计，会发现那其实只是“功能的设计”而已，可以找到更多的执行者去做。

(张亮跟我约一篇关于“apple为什么可以将用户体验作为核心竞争力，取得卓越的成功”的文章。我说因为有Jobs和他的思想，某种程度上，我认为Jobs就是这样的人… 明天尝试详细回答张亮的问题。)
.
.
ps 1：期望值的变迁、期望值
PS 2： 《Design IT.》接下来的两篇是，“Design IT. (4)，团队和决策 ”、“Design IT. (5)，有什么可做？”。
(《Design IT.》系列关闭评论，请在你自己的博客用“文章”回复，或者将你的文章发布到UCD大社区里。这些文章都会聚合成话题)

分类：Design IT., UCD | 4 条评论 »

本篇针对的是Keso的《别装了，你不是用户》

1、 我说：首先必须告诉自己：“I’M Not User” ，如此同时还要再把自己模拟成一个平凡的用户，不停的反复的去用自己的产品，和同类产品。
但，装的前提依然要不停的提醒自己“我不是用户，不要本位思考”。
装，是为了让自己站在用户的角度思考问题，而不是不停的拿自己当用户。 这是一种产品设计者的态度。

2、在产品设计中，只靠定量数据发现问题，往往结论是不正确的。
只有1%的人用广场，这个数据不能确定“广场一定是不好的”，造成这个数据的原因有很多，如果只是因为这个数据做出判断，是很武断的。我相信阿北也不是仅仅靠数据做出的判断。
比如（以下未经证实），豆瓣的“收藏”刚开始是“想读、正在读、读过”直接展开，后来改成了收起来的“收藏，”点击后才出来“想读、正在读、读过”，现在有改回到了最早的方式。
在改成收起来的“收藏”时，数据告诉我们点击是下降的，这个下降的原因是什么？ 数据不能告诉我们，只有用户才能告诉我们，是因为：“‘收藏’的贡献成本高，‘想读’的贡献成本低、自然”。

有时候这个原因是从自己“装”做一个用户的时候得到，能不能在“装”的时候得到，要看“装”的水平。当然，通过定性的用户研究，是可以得到的，但那样成本高。

产品设计的数据分析者，要清楚：定量数据只能看到结果，看不到原因。 必须跟定性的用户研究结合才能找到真正的原因。

3、啤酒和尿布的事情已经很老了，在中国柜台不是这样摆的，所以在5G问有没有人看到，答案是“没”。
就算这个故事的真实性值得怀疑，但方法依然是正确的。 产品设计者看问题不关注答案，关注得到答案的过程和原因。

4、K总对于用户研究的理解比较片面。 可用性测试确实5个用户就够了，可以发现80%左右的问题。但用户研究不只是“可用性”，可用性只是用户体验的很小一个方面。
而且，有些时候用户告诉你的答案可能会是“欺骗性”的。 比如，sony在要确定BoomBoX颜色的时候找了一群用户来问，“喜欢黑色还是黄色”，没人都倾向于“黄色”，临走的时候让这些人选一个带走，他们却都选了“黑色”。（有个介绍这件事的文章在这里）
还有，“5个用户”的前提是“这5个用户是很准确的典型用户”。

5、乔布斯是会看数据的，也会了解用户需求。但，他的决策不只是浮在数据和需求上，而且“超出期望”。 就好像福特听到“需要一匹更快的马”时，不会像普通设计者一样设计一匹马，而是搞了一个很快的汽车。
Design IT. 的第7篇《需求和期望值》，我会写。产品设计，应该超出期望值。

6、把产品拿给用户用，把诗读给妇女听，来发现问题，是产品验证过程很必须的方法。 但，这不代表自己不要站在用户的角度去思考问题。不在网上买东西的人，确实没有资格去做电子商务的产品设计师。

装，必须的。 关键是，要知道自己是在装。 这是一个矛盾的问题 …  但，如果连装都不装，只是看数据或者本位思考，就更没法做了。

ps：依然关闭评论。 原因很简单： 我需要深入的回复和讨论，不需要“沙发”、“支持”、或者“顶”！

分类：Design IT., UCD | 16 条评论 »

一堆数据摆面前，数据背后有什么样的事情在发生，这些数据里面暗藏着什么样的用户需求，什么样的商业机会？看懂这些，将为未来产品设计的方向，用户需求的把握起到关键性的作用。
但，“看不懂数据”是一个普遍的问题，而且是一个永远存在的问题。 基本上，我认为原因都出在看数据的人身上。
.
1、不配看数据

产品设计者对待数据的态度，不像一个市场分析者或者财务分析者。我们看数据，更多是需要了解数据背后用户的行为逻辑和期望需求。这就要求我们看到数据的时候，必须第一时间想象到用户是如何创造出这些数据的，为什么会创造出这样的数据。

作为一个产品设计者首先必须告诉自己：“I’M Not User” ，如此同时还要再把自己模拟成一个平凡的用户，不停的反复的去用自己的产品，和同类产品。我向来认为，一个做移动互联网的产品设计师，不有事没事换手机玩，不是好的产品设计师；一个电子商务的产品设计师，不每周在网上买一件东西，不是一个好的产品设计师。

06 年中，在某个用户体验设计的会上，某知名教授大讲他所在公司搞到的facebook的数据，说他的理解、说他的分析，说facebook如何没戏。刚开始听着蛮有根有据，后来越听越不对味，突然他冒出来一句“虽然我从来不用facebook”…  我当场昏厥。这种人，不配分析facebook的数据，更不配去评论。

要想有资格去看数据，通过数据给产品设计提供有效的依据。方法很简单，也很有效：把自己当作一个平凡的用户，不停的用。有，且只有这么一个方法。
.
2、为了看数据而看数据

和做可用性测试一样，测试之前不能说没有“关注点”，发现什么就是什么。那样什么也发现不了，即使发现了，价值也不大。数据拿到手里，没有目的的去看，不如不看。

在做产品设计的数据分析之前，首先应该搞清楚自己需要什么样的数据来说明什么问题。一个数据对于不同的产品、不同的环境、不同的用户类型，得到的结论应该是不一样的。传统的市场研究中，对于数据的分析往往是根据“硬属性”，比如他们对于用户的分析基本都是根据“人口属性”的数据，他们得到的结论也很少结合现实环境。这样的结论，对于（互联网的）产品设计基本上没有太大的参考价值，特别是如今个性化需求越来越强，用户行为越来越独特的时候，“人口属性”很不能代表用户背后的行为逻辑。

比如，想了解“有购物搜索需求的网民”具备的主要特征，这个时候“年龄、学历、性别、收入、婚姻状况、消费能力、信息获取方式、上网条件、..”可能都是对我有参考价值的数据，但那些才是最重要的呢？分析后很快就可以发现，比较而言“年龄、收入、上网时间、上网条件”都不是最重要的，“消费能力”、“信息获取方式”在这里才是最重要的特征。这些数据背后才更能代表用户的行为逻辑和需求。（如果不是很明白这个结论，稍后再《Desing IT.》第8篇左右会谈到产品设计上如何区分用户属性）
.
3、不去筛选数据

做一个优秀的设计者，首先必须善于“提问”。“提问”的水准和设计水平基本成正比。要什么样的数据，什么样的数据可以帮我解决这些问题和疑问？这个很简单，一罗列你可以想到很多很多。但，事实上数据类型到达一定数量后，类型越多，反倒越不利于对于结论的判断。因为，不同数据类型之间会产生相互的干扰，有些时候次要问题可能会战胜主要问题，影响最终的结论。

在实际项目中，解决了主要问题，次要问题可能就会很自然的被稀释了。获取数据也一样，必须搞清楚什么样的数据最能说明这个问题？确定这些会使分析过程的精力更加集中。把主要的几个问题想穿、打透，其他问题很快就会迎刃而解了。

很多时候不是解决不了问题，而是想解决的问题太多；很多时候不是数据不够，而且想要的数据太多。还比如，想要了解如何解决“购物搜索”的需求，其实只要关注好“信息获取方式”、“消费能力”、“决定购买的因素”基本就能解决很多问题，盯着“用户是男是女，8岁还是80岁”，只能是耗费精力。

不去筛选数据，还有一个很大的危害就是：“因为没有筛选，所以不能把关心的数据点看透彻”。
比如，很多人都在夸开心网的推荐做的好，很多用户在上面找到了自己的“同学”，于是定论为“算法的技术好”。其实如果专注关心“开心网为什么打通用户关系这么快”的人，经过详细分析后是不会得到“技术好”这个结论的。根据我的观察，我比较赞成麦田的结论：“开心网把校友录的数据库用进去推荐算法里面了”，我甚至认为开心网的推荐里面不只是用了“校友录”的数据库，还有更多其他数据库。 （麦田对于数据的分析虽然是偏市场和运营性的，但其实对于产品设计的促进一样很大，而且他确实是一个观察数据很细，研究数据很深的人）
.
4、不关注数据采集的方式和方法

当我们为某个项目寻找方向或者确定某个决策，需要一些数据的支持，以便了解状况并确定思路。这个时候，不仅需要给出“需要什么样的数据”这个需求，同时还应该包括如何得到这些数据。

很多时候，我们只提出需要什么样的数据，并不去提出要求如何得到这些数据的方式、方法，完全依靠调研者的经验去获取数据，这是不可取的。因为这样来的数据对结果的帮助是不准确的，甚至往往会出现误导。因为调研过程中不同的方式方法，得到的结果会不一样。

比如，还是要做一个购物搜索的网站，你给出的“需求”不应该只是“用户目前获取信息的方式”、“搜索的商品类型”等，还应该包括数据的来源，以及获取的方法。现有搜索网站？问卷？电话？…
不同的方式方法，渠道，得到的数据是不一样的。不同水平的人采集到的数据结果也是不一样的。

往往我很同情国内的同行，大家能找到靠谱的数据真的少的可怜。就拿行业数据来说，基本上国内没有一家第三方机构可以提供靠谱的数据。XX统计局就不说了，比如商业机构艾瑞，他的数据丝毫不具备可信度。最根本的，我们可以去看看尼尔森在欧美（不要看国内的尼尔森，那是同样的不靠谱。跟他们合作过一次，东西做的一塌糊涂）的一些问卷，从问卷设计的逻辑、采集方式、统计方法，甚至包括“埋地雷”的方法，都高出国内这些数据提供商一大截。（比如一个细节：去尼尔森在欧美的一些问卷试试，如果你是玩的心态，很快就会被说“谢谢你参与调查”。因为，他们很快就通过“地雷”判断出你并非真正的采集对象，很快就把你踢走了，而国内的你可以随便玩）

有些时候，如果实在没有办法，去做小量的抽样数据，也比那这些不靠谱的数据去分析强。
.
5、只用定量数据，没有定性数据

还说那个最老土的例子：
沃尔玛每天总重要的事是“想尽一切办法，把货架摆好，让顾客更快的找到，更快的走掉”。事实上，当他们的MBA（商业数据分析）人员通过庞大的数据处理系统发现，啤酒和尿布的销售曲线惊人相似的时候(特别是在周末)，他们其实只能得到一个“结论”。但，这些知识定量的数据，并不能挖掘出本后的顾客行为，以及为什么会造成这个现象。这个时候，如果靠“分析”、“猜测”是不能得到正确结论的，方法只能是去结合“定量”的研究，通过具体观察和调研了走到用户身边，最终才能了解到“因为，在美国一般都是男人去买尿布的，而在沃尔玛就算买1美元的东西也要排队半个钟结帐，男人们周五往往会呆在家里看球，这个时候就顺手拿了啤酒犒劳一下自己”。

海量的定性数据，只能告诉我们结论，不能告诉我们背后的原因。同样，如果只有定性的数据，往往看到的现象可能是片面的，结论可能是有偏差的。（关于定性研究，稍后章节详细解释）

.
还有一些常见问题：只关心数据结果，不关心过程（比如，就知道那个广告的流量大，没注意那个广告比别的大三倍）；只看大数据，不看小数据（比如，只发现交易量疯狂增长了，没注意虚假交易疯狂上升了）；只看数据表象，不看发展过程（比如，只知道现在的行业分布均衡，没发现曲线的前方已经出现裂痕）；等等。 因为没有方便拿出来说的实例，不再一一絮叨 …

其实，
要看明白数据是个很简单的事情，但要真正懂数据背后的原因和逻辑，是一个很难的事情。自问，我依然只刚刚上路。
不过，可以肯定的是，随着对于用户的接触越多，对于用户心理模型的理解越透彻，对于业务逻辑了解的越透彻，一定会带来对于数据的理解能力越强。 共勉

PS： 《Design IT.》接下来的两篇是，“Design IT. (4)，团队和决策 ”、“Design IT. (5)，有什么可做？”。
(《Design IT.》系列关闭评论，请在你自己的博客用“文章”回复，或者将你的文章发布到UCD大社区里。这些文章都会聚合成话题)

分类：Design IT., UCD | 4 条评论 »

对于什么是好设计，一万个人那里至少有一万零一个答案。每个人都有自己的答案，有的人还不止一个答案。

老师说，一定要在设计里灌注自己的思想，有了自己的思想你的设计才有灵魂，才能是好的设计。
工作后我发现，“如果一个设计只有设计者的思想，那么这个设计简直跟大便一样”。大便之后你会感觉到爽，别人却会被臭到；只有设计者自我思想的设计，设计者爽了，别人会很别扭、难受。这个别人包括老板、同事，特别是用户。…

在设计公司的时候，老板说，设计一定要好看，一定要让客户喜欢，客户不喜欢你的设计等于零。赚不到钱的设计不是好设计。
后来我发现，凡是客户满意的设计最后到了市场上，通常都是被用户臭骂的。因为那些挺着啤酒肚的客户，品味总是低于他的用户。

在证券公司的时候，老大说，设计一定要合理，严谨，不能出半点差错，功能要强，页面上需要的操作都得合理的出现。
后来，我们的产品使用者，如果不经过一周的培训，根本不会用我们的稽核监控系统。因为这个系统很强大，很完善。

当我们发现功能越来越多，产品架构越来越复杂。页面内容区越来越小，辅助导航区越来越大，所有人都没有办法了。老大不舍得精简，也不能精简，因为那些东西“多少都有用”。我们更不敢做精简，因为老大说了算，我们不能乱想。
后 来，老外顾问告诉我们：“少，就是多”。设计不需要你把所有的功能都摆在他面前，而是先满足他们的基本，挖掘深入需求，“当然想要时，找一下，能找到”， 这就足够了。比如，网站首页的帮助信息区域，哪怕放在页面最底，只要用户需要他一样可以找到；就算你放在首屏正中间，用户不需要一样看不到。

我恍然大悟，“原来好设计就是把不重要的都隐藏起来，需要的时候能找到就行”。于是，我开始在做设计的时候，尝试依据“用户的使用轨迹”来设计。那个时候我们还根本不知道什么叫“角色”、更不知道什么“场景设计”。
这个“进步”让我成了“高级设计师”，因为老大发现我的设计总是比别人更直接明了，不繁复。而且，我还总是能站在“用户使用”的角度，向他提出关于产品规划上的思路建议，很多被采纳。

自己带团队做项目后，我发现“把不重要的都隐藏起来”这招，根本不灵。我遇到了几个重大的问题：
1、需求分析的越细致，越耽误时间。 而且后面需求的变更或者整合，总是会牵扯到大局。
2、我的时间、人力根本不够完成那些详细的近乎完美的强大功能需求。

慢慢的我总结到：“少，就是多”，不只是要“表现”的少。
那些我站在“用户使用”角度，挖掘出来的很得意的需求，其实根本不值得做。“在条件有限的情况下，设计就是如何更好的满足大部分人的大部分需求”。
同时，随着web2.0的出现，产品的迭代越来越快，“把多余的都去掉”这种思想在互联网领域越来越受追捧。

随着以“简洁”、“Ajax”两个词为基本特征的“2.0式设计”出现以后，又出现了一个变态的现象：我们在不停的追求“这个细节能不能在交互上更人性化一点”、“这个跳转窗口能不能去掉，用弹出层如何”，… 我们很多所谓的“交互设计师”偏离了人机交互的本质，被同伴称之为“搞点花样的家伙”，甚至经常因为花样太多而被排挤。因为，花样总是要耽误时间的。

如是，终于在某一天，拿着一堆“很眩交互效果”去展示被否定后，我总结出了今天我对“好设计”的观点：
好设计首先要明白“解决什么问题”，然后分析“用什么解决”，然后设计“具体怎么解决”，最后在条件允许的情况下思考“这个解决办法是不是可以更好”。

总之，好设计就是用最低的交互成本帮助用户解决问题，并获取商业利益。和什么交互方式无关，和是否眩目更无关。

.

.

PS： 《Design IT.》接下来的两篇是，“Design IT. (3)，看不懂数据”、“Design IT. (4)，团队和决策 ”。
(《Design IT.》系列关闭评论，请在你自己的博客用“文章”回复，或者将你的文章发布到UCD大社区里。咱们可以把这些文章都聚合成话题)

分类：Design IT., UCD | 1 条评论 »

从大的发展来看，
网站就是一块试验田，一块在错误中成长、在错误中变强变大的试验田。这决定了互联网产品的成长路线，一定是一个反复修正和迭代的曲线。
很多，多年前的产计，当时未能取得成功，有的还一败涂地。拿到今天，稍加包装就成了最热门最合适的设计。究其原因，我认为大多数都属于“时机问题”，当初那些产品设计，面临的很多环境并不成熟。究其错误，我认为大多数都属于过于“激进”，在互联网这个世界，如果你要从一开始就做彻彻底底的去创新，基本没有成功的可能。
回顾互联网历史，我们不难发现，几乎所有成功的产品都是一个不断在演变的产品。包括yahoo、google、myspace、facebook、taobao、QQ等等，乃至MS。

回到产品设计本身，
早期“阶段性”的流程方式给我们产品开发和设计，带来了无尽的“返工”和低质量设计。往往前一个“阶段”的细节失误，就能导致后一个阶段的彻底垮工。
特别是我们从目录网站走到内容网站，又走到了今天的社区，网站本身的跌代性和反复修改变得越来越快。“阶段性”的流程方式无法“多团队同时协作”，导致的低效率，越来越凸显。

于是我们开始针对“产品更新快”、“迭代频繁”、“多团队协作”，等特性需求而改进的一些产品设计流程。这样的流程从大体上可以分成三个要点：按阶段发展相互依赖 + 表现层和底层相对分离 + 循环渐进反复迭代。

可以尝试用这样的一张草图来表现这种“流程”：

1、产品团队是核心。
产品团队发起项目，做前期的整体调研和评估，确定产品的定位、方向，以及大的产品概念设计。
在这个基础上将所面向的用户群进行大致划分，对不同用户群体的需求进行概要分析和总结。
最后产出：产品的整体框架，重要需求点的业务逻辑。

2、表现层和底层相对分离。
对于研发来说，产品的产出物都是数据。产品架构就是他的底层数据结构，业务逻辑就是他的数据逻辑。（研发我只懂皮毛，具体内容不一定完全正确）
对于设计来说，之前对于用户群的划分、对于需求的分析将演变成未来网站的内容设计；产品架构将演变成网站的信息架构（栏目、布局、导航等），业务逻辑是未来交互设计的依据。
最后，研发的前端的接口和设计的前端开发相结合。

3、这样做最大的好处在于：
业务发展到一定时候，当底层需要升级或者改进，表现层可以不用变化；
如果表现层的设计需要“改版”，底层可以不用变化；
只有当产品方向有变，或者业务逻辑发生变化，才会牵扯到底层和表现层同时变化。

4、按阶段发展相互依赖。
单看产品+研发，或单看产品+设计，每一个从上至下的过程都必须具备先后的阶段性，上一个的过程决定了下一个过程的大致范围，下一个过程影响并补充了上一个过程的详细内容。
比如，没有大的产品框架就没有具体的信息架构，在具体的信息架构设计过程中，又会修正并补充整体的产品框架。
再比如，没有需求分析，就不能有具体的内容设计，在具体的内容设计过程中，又会细化需求并有可能合并或者拆分已经修改需求。

5、循环渐进反复迭代。
这一点和第四点有很大的关系，理解这一点可以先看一下Jesse James Garrett 在《THE ELEMENTSOF USER EXPERIENCE》一书中（这是一本每个产品设计者都应该阅读的入门好书，中文叫《用户体验的要素》，由Angela翻译，因为我很讨厌这个书名里莫名其妙多了一个“的”字，所以以后我只会引用英文书名。），关于“迭代”的解释：

JJG在把体验分成了战略、范围、结构、框架、表现五个层面。我认为这五个层在细化的过程中，已不很适合如今的互联网产品设计，而且内容过于粗略，属于概念性质的东西，很难应用到操作层面。但，他在这里讲述这五个层在具体应用中的迭代关系，可以应用现在的设计中。

Angela是这样翻译的：“你应该计划好你的项目，让任何一个层面中的工作都不能在其下层面的工作完成之前结束。… 在我们知道基本形状之前，不能为房屋加上屋顶。… 要求每个层面的工作在下一个层面可以开始之前完成，会导致你和你的用户都不满意的结果。… 一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成”。

拿到这里会有一点小变动，应该这么说：不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作。（这也是为了我在前面给“完整”“整体”“大致”等关键词加粗的原因）
比如，不要把需求整理的非常详细以后再去内容设计，只要在内容设计该结束的时候完成需求整理；不要在开始信息架构设计的时候完全确定内容设计，只要在信息架构该确定的时候完成内容设计。也就是说“需求整理在信息架构开始的时候完成即可”。

（当然，这种做法一个更大的问题会出现：文档维护比以往阶段性的方式更繁复。 这一点，后面会详细谈到。 ）

不可分割的“用户调研”
细心的人可能已经看出，上面的设计并没有加入“用户”的内容。没错，上面的图只是在说“设计”，并没有提到用户调研。
用户调研应该贯穿于设计的任何一个环节，在整个设计过程中既起到“引导”的作用，又起到“校验”的功效。加入了对用户的研究以后，整个“迭代的设计过程”才会变得完整和丰满。

事实上这边文章应该属于“迭代设计”的一半内容，在以往的培训中我会加入用户调研部分进去（比如，这张图白板左边是上面的内容，右边就是用户调研加入进去之后的“产品设计”过程。右边的一半内容都是用户调研）。这篇文章就不细说了，《Design IT.》 系列正式完成的时候再补充进去。

.

.

PS:
《Design IT.》将是一个很长期，很完整的系列。从设计方法，到产品市场、到具体的设计，到最后的测试和产品类的线上运营。
欢迎有兴趣的朋友对每篇文章进行指正和补充。（为了保证更高质量的评论，我将关闭这个系列文章的评论。请在你自己的博客用“文章”回复，或者将你的文章发布到UCD大社区里。咱们可以把这些文章都聚合成话题）

分类：Design IT., UCD | 3 条评论 »