求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
浅谈用户体验的那些事情
 

作者:西米,发布于2011-11-28

 

某日,一同事埋怨,我们是做用户体验工作的,辛辛苦苦的做功能需求分析、用户信息调研、做加法减法、业务流程优化,产出原型稿后,却经常遭到用户的挑战,死心塌地为他们做最好的产品,最人性化的系统,却做的两边不讨好。对于这个问题不仅仅是我那位同事的苦恼,也是我一直所迷惘的方面。今天就简单的聊聊用户体验这个部门的存在,是不是一个摆设,如何实现它的价值。

首先我要提出的观点是,做UE的人员有两方面矛盾冲突点,一个是来自内部的压力,对于做技术开发的同事来说,他们当然希望我们提出的交互性的需求越来越少,曾经在会上,一研发经理看着我们做的交互原型,不停地摇头说这个功能不能做,那个功能成本太高,时间不允许,经过分析得知,研发做前端的人一般提出了几种技术解决方案,属于不同公司和框架集,固定的控件,可扩展性差,所以他们被逼无奈只要在UE部门装载了N个技术方案,让我们去选择,有合适的就用,最好在一套技术方案来用。所以经常性我们提出的需求即使是很小的一个功能按钮要放在表格数据里面进行设置,对他们来说是很头疼的问题。对于我们来说,简直是有点异想天开。其次就是第二个压力点,对功能需求团队来说,他们前期只负责提出大概的功能文档和说明,经过我们初步框架设计出来之后发现很多衍生的需求需要他们去挖掘和完善,当然对于技术那边也是一个压力点。所以尽管现实情况是这样,我们还是坚持给用户最好的产品和易用性。可为什么我们面临需求团队、技术团队、目标客户、都是让人讨厌的的对象。

目前的系统是一个用了很多年的老系统,原有的技术团队早已不复存在,系统庞大复杂、涉及的业务模块错综复杂。可以肯定的说整个公司内部没有一个人能够对系统有全面的了解和清晰的分析,更别谈用户体验方面了。所以这导致了,计划永远赶不上变化,需求反反复复修改,需求做修改,那么接下来,原型框架、高保真原型、需求说明文档、用户调研方向和数据都需要重新来过。所以自我总结出以下值得深思的问题和要点

1,怎样快速理解业务本身是干什么,只有先理解需求部门才能衍生新的功能需求,但现实问题是即使养着我们一大帮人不做事全天学习业务和系统,保守估计最少得半年时间。

2,为什么需求总是在改,改完需求后,一动百动,最近我做页面原型已经头昏脑胀,上午提出的修改需求还没改完,下午又有需求要求改,无非就是业务逻辑关系没搞清楚,当前页面模块牵扯的数据范围和最终用户模块跳转整合的问题。所以需求那边是一边学习一边做,无可否认,UE团队、研发团队目前走的都是这个模式。

3,用户体验价值何在?曾几何时我一度迷惘,整天忙碌修修改改连思考的时间都来不及,这是很危险的事情,我们如果忙碌在这些工作当中,UE团队可以考虑不需要了。

4,我们提出的交互性的需求还是需要和技术部门需求部门继续商讨和想办法解决,当然不能什么需求都召集大家开会,具体模块对应具体模块负责人,自己去沟通协调,尽量在不增加其他部门的工作量情况下,提出合理性的需求,切忌不要天马行空。用户体验谁都会说,但要做很难,深入的去做更难。

5,一定要保持客观的判断思维,你不代表用户,但你做的工作是为用户提供更快捷更友好的系统,提高他们办公效率,所以最好不要说:“我觉得用户走到这里,应该会…..”或者”唉,没关系了,用户又不是笨蛋,怎么可能不知道这个功能按钮是干嘛的“。

6,我们提出的想法和创意对应整个系统来说,没有对和错,也没有多么幼稚或者很牛B,静下心来你会发现,一个月前我们提出的解决方案内部都认可,两个月前我们彼此有各种的想法,互不认同。所以唯有时间和最终受益用户来决定你的价值。

7,前期如果没有用户调研相关数据,大家可以异想天开,但一旦有客观的真凭实据,请尊重用户真正动机和行为,把精力放在关注他们所关注的业务工作上,你才能得到正确的想法,从而做正确的事情。

8,不要觉得老系统很多功能很变态,人家用了那么多年的业务系统,为什么会这样是有原因的,当你了解到原因之后才知道存在是合理。

9,用户习惯和你做的功能操作规范不是固定的,如果你一定要说TAB键是可以切换选择页面元素,单击是打开新连接,那么调查来的数据是,TAB键做切换是对的,但老用户更多用的是Enter来做切换,而且在填写数据后,还是用Enter来做提交。对于用惯了C/S系统的用户来说,双击永远是打开新的页面和操作。如果你非要说我做的B/S系统,单击就能打开,那多方便了,何必双击了。这个问题得出的结果,双击和单击都要做到同样的功能。

10,UE部门的价值在哪里,这里需要我们去分析,用户所用到的90%以上的功能模块和问题,抓住这个问题重点下功夫改善并学会推广。如果你在一个系统管理员用户管理模块花费三天,用的人不超过三个,你做的再好,和前者相比哪个价值更大。

11,最后要说的是,作为一个UE初学者,不是要求你文档写多么棒,原型做的多么漂亮,说的别谁都好,更重要的是要学会观察细节,学会思考,独立的分析能力。学会怎么去思考问题。然后帮助给我们饭吃的用户愉快的达到他的目的。。

下面谈谈UE团队的管理,个人认为做管理的本质是帮助团队更好的发挥潜力,服务于团队,创造更大的价值,所以你一边需要负责沟通各种问题,安排计划、解决高危项目模块,协调延期项目、主导工作目标和方向。这不需要你有多么强悍的技术,我见过一些UE经理,搞不清自己是什么专业出生,但对视觉设计、前端技术、原型设计、统统都要插一脚,可问题是,你插进来之后所提出的问题和解决办法完全让人无法接受,最终的结果是不停地返工。所谓”将帅无能,累死三军“所以起码要知道让这个团队的人都实现自己的价值,专业的人做专业的事。

 
相关文章

需求分析师的能力模型
基于模型的需求管理方法与工具
需求管理工具DOORS 的接口
使用Web+EA实现基于模型的需求管理
需求经过大脑的过程:需求分析评估方法
 
相关文档

需求分析与需求管理
需求分析具体要求全解
需求分析与验证
需求分析的核心线索
基于UML的需求分析方法
 
相关课程

需求分析与管理
从需求过渡到设计
业务建模与业务分析
产品需求分析与管理
需求分析最佳实践与沙盘演练
 
分享到
 
 

相关文章

需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   

相关培训课程
软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践

成功案例
北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...