《就这么简单》读后感

      感谢shuya同学提供的硬件,此书是一本讲用户体验和Web类产品可用性的入门书籍,内容比较全面,语言亲和,配图有趣,举例多为国内读者常用的网站,但价格比较贵。

      我很粗略的阅读了本书,如果以后有机会,我还想对有些篇章精读下,作为一个菜鸟,书中很多观点和建议我还是很受用的,特别是能够引发我在实际工作中的一些思考。

      用户体验和可用性设计并不是很玄的东西,书中九个章节谈到的内容-不管是“了解用户、了解需求”,还是“设计方案和制作原型”,或者“测试可用性”等等-我所在的团队在实际的产品开发中似乎都有涉及,但仔细琢磨下,没个方面都有不足,最终的结果是产品的用户体验和可用性上比较弱。

      以下是我读后的一些思考:

1. 原型的力量

本书中作者很推崇原型的作用,不管是初级原型还是高级原型。我自己的团队中的产品有原型吗?有。原型的作用有那么大吗?我觉得没有。有时我们的原型与实际的产品设计混淆了,我们把某个阶段或迭代的产品作为原型推送个用户,去做产品体验了,‘推倒重来’的悲剧偶有发生,付出的代价比改进或从新设计原型要大。为什么会这样呢?我觉得有2个主要原因:1.迭代中缺失了这个环节(这个环节是否必要我觉得要因项目和产品而定),我所在团队的产品人员所制作的初级模型我觉得很不错了,但就初级模型与用户的交互这一块我觉得可能还有待加强,这不仅仅是可以获取用户的反馈,更重要的是有助于解决开发人员关于产品设计的争议;2.我们作为开发人员或产品人员的模型制作能力不是很强。至少对我来说,有时觉得制作模型与实际开发的成本差不多,往往头脑中想的差不多了就动手编码了(难道Web开发很容易这样),最终的产品人员和用户的反馈我并没有多少把握,于是悲剧就在酝酿之中了。

2.Showcase离用户可用性测试有多远

主观和客观的条件决定我所在的团队无法实现较严格的产品可用性测试。我觉得我们比较接近可用性测试的研发环节就是用户Showcase。Showcase时先有一番发布特性的知会和教育,其后用户会进行反馈和交流,偶尔会演示其在实际操作中遇到的问题;最终的效果我臆测估计不会太好-从获取一些改进意见的角度来看。如果要想Showcase能够承载更多的用户可用性测试的作用,我觉得至少要在showcase的人数规模(不用太多人,给用户一个宽松的环境和公平发表意见的机会)和次数(要坚持多轮次,逐步发现更多的可用性问题)上加以改进。本书中提到这样的观点:用户可用性测试,测试用户数不是关键,测试的轮数比较重要,我觉得挺有道理的。

3.用户真的参与了开发吗

这是个复杂的问题,以我现在的能力无法掌控其中的奥秘,但我肯定不能闭门造车,完全将用户和客户排除在开发过程之外。一直高举“以用户价值为依归”的伟大旗帜,但实际开发中对用户的一些需求还是有想法的,甚至有时有排斥和不理解的情况,借口通常是用户不熟悉技术实现的难度,现在我决定时常提醒下自己,如果真的到了用户需求与技术实现产生冲突时,应该下定决心满足用户,克服技术困难。

4.一些有用的Web开发常识

书中比较零散地散布着一些法则和常识,对我挺有启发,特别是结合实际工作时。略举几例:

 * 摩西的十戒:依赖识别而不是记忆;提倡一致性和标准化;给予用户控制权和自主权……;

 * 控件的左对齐与右对齐法则;

 * 标签只能用来导航,不能选择数据;

 * 时隐时现的菜单项体验并不好;

 * 国内的门户网站首页的信息量和闪动广告是一大的“奇葩”。

   一点感受,暂时写这么多吧,希望以后自己能多读些书。

关于“快捷方式”与“用户体验”的思考

首先转载一片看到的博客,感觉跟TAPD遇到的情况的有些类似,文中观点,大家可以思考和探讨下。

原文地址:http://www.a-xuan.cn/?tag=%E7%94%A8%E6%88%B7%E4%BD%93%E9%AA%8C

————————–   START ——————————

快捷方式,不能随意快

星期日, 11月 9th, 2008

最近设计师小X遇到一个问题。他在设计一款全新的Web产品,通过几轮仔细地对功能及任务划分,确立了导航的组织结构与形式。Tab之间的任务关系为并列关系。

如下图:

由于是新产品,需求方对于这样的任务组织形式显得有些不自信,担心常用任务a1和b3无法被用户快速找到。每次操作需要花费一定时间成本去查找任务入口等。于是,需求方就“大胆”地提出这样一个想法:

在首页首要位置划分一块区域,把“用户常用”的功能链接放到里面。为名“快捷方式”,并解释说可以节省用户操作成本,不必浪费操作轨迹。

如下图:

首先,我对于这样的“节省方法”不赞同。其次,分享我不赞同的理由。

Windows这样定义快捷方式:快捷方式是Windows提供的一种快速启动程序、打开文件或文件夹的方法。他是应用程序的快速连接。

1,此产品导航设计,是对产品任务结构按不同属性划分任务主要属性是用户查找功能的路径上重要的可信的路标,在产品最初期破坏属性路径等于是杀鸡取卵。举个例子:如果把任务比作一台电视机的话,快捷方式就像是一只遥控板。只有一台电视机的时候,我们可以拿起桌上的遥控板轻松快捷地控制电视的开关、频道的选择等。当一间房子有数百台各自播放不同内容电视机的时候,没有分类的、堆在一起的、各自不同的遥控板显然起不到快捷的作用了。

2,在按不同属性划分的并列关系导航中,用户行为的分布也非常广泛。在一项新产品中提及“常用任务”只是一厢情愿的臆断。

3,在产品的初期版本,尽量保持最简设计。发掘、发现、培养富有逻辑的任务组织方式,而不是任意做加法。

4,假设在首页显要位置增加了这个“快捷方式”区域,这种不含有任何组织逻辑的方式会在产品中被愈演愈烈,它的方便快速的使命很容易就成了“解决问题”的“伪救命草”。

————————–   END ——————————

以下是Mark的一点想法:

        今天中午耍着我的BB8700,快捷操作是其使用中的一大心得,可是我还没有熟练使用,把玩时一方面想着使用快捷操作,一方面又愈发想不起来到底是按哪个键,有点想按部就班地去执行,犹犹豫豫中反倒显得更加笨拙和缓慢了,郁闷。想一想,现在我们使用的电子产品,包括Windows 、Linux的OS,手机,笔记本等,快捷操作似乎成为其应用的一个重要组成部分,也是很多高手引以为傲的资本。可是,我在想,快捷方式,站在产品的角度来说,真的是很好的用户体验吗?我觉得目前至少有三点我不敢认同:

1.现在不同产品的快捷方式仍有很大不同,造成用户有时出现使用错乱的现象;

2.某一产品的快捷方式快捷地没啥道理,记忆比较困难;

3.有的产品注重了快捷操作的设置,反倒降低了其用户体验的改进动力。

        我们的产品是Web应用系统,快捷操作,一方面包含了利用键盘按键替代鼠标点击的传统意义上的快捷操作,另一方面,也包括了上面转载的博客中提到的快速入口的快捷操作。读了上面的博客,我有如下体会:

1.Web系统的快捷操作确实要注意一下其本身的内在逻辑性,不能成为一切快速达到、快速解决的救民稻草;

2.过多的依靠或者布置了快捷操作,是不是说明本身系统的导航、跳转操作存在一些问题呢?有无可能一个Web系统只能让用户在其项目导航系统中去跳转,但体验也是不错的呢?

我觉得越多的元素,如果不是具备超好的用户体验指导,很可能带来越多的用户教育成本。

当然,一切不能一概而论,想想很多系统,确实逻辑、概念太复杂了;难道复杂的系统也不是太适合做个Web系统?这个我再考虑下,呵呵。

最近工作中的一些心得杂想

PDI后工作中和生活中都做了些小调整,还是那句话,要坚持要执行。工作中注意下与同事的交流、向同事学习,有些体会,聊做记录。

@mic:

1.职业发展目标:工作中技术广度重要,深度同样重要。针对我们现在的工作岗位,职业发展也是有细分的,比如Web的前台技术或者后台Server开发,自己要有所考虑,尽管不一定是现在做出选择。

2.要关注底层协议的原理,平时很多东西只是知道些皮毛,根源是对整个Web协议不熟悉。

3.要做好工作,首先要热爱行业,关注行业。

@spark:

spark最近专注于系统的性能优化,由于我做的部分页面成为性能优化的瓶颈,所以和spark进行了一些交流。首先,我挺佩服spark和robert能看懂我的龌龊代码的,本来逻辑就挺复杂,加之我的一些非常规处理,使得代码的可读性比较低,而我自己也体会到看别人代码是要付出比自己写代码更多的精力的。在我看来spark的性能优化大致包含了四个部分:1.简化逻辑;2.SQL优化;3.页面缓存;4.代码改进。经过和诸多同事一道讨论,针对需求树形列表页面的优化目前准备采用简化逻辑(一种近似的生成方法)和代码改进(减少查询次数)。以上实属无奈之举,spark在SQL优化方面做过尝试,效果不是很理想,这个优化过程我也有所旁观,感触比较多的是:

1.建索引:这个以前基本上没接触过,后续要关注;

2.复杂SQL的应用,包括join、嵌套、exist等;

3.关注SQL的运行时间和是否使用索引。

走出磨坊-痛苦转型篇

一日傍晚,乘班车回家,坐猛男minglin旁,期间聊起,鸣哥道:以前跟joe一道回家,最近很少,每天加班啊!我笑了笑,想一想,最近确实够忙的,我算按时下班的人了,组里好多同事此时还在忙着Check out和Check in呐。

TAPD的产品之路是曲折的,我们组的敏捷研发之路也并非顺畅;从上到下,我们期待着走出一条充满Tencent特色的敏捷研发之道,但从磨坊中拉出一只有战斗力的正规军又谈何容易。

近一个月来,整个组工作强度和产品的压力都比较大,我感觉这种压力也一定程度上影响到了我们的整个项目管理,同时,一直以来,我们在敏捷研发实践中有些环节还比较薄弱。首先,整个研发流程的节奏的把握,一方面工作强度时紧时松,另一方面有些研发环节,如测试、用户Showcase等不能按时保质的完成;其次,我始终有一种感觉,我们自己对产品的目标不是很清晰,或者团队内存在一些认知上的差异,这导致了我们的研发过程易收到用户需求和同类产品的影响,学习标杆和以用户价值为依归是很好的理念,但我想其内涵应该是学习标杆的思想(仅非表现形式)、响应用户潜在需求(而非浅层表述);再次,团队建设还是有些欠缺的,我留意到另一个组KM组存在一种相对较务虚、非纯技术与业务的小型交流会,感觉气氛不错,另外,不局限于自己的一小块工作领域,关心团队内其他同事的工作、技术体会乃至生活感受似乎不错。

我们是一个年轻的团队,大家在工作中也相处的比较融洽,大家不同的成长背景、技术背景导致了团队建设中种种问题,如果我们整个团队决意要走出磨坊,成长为专业的研发团队,从半职业或者业余到职业的转变必然要经历转型的阵痛,及时总结、寻求帮助,希望我们早日脱下换上真敏捷的内核。

 

 

Thinklet Team-看图说话

      这是Thinklet团队的合照,我个人觉得这张照的不错!

      Look,有男有女,有帅有靓;有高有矮,有胖有瘦;有分头有乱发,有四眼有隐形四眼。还有很多特质是照片表现不出来的,总之,我们的团队充分体现了生物多样性的自然学优势,具备持续发展的良好条件,我看行!

Ipod touch 2 摸索之路 (持续更新)

       放血买了个人首款Apple产品,ipod touch 2。苹果的产品,果然是精品,外观精致之极,以至于太容易留下指纹,于是我将它包裹起来。拿在手里把玩了半个月,时常感叹touch的体验确实不错,今日和oscar还谈起由touch联想到如何做我们的产品这个话题:核心体验做到极致,锦上添花的贴心功能又能给用户带来惊喜,确实上到一个境界了。完成了一个玩家的初级体验后,我觉得应该深入摸索下touch的一些更有趣的玩法了,本文聊做记录。

       www.weiphone.com 一个不错的toucn/iphone的产品使用论坛。期待touch 2G的破解。

 

IPOD不为人知的隐藏功能

(1)当你玩游戏时,快速的连按2下HOME键,就可以跳出透明的音乐快捷方式

可以按开始,暂停,上下换歌;锁着的状态,按两下也可以调歌。

 

(2) 同时按HOME键和上面那个关机键,可以截图。

Passion & Show-Time

      1月16日,气温宜人,南中国某“K吧”,部门隆重举行迎新晚会。重赏之下必有勇夫,各个组使出浑身解数,激情演出,晚会气氛相当火爆。结果很和谐,尽管过程很曲折。

      作为一个对奖励没什么想法的同学,我在台下完整了看了各个组的表演,我觉得尊重他人的劳动成果是一种表演者应有的胸怀,也是晚会的真正意义。看得出,很多同事对奖项看得很重,表演确实卖力,有几个瞬间还是很精彩的,比如老大参与的热舞、dancy极具地方特色的小品、最后的6位MM红衣热舞,颇具水准。

      当然,我始终还是最中意咱们组的节目,如果那天有的同事因各种原因错过,除了遗憾就是遗憾了。排练节目的过程是痛苦的、曲折的,甚至包含了浴火重生的过程。我现在理解本山大哥了,演出前一晚,本子几乎是推倒重来,绞尽脑汁想包袱,那叫一个身心俱疲啊~!这个锤炼、萃取的过程,让我们逐步认识到了我们自己的优势,这个不仅仅是指表演上的,也可以延展到其他诸多方面。正如我前面的博文提到的,我们的最大优势就是“激情”、“活力”与“敏捷”!短时间的剧本创作与润色,高强度的舞蹈排练,对变化的快速响应与执行很好的体现了上面的三大特点。纵观,三个组的节目,内容与表演人的特点其实挺吻合的,很有意思。

      积蓄的Passion需要一个Show Time,我们的表演展现了我们的Passion和Thinking,我最大的遗憾就是参加了表演,不能在台下完整欣赏XDJM的表演,我想那是相当的精彩。我们没有拿到最佳男女主角,那是因为我们每个人都奉献了精彩绝伦的演出,你挑得出谁是最佳吗?嘿嘿,大家要加油啊,发现个个都深藏不露啊,艺术细胞挺多嘛,以后别藏着掖着了!

Passion & Football

      为期2个月的系统五人足球赛在寒风中落下帷幕,而我们的热情却是越发的高涨了。

      第一次组队,大家难免紧张,狂胜一场,小负两场,得了个殿军,还算不错,其实主要是大家爽到了,打得是相当热血。

      总结下自己的表现:防守为主,中规中矩,居然还有个进球;比赛中有些紧张,高对抗中处理球比较拘谨,进攻时没有充分发挥出来;传球准确度不高,防守时转身有些慢。总的说来,还行,以后有机会,还要搞!

      整个比赛过程,部门表现得很团结、很有气势;其中平台组则可以视作其中最有气势的一个Punch。啥叫Passion?就是球场上“追死他”、“逼死他”和“抢死他”。不管做啥,要专注、要投入,要倾尽全力;要享受这个过程,但绝不放过一个好的结果。

      我们很High,会不会踢的都很High,而且越不会踢越High,这个才是足球的真谛,技术可以提高,没激情,那就成了中国足球了,很危险。平台组还涌现了一个足球宝贝,美貌与智慧并存,前可过人、后可堵门,站在场边还可跳舞助兴,是个很有Passion的Girl。

      有了Ball,我们就可以玩了;有了Passion,我们还可以干很多有意义的事。

Passion & Punch

2009年1月9日,一场别开生面、持续至深夜的团队聚会,带给我很多感触,在此Mark一下。

1. Passion

      Offsite会议上抛出了一个针对团队Passion的思考,我也考虑了一下,首先,作为一个如此年轻的团队,Passion应该不仅有而且还应该成为我们的优势,同事有这方面的忧患意识也很难道,我想,只有对自己的技术能力、产品质量和职业前途有更高期望和更远大抱负才会提出这个问题来探讨;其次,我觉得疲劳是绝对的,激情是相对的,解决Passion问题的前提是自己对从事的工作的认可程度,在此基础上,再套用一句老话:干一行,爱一行,我想工作的激情还是可以延续相对长时间的。

       近段时间,我们的团队不断上演着很热血的行为:我们的热血足球,我们的Punch Party,以及即将到来的很黄很暴力牛年续集,这些可以视作我们成功的Team Building,来年春暖花开之时,我们如何将这些活动中迸发出的Team Passion转化为工作中的Team Power&Idea值得期待,我自己也要加油!

2. Punch

      这是一次很有Web2.0特点的聚会。我第一次尝试了一把私房菜,吃到的菜式倒是没有很深的印象,但主人将“私房”的气氛演绎得不错,满屋子古色古香、笔墨纸砚,觥筹交错间回荡着一曲古典弦乐。

      一如既往的用酒灌一把各个大佬,大家带着微醺的奇妙感觉,进入了个人分享环节。投影仪、笔记本和PPT我们自己的准备工作相当专业,当屏幕上打出了那个拳头时,大家已经摩拳擦掌、跃跃欲试了。9个同事,9个主题,我仔细听了每一个用时7分钟的演绎,从话题的选择和现场的互动来看,我觉得这个环节是非常成功的。首先,同事们分享的话题我都很感兴趣,有些领域使我平时完全没有去关注和涉猎的,比如生儿子、搭讪、蜜月旅行、摇滚音乐等等。其次,分享的同事能拿出他(她)们生活中很有意思的东西出来与我们分享、探讨,我觉得非常有利于提升团队的凝聚力,让我们发现其他的同事原来在生活中有如此广泛的爱好和精彩的经历,他们在平时工作之余也在尽情享受这生活的乐趣。我很羡慕他们的精彩生活,也很希望今后有机会和我的伙伴分享我的有趣经历,呵呵。

       我们是一帮搞互联网的,非常注重分享;对于我们的团队内部,线下的分享与线上的分享同样的重要,第一个充满激情的Punch已经打出去了,期待下一次,让我们活得更精彩!

 

08月 2010
« Jun    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
MC Inside