好几次书友会，我们讨论着讨论着就说到了设计的“终极目标”：用户想要什么，就给他什么。这里的想要什么，应该更多的是指期望。需求和期望的联系和区别，Angela 的设计的价值里解释的比较清楚，我想补充的是：期望，是需求的多种实体。
其实，我很少“关注”需求和期望，在设计过程中，我比较关注的是很直接的两点：a) 用户有什么问题？ b) 我们怎么去解决？（一般在前面会加上谁是用户，不过跟本文不太相关，就略了）。前者主要是结合问题去发现动机（为什么会这样，有时候也能理解为需求），而后者主要就是用一些设计方法去摆平。问题、动机、解决方法，形成了一个三角。这三者相互制约着，三者都有可能分析错误，但三者同时错误的几率不高。当这三者都能说通的时候，一切就顺理成章了。
自认为算Flickr的资深用户，从2004年8月偶然在搜索引擎中发现开始，到2006年4月成为Pro。继续一年的疯狂体验后，在2007年3月续费。不幸的是，2007年6月某天，Flickr网站上的所有照片被GFW屏蔽。更不幸的是，我的3月充值提重了订单，把预期游戏结束时间给推到了2011年。
身为设计师的角度，我承认消费美金的目地不单纯，除了充分享受平台带来的愉悦，还特别想深入系统，搞清楚设计的初衷。注意，刚才报了一连串数字，以辅助说明下文的用户期望。
我们要做的这个东西，“商业上是否能得到回报？”、“技术上是否能实现？”
能解决以上两个问题，一个产品基本上就具备了可实施的条件。事实上，大多数的产品都是在回答了以上两个疑问之后付诸实施的，也许有的一开始只考虑技术是否能实现，但接下来很快就会想商业上如何得到回报。反之亦然。
但是渐渐的有人发现，仅仅解决“商业”和“技术”问题，并不能让用户买账。用户选择使用哪个产品，似乎过于随意、主观、毫无规律可循，这是一个让人摸不着头脑的现象。
有一个模型似乎很合理地解释了现象背后的原因，这就是现代产品开发设计的三要素。
这个由Doblin Group公司的Keeley提出的“技术可能性、商业可行性、设计期望性”的三品质模型，第一次把“设计”有意识地引入到影响产品成功的因素之中。Larry Keeley认为，一个高技术的商业产品，这三个因素同时对其产生影响，如果三个基础中的某项显著的弱于其他，那这个产品不太可能禁得住时间的考验。 (more…)
用户的期望值产生于需求，而非体验。
先是期望值产生的时间，应该是在意识到自己需求的时候，（注意并非是产生需求的时候）。这个时候，最基本的期望值便已经确定了，例如感觉到了自己口渴，这时候同时产生了需要解渴的饮品的期望。这个期望的产生，完全和先前的体验没有关系。
至于说其他的期望，很多时候也并非是产生于先前的体验，而是需求的分解，当意识到自己需求的同时，意识到自己这个需求同时还是伴随别的需求的，例如运动的时候想喝水的时候同时意识到自己有点累需要解决累的问题，可能就增加了期望，补充点糖分。
ami在文中提及了，我们经常期望在**软件中存在**功能，当然，先前的体验在我们这个期望的产生中是存在作用的，但是先前的体验并非是决定我们对该功能有期望的原因，而是辅助的作用，它只是帮助我们去快速的分解自己的需求，当我们意识到主体需求的同时，先前的体验可以帮助我们快速的将主体的需求分解成被分解的需求，如果思考够理智的话，可能很多功能是很好，但是不在我们的分解需求之中，这个也不会产生什么期望值。
在一个人没有意识到自己的需求的时候，任何体验都是对期望没有影响的。
(more…)
用户来到我们的网站，与我们的产品进行交互时，必定带着他的期望。是否能满足用户的期望，直接关系到是否能带给用户积极的体验。
那么，用户期望是怎样产生的呢？
品牌信誉
首先，用户期望可能基于你的品牌信誉，尤其是对你这个产品还没有初步体验和接触的时候。品牌信誉是从多方面累积建立起来的，产品本身的质量、口碑、公关和宣传……当你建立起一种品牌形象，用户自然会对你的产品产生相应的期望，比如IBM的本本应该有可靠的质量、NOKIA的手机很耐摔……在这次上海的书友会上Sky还举例，如果Google和微软同时推出一款互联网产品，我们很容易对Google有更高的期望——微软相对来说没那么擅长互联网产品，而Google，会让人期待又一个Gmail或者Gtalk、Google Reader…
当你的产品能满足用户期望，提供良好的体验时，也会进一步的促进和提升你的品牌信誉，更增加用户的忠诚度。 (more…)
对规范更深层次认识来自于YUI的启发，这个几乎已经是控件代名词的英文缩写，可能很少有人注意全称The Yahoo! User Interface Library，其实就是整套带有开发模式的界面规范，因此我也喜欢把整理好的各种规范叫做XXX Design Library。
产品规范的应用对象，分为设计师、工程师两类人。对设计师来说主要是“协调”工作，使交付物统一；对工程师来说主要是“配合”工作，使开发效率提高。
我倾向于在概念设计的低保原型之后，也就是说得先有第一批可开发的页面。我反复强调的原因，概念上不管做产品还是平台，核心都是由一个个页面组成的网站，有效规范只针对于最终产出。
很多朋友提到边设计边整理规范，这是对设计工作的总结。我的看法，产品设计与开发是整套系统工程，所以更进一步，应该边开发边整理规范，让规范与开发同步，互相契合更新。也就是说，每次迭代之后，都应该升级规范。
对工程师而言，上手来一份事无巨细的规范，读完要花两天，熟练要花十天，在庖丁解牛的开发过程中，简直就是噩梦。于是还没等走完这个过程，早因想痛打设计师而消极怠工了。这也正是不建议使用现成规范的原因，第一国情不同，第二时机不对。
注：如无特别指明，以下规范可能只适用于设计。
规范一定是文字吗？当然不一定…尤其对于图形设计规范来说。规范可以是以下任何一种形式：
* Word文档
* psd或jpg图片档
* ppt演示文稿
* VISIO框图
* 等等
规范的内容简而言之是这样：嘿，以后照这样来做。然后给“这样”举个例子。
从业这几年，自己写过的和帮人参谋的所谓“设计规范”不少了，这个东西大概在中国的决策层眼里是这么回事儿 - 一帮农民在一块田里种粮食，起先天气不错，土地肥沃，但是不久天气变差了，虫子多了，土地沙化严重，还有几个缺心眼的内鬼偷粮食，这下必须立定一个规范，挑头的告诉他们该在哪儿种，收多少麦子算合格，哪部分的地是留到下一季种的，种出什么样的麦子给奖金，偷懒不干活的怎么处理……
但我理解的规范不是简单的把一个设计做成一个“行业套路”的量化指标，而是一个综合的品质评估的参考，甚至是一个设计能否面市的决定因素。为此，我们需要拟定一些表格，文档备案，图形参考，交互模板。
同时，设计规范还要成为设计部门或者一个公司对于设计品质的共同价值观，让大家伙都知道这样做出来的是好设计，通过这样的规范教育和交流，形成对设计品质的统一认识。设计规范不是规定要做什么，而是提出这样做是正确的，但是有更好的地方可以改进。
(more…)