说到Web2.0, 很少有人能给出一个关于它的准确定义, 大多数只是通过对比Flickr, Youtube等对它的特点进行描述. 这次开放日, IBM通过一个demo展示了网络协作群件Lotus旗下的几乎全部子产品, 向与会者诠释了Web2.0架构在应用领域的另一个方向.

下载演示文档(不含demo), 打开此文件您还需要下载安装Lotus Symphony.

随意想象一下, 假如百度采用这种界面, 估计其竞价排名业务更生财有道了;-)

书名: 一目了然 — Web软件显性设计之路
原书名: Designing the Obvious: A Common Sense Approach to Web Application Design
作者: Robert Hoekman
译者: 何潇
出版社: 机械工业出版社
出版日期: 2007年11月
定价: 39元

作者介绍
Robert Hoekman, Jr.是一名交互设计师和易用性专家, 他曾任职于GoDaddy.com、MacroMedia、Adobe、联合航空、思科等众多公司, 为广大受众提供优质的用户体验服务。更多信息请访问: www.rhjr.net

目录
第1章 显性设计的定义
什么是显性设计
如何做到显性设计
显性设计框架

第2章 理解用户, 然后忽略他们
理解用户对所做事情的思考
理解用户真正如何做事
知道如何揭开真相
为活动而设计
撰写用例

第3章 够用就好
独辟蹊径
去掉一般性功能

第4章 支持用户的心智模型
为心智模型而设计
消除实现模型
原型设计
公开测试

第5章 让菜鸟即刻上路
快速上路
选择合适的默认值
信息设计
提供帮助

第6章 巧妙应对出错
利用Poka-yoke处理错误
摒弃模式化
撰写有用的出错提示
设计宽容的软件

第7章 一致性设计
设计的一致性
将一致性贯穿软件始终
平衡无规则性

第8章 精简与优化
消除混乱
实践Kaizen
杜绝浪费
将复查进行到底

第9章 改良比创新重要
提升用户体验
向好的样例看齐
提升标准
分清主次
遵循游戏规则

封面

PS: 已经有朋友抱怨本书的翻译质量, 我也很忐忑. 客观说整个翻译过程比较匆忙, 校核时间不足(特别是后几章). 这是我第一次尝试翻译一本著作(极有可能也是最后一次), 水平有限, 诚恳期待大家批评指正.

From: MySpace User Stack
To: me

You have not logged into MySpace since January 1, 2007. That makes us sad!
你丫好久没上我们网站了, 我们挺不爽.

You're also holding a very valuable piece of MySpace real estate, which is the username/URL you chose. That makes MySpace users sad!     Why? Because you've got a URL someone may want, and you're not really using it!
你丫还占用了一个很有价值的用户名和URL, 我们就更不爽了. 现在有人要了.

Since it doesn't look like you're an active user on this account, we will be resetting your username/URL so that someone else can use it.
既然你丫不是活跃用户, 我们就要删了你的用户名和URL.

To prevent this from happening, simply login to MySpace before Oct 31, 2007.
要是你丫不想被删的话, 必须在10月31日前登录一次.

... ...

棕色文字是我理解的意思. 附带说一句, 整封信没有开头和称呼, 末尾倒是有一堆法律申明. 也许中国领先的web2.0网站MySpace了解到我是名喜欢开门见山的用户.

网上现在有不少关于流程的文章或讨论, 在一些行业聚会上也常常提到这个问题. 现在最流行的一个词叫"以用户为中心的设计" (UCD, User-Centered Design), 客观讲UCD不仅是一套方法, 更是大势所趋, 不管是所谓的蓝海还是红海, 最终产品要想获得成功, 都必须UCD. 从这个角度来讲, 最重要的是产品开发人员必须先要有以用户为本的理念, 其次再讲方法.

董建明博士、傅利民博士和Salvendy教授曾经联合写过一本书, 叫《人机交互: 以用户为中心的设计和评估》, 其中详细介绍了一套UCD的开发流程, 将整体流程大致划分为三个阶段: 策略和用户分析 > 设计和评估 > 实施和评估. 不过个人感觉这套流程有些理论化和繁琐, 对一些以研究为目的的团队或项目比较适用(项目周期较长), 但未必适用于一些要求快速开发的项目. 但从这套流程看出, 评估和迭代是非常重要的!

IBM也有一套很完善的UCD方法说明, 并公布在网上, 充分发扬了IBM做事规矩、事无巨细的特征, 也可以作为参考.

在我看来, 对很多快速而轻量级的项目(注意!)而言, 有UE参与的开发流程无外乎四个阶段: 需求定义 > 快速原型(Prototype) > 交互式模型(Mockup) > 开发与上线. 在这套流程中, 一些易用性研究和用户研究方法(如问卷、焦点小组、认知走查等)都会包含在整个流程中, 比如在需求定义阶段可以展开焦点小组、头脑风暴、竞品分析等, 在快速原型(一般为低保真)阶段可以展开认知走查、Persona等, Mockup阶段可以主导专家评估或用户测试... 这种流程的特点是每一个阶段都会直接作用于最终的产品上线, 而且最大限度地保证前端界面设计的质量, 同时Mockup阶段更是清除掉其中的hard code后, 就可直接复用到产品的前端开发之中, 因此较为省时.

举例: A项目组近期需要为某小区开发一套web地图, 周期为4个月.

需求定义: 思考并解决 现有哪些类似的产品或服务?(竟品) 该小区的哪些人会成为我们的用户?(问卷或访谈) 他们想通过地图得到什么?(焦点小组) 该项目的预算和策略是什么?(参考) 这套地图和我们的其他产品如何融合?(参考) 最终输出一份报告或说明, 耗时10个工作日(周末要加班).

快速原型: 根据上述报告设计一份纸质原型(或再配合讲一个故事, Storyboarding), 画出流程图和概念图(很重要!), 找若干用户(6-8个)做一次走查, 找出其中的问题并修正. 另外评估该原型是否符合我们的典型用户! 耗时8个工作日(周末还要加班).

交互式模型: 设计师设计界面, 工程师做前端开发, 部分交互效果可通过js模拟出来(hard coding), 以方便展开专家评估和用户测试. 需要指出的是这个阶段RD同事已经可以通过前面的成果以use case/UML等方式来设计系统架构了, 并行开发两不误. 耗时8个工作日(周末继续加班).

开发与上线: 这个阶段的重担落在了RD手中, 不过UE也不会闲着, 一方面开发过程中工程师还会不停地就一些细节问题来骚扰你, 另一方面我们要撰写相关的规范文档如UI设计规范、交互设计规范(如果时间充裕的话它们应该在开发之前就完成)以及协助业务部门设计帮助信息等. 此外在后期还有QA、用户测试、上线后数据跟踪与反馈等, 估计还会要加班.

话说回来, 流程更多是能保证项目的顺利执行(尤其对大型团队而言), 产品的成功应该取决于策略、市场、运营(很重要!)、设计等各个方面.

欢迎讨论.

2008年度的淘宝UED团队为了招聘还在Blueidea上登广告, 网站做的也算精美, 虽然问题有些弱智, 但足以体现人家的重视.

地址: http://ued.taobao.com/job

看好淘宝!

开场白

老丁近照

人文奥运

Work show hall

Design work

确实如葛爷所说，境界是分层次的，当然能达到佛这样境界的自然只有佛他老人家。

由此类比我们的产品升级，常听到有设计师朋友(包括自己)的抱怨：“公司现有的产品界面简直就是TMD破烂，那帮PM居然还浑然不知，整天被别的事忙的屁颠屁颠的...”从同行的眼光看，咱们很赞同这句话，说的也是事实，谁让设计师大多干的是“乙方”的活儿呢?!

不过咱也可以借此机会分析分析产品升级的“境界”问题，看看“界面升级”这件事儿能排到哪一级。

先掰着指头数数每次产品升级会涉及哪些关键部门(学过CF决策管理的朋友可能对这招有点熟)：产品管理(PM)、运营(Operations)、市场(Marketing)、销售(Sales)、客服(Customer Service)、设计(Design)、开发与测试(RD & QA)，以及法务、审计等支持性部门。依次总结一下各个部门关心什么：

·PM：产品战略布局与发展方向、功能设置等
·Operation：产品内容、用户需求、成本等
·Marketing：市场份额、品牌与口碑、营销手段等
·Sales：价格策略、产品认可度等
·CS：用户满意度、用户需求等
·Design：产品专业性、易用性等
·RD-QA：系统稳定性、产品质量等

当然啦，不是所有公司都有上面这么多条条框框的部门，大多数创业型公司扯上点RD就能上路了(程序员就是大爷)，再者部门之间的关注点常常也会有重合的地方。

梳理一下这些关注点，归纳起来影响产品升级的因素包括：

·产品战略布局：扩展性、产品在公司内与行业内的生态价值等
·产品功能
·成本：人力投入成本、开发成本、时间成本等
·用户需求
·用户满意度
·品牌与口碑
·系统稳定性
·开发质量
·界面专业性与易用性

回头咱再加工一下这些因素，结合一下PM和设计师的眼光做个排序吧，不过注意设计师同样应该全面关注所有层次：

·战略层：产品战略布局、生态构架等
·实现层：产品功能、实现成本、用户具体需求、系统稳定性、开发质量等
·表现层：品牌与口碑、产品界面流程与易用性等

由此可见，每一次产品升级都会牵涉到不同的角度与目的，而不仅仅是从视觉设计的角度做做“换肤”工作，或者局限于这个按钮应该摆哪里，那个地方是否应该用Tab ... 如果每一次的系统改进我们都能从这三个层次进行梳理，也许你就能发现自己当前的角色最应该考虑哪些啦。

举个例子，在普通用户看来，微软的Windows XP到Vista的最大升级莫过于界面，很多设计师也对此欣喜不已，认为Vista、Office2007等产品是微软有史以来最重视用户体验(最贴近苹果水平)的一次。但我们更应该看到的是，隐藏在这些产品背后的战略层思考：互联网时代的软件必须更贴近互联网。比如Widget，比如线上线下同步，比如随处可见的Web内容嵌入，尽管这还只是开始... ...

我比较奇怪的是往往一涉及到Web端的层级文档管理时，很多人(比如PM和开发工程师)头脑中的第一反应就是采用树型视图。哪里最先使用到树型视图我无从考证，不过猜想人们大概都是从微软OS的资源管理器设计中获得的启发。

本文要表达的观点是：树型视图是一种很好的呈现层级关系的方式，但现有的树型视图模式是可以优化的。

首先让我们来回顾一下经典的树型视图吧：一个小小的图标(可能是加减号或箭头)，紧跟着一个文件夹。单击图标或双击文件夹，则展开或收缩子文件夹；单击文件夹，则会在右侧出现该文件夹所包含的子文件。

请注意上述描述，界面设计中有两个重要的易用性原则：关联性和一致性。对比看一下，图标和文件夹是两个关联的界面要素，因此无论视觉、行为还是界面反馈，两者都理应保持一致。但现实情况则是：单击图标和双击文件夹所获得的反馈是一致的，而更诡异的是单击文件夹居然得到另一种反馈——这里我们还不计较那么小的图标有多少眼神好的用户能分辨的清。

现在你应该就能明白我所说的可改进的地方在哪里了吧? 也知道该怎么优化了对吧? 不过别急，让我们回到最开始，为什么要用树型结构? 前面已经说了树型结构的优势就是呈现信息的层级关系，那紧接着，为什么一定要使垂直结构呢? 仅仅就因为空间有限吗?

揭开一个谜底吧，大家可以留意一下苹果的“树型”视图(其实并没有“树”，严格说应该叫层叠列表，Cascade-style list)，看看苹果是如何处理这个问题的。

细心的你可以发现，在苹果的设计里，关联性和一致性都处理得非常好!

PS两条：
(1) 微软对树型视图的设计有着详细的说明，详细信息可参考MSDN；
(2) 对照苹果的设计，观察一下Web上已有的成例eBay和淘宝吧，在它们的用户卖商品时选择商品类型页面中都出现过这类设计，看看哪家的设计更有细节，更易用;-)

说来惭愧，虽然是工业设计科班出身，这么多年的学生生涯却对产品设计极少积累，只好从一次次的展览赏析中弥补了...

参观完后居然忘了拍过大量照片，昨天才无意中翻出来。

Giro 削皮刀, 红点奖

Kenwood EON烤面包机, 红点奖

Kenwood EON咖啡机, iF奖

Taylor's Eye Witness, iF金奖

Cork冰桶, 红点奖+iF奖

LOMO一张, 猜猜我拍到了什么?!

说起名字，立马能让我想起在IBM呆过的一个部门的全称，也是相当长，叫做"Enterprise Content Management Solutions & Content Management Rapid Industrial Solutions Engineering Development"，缩写是"ECM Solutions & CM RISE Dev."，听上去蛮好玩的吧? 看上去似乎这两家大公司在取名字方面可真是有一套啊，让人光听着就晕晕的(Microsoft在这个方面一直为人诟病，尤其是在Live推出后)。

好的名字往往会让人难忘，有如金大侠笔下的神仙姐姐"王语嫣"，纵然未见其人，光这三个字的名字也足够让人能感受到那份楚楚动人。

随手也罗列了一些很赞的产品/品牌的名字，比如：
• Del.icio.us
• 饭桶
• 抓虾
• 豆瓣
• 臭豆

• 佳能
• 强生
• 奔驰
• 宝马
• 苹果
• 梦工厂
• 运通

另外一直很赞百度空间的域名(Hi)!

还有一些觉得很蹩脚的名字：
• 客齐集 (弱弱地提醒王建硕同学平仄有些问题)
• 谷歌 (一直没太明白官方宣传片中"以谷为歌"是啥子意思?!)
• 奇虎 (迷糊中)
• Lava-Lava (哇啦哇啦@&*@$)

大家一起来补充好的/差的名字吧 ;-)

知识产权出版社4月份刚刚推出的一本书: 《创新的10个面孔》, 由全球最负盛名的设计公司之一IDEO总裁Tom Kelley亲自操刀, 非常值得推荐! Tom Kelley之前还写过一本《创新的艺术》(The art of innovation).

书中作者列出了创新设计的10类角色, 并配以大量新鲜案例:
· 人类学家
· 实验家
· 嫁接能手
· 跨栏运动员
· 协调员
· 导演
· 用户体验设计师
· 布景师
· 照料者
· 故事家