1、一张图很直观的表明我们需要挖掘用户真正的需求
“用户角色”在可用性设计里,是一个很重要的概念,之前很多关于用户的讨论,比如:“不要听用户的”“要不要听用户的”“以用户为中心是有害的”“要关注用户,学会倾听用户”等等,或许都从各自的角度来证明了自己的想法。今天在西贝那里看到这样一张图:
从上面这张图我们可以看出:不光开发团队的不同工种的理解差别很大,而且用户的期望和用户的真正需要也不尽相同。
2、在设计时候适当运用角色,正好可以弥补设计与用户真正地需求之间的差距。
下面我们先解读一下上图,按照从左之右,从上至下:
用户的描述
根据用户描述的理解
分析师的设计
程序员编写
高级顾问的描述
项目策划书
操作用使用的工具
用户自己建造的结果
提供基础支持的程度
用户真正的需求
a. 我们先比较1、8和10会发现,不但用户真正的需求和用户的描述是有差别的,而且让用户自己去设计更是不且实际,用户不是设计师,并没有专业性的用软件去表达自己的能力。鉴于用户的局限性和非专业性的问题,我们不能完全听用户的,更不能让用户去做设计。
b. 从2、3、4、5、6、7、9可以看出,最基本的方向和起点大家都是一致的,但理解确实差别很大,理解的层面和深度各异。此时我们需要有一种方法客观的统一意识,朝用户真正的方向努力,用户角色是个很好的辅助方法。程序实施是实现了基本的功能,根本满足不了需求;用户顾问把用户的需求夸大或者变的过于“高雅”;产品经理和分析设计师都只是接近用户的真实需求。我们这些认识和想法,只有通过用户验证和反馈,来不断的客观修正,才能真正的达到用户真实需求。
3、至于具体做法,是一门学问,借此推荐两本书,通过系统的学习和大量的时间才能真正的掌握这门技能。
“用户角色”在可用性设计里,是一个很重要的概念,之前很多关于用户的讨论,比如:“不要听用户的”“要不要听用户的”“以用户为中心是有害的”“要关注用户,学会倾听用户”等等,或许都从各自的角度来证明了自己的想法。今天在西贝那里看到这样一张图:
![](http://hi.csdn.net/attachment/201112/15/0_13239396580F99.gif)
从上面这张图我们可以看出:不光开发团队的不同工种的理解差别很大,而且用户的期望和用户的真正需要也不尽相同。
2、在设计时候适当运用角色,正好可以弥补设计与用户真正地需求之间的差距。
下面我们先解读一下上图,按照从左之右,从上至下:
用户的描述
根据用户描述的理解
分析师的设计
程序员编写
高级顾问的描述
项目策划书
操作用使用的工具
用户自己建造的结果
提供基础支持的程度
用户真正的需求
a. 我们先比较1、8和10会发现,不但用户真正的需求和用户的描述是有差别的,而且让用户自己去设计更是不且实际,用户不是设计师,并没有专业性的用软件去表达自己的能力。鉴于用户的局限性和非专业性的问题,我们不能完全听用户的,更不能让用户去做设计。
b. 从2、3、4、5、6、7、9可以看出,最基本的方向和起点大家都是一致的,但理解确实差别很大,理解的层面和深度各异。此时我们需要有一种方法客观的统一意识,朝用户真正的方向努力,用户角色是个很好的辅助方法。程序实施是实现了基本的功能,根本满足不了需求;用户顾问把用户的需求夸大或者变的过于“高雅”;产品经理和分析设计师都只是接近用户的真实需求。我们这些认识和想法,只有通过用户验证和反馈,来不断的客观修正,才能真正的达到用户真实需求。
3、至于具体做法,是一门学问,借此推荐两本书,通过系统的学习和大量的时间才能真正的掌握这门技能。