互联网产品设计操作指南

举报 2008-11-11

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


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

1. 行业,在何种业务内做事?
2. 指导理念,在哪些原则下做事?
3. 工作方式和流程,一个人怎么做事?

4. 团队协作,一群人怎么做事?


组织理念并分层

思想信仰——以用户为中心的设计

实现目标——良好用户体验

具体指标——可访问性、兼容性、可用性、标准化、搜索引擎友好

接受来自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,有人可以带领大家做的更好,没人自己也能抗下来。

© 一叶千鸟(转载请留原文链接)

本文系作者授权数英发表,内容为作者独立观点,不代表数英立场。
转载请在文章开头和结尾显眼处标注:作者、出处和链接。不按规范转载侵权必究。
本文系作者授权数英发表,内容为作者独立观点,不代表数英立场。
未经授权严禁转载,授权事宜请联系作者本人,侵权必究。
本内容为作者独立观点,不代表数英立场。
本文禁止转载,侵权必究。
本文系数英原创,未经允许不得转载。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权,侵权必究。

    评论

    文明发言,无意义评论将很快被删除,异常行为可能被禁言
    DIGITALING
    登录后参与评论

    评论

    文明发言,无意义评论将很快被删除,异常行为可能被禁言
    800

    推荐评论

    暂无评论哦,快来评论一下吧!

    全部评论(0条)