1700424330
1700424331
1700424332
1700424333
1700424335
用户体验要素:以用户为中心的产品设计(原书第2版) 第8章 要素的应用
1700424336
1700424337
不管你的产品有多复杂,用户体验要素都是一样的。但是,将这些要素背后的想法付诸实施却是一次自我挑战。这不仅仅是时间和资源的问题—它常常是一个心态的问题。
1700424338
1700424339
回过头来看这五个层面(战略、范围、结构、框架和表现)它们听上去都像是有一大堆工作要做。当然这种需要高度注意所有细节的工作,必须要花费几个月的开发时间和一小组经过专业培训的团队来完成,不是吗?
1700424340
1700424341
不一定。当然,对一些项目和一些企业来说,那些太复杂很难通过方法来控制的产品,通过成立一个由全职专家组成的小组来负责,是分配责任最有效的方法。此外,由于专家可以专注于完整的用户体验的某一个方面,他们通常对自己所承担的那部分工作有着更加深刻的理解。
1700424342
1700424343
不过,大部分时间,在有限资源下的小团队也能达到相似的目标。有时只有几个人的小组实际上可以产生比一个大团队要好得多的结果,因为他们更容易共享用户体验的设计版本,并及时同步。
1700424344
1700424345
创建良好的用户体验最重要的工作内容是大量收集亟待解决的非常细微的问题。“成功的方法”和“注定会失败的方法”的差异归根结底就是以下两点:
1700424346
1700424347
▼了解你正在试着去解决的问题。你已经知道在主页的那个紫色的大按钮是个问题,是按钮太大还是紫色不合适?它们哪个需要改变(表现层)?是这个按钮在这个页面上放置的地方不对(框架层)?还是这个按钮所代表的功能并不是用户所期望的那个(结构层)?
1700424348
1700424349
▼了解这些解决办法所造成的后果。要记住你所做出的每一个决定对其上、其下层面都有可能会产生“连锁反应”。在你的产品某个部分运作得非常好的导航设计,可能完全不符合结构层的另一个部分。产品选择向导的交互设计也许是一种创新的方法,但它是否能满足“技术恐惧症用户”的需求呢?
1700424350
1700424351
1700424352
1700424353
1700424354
必须要同时考虑五个层面的全部因素,这对于创建成功的用户体验是至关重要的。有专人分头来负起责任固然重要,但更重要的是要保证所有的用户体验要素都被关注。
1700424355
1700424356
你一定会惊讶于有多少组成用户设计开发过程的细微决定完全是不自觉地产生的。大部分时候,关于用户体验的决策总会体现在以下这些场景之中:
1700424357
1700424358
▼由现状决定的设计(design by default)。这发生在当用户体验的结构遵循其背后的技术,或企业的结构时。将客户的定单记录和消费信息分别保存在独立的数据库中,也许对于你现有的技术系统是合理的,但是这并不意味着把它们从用户体验中分开也同样是一个好主意。相似地,来自企业内部不同部门的内容,也只有在放到一起而不是保持独立的时候才会更好地服务于用户。
1700424359
1700424360
▼由模仿决定的设计(design by mimicry)。这发生在当用户体验依靠于来自其他产品、公共刊物或软件应用程序的相似情况时,不管这些情况对你的用户(或甚至对网站)来讲是否确实合适。
1700424361
1700424362
▼由领导决定的设计(design by fiat)。这发生在当用户体验由个人喜好代替了用户需求或产品目标驱动体验决策的时候。如果由于某个高级副总裁很喜欢橙色,配色方案中橙色就占了主导地位,或者由于研发工程师的领导喜欢下拉菜单,结果导航元素就变成了下拉菜单的话,你可能已经忽略了应该用于驱动你所做出的决策的战略目标。
1700424363
1700424364
1700424365
1700424366
1700424368
用户体验要素:以用户为中心的产品设计(原书第2版) 提出正确的问题
1700424369
1700424370
面对那些设计用户体验时需要解决的纠缠不清的小问题,有时会是一件令人气馁的事情。有时某一个问题的解决办法会让你不得不重新思考你认为已经解决的其他问题。很多时候,你必须在不同的做法之间做出妥协并评估利弊和进行取舍。当你夹在不得不做出此类决定的中间左右为难的时候,不管你是否采取了正确的做法,都很容易变得沮丧和怀疑。正确的做法是,将每一个决定都建立在对其背后议题的理解之上。与用户体验有关的第一个问题恐怕是问你自己的(这也是你应该回答的第一个问题):你为什么要这么做?
1700424371
1700424372
对于你即将面临的问题抱有一种正确的心态是最重要的。每一个用户体验的设计过程的其他方面都有可能导致调整,以适应时间、金钱和为你工作的人员。没有时间去收集你的用户数据?也许你能找到办法去看看已经拿到手的信息,比如客服的日志或反馈消息,去找到用户需求的一些感觉。负担不起租用可用性实验室的费用?那就找几个朋友、家人或同事来做一些非正式的测试。
1700424373
1700424374
不要以“节省项目时间或金钱”的名义对用户体验问题敷衍了事。在某些项目中,一些人会自作聪明地在这个过程的最末尾添加“用户体验评估”—在应该提出这些问题的时机已经过去很久以后。当发布日期确定后,你告诉自己“比赛开始以后不要顾虑太多”,这看上去好像是一个不错的主意,但这样最后很可能得到的是一个满足所有技术需求却恰恰对你的用户毫无用处的产品。甚至更糟的是,通过在结束时附加的用户体验评估,最后你可能会发布一个明知道已经被损坏却没有机会(或多余的金钱)去修复的产品。
1700424375
1700424376
一些企业很喜欢这种做法,称之为“用户接受度测试”,“接受度(acceptance)”这个词在这里的意思非常明显—问题不是说他们是否会喜欢或是否会使用这个产品,而是他们是否能接受它。这种类型的测试往往发生在整个流程的最后,在那个时候无数的假设已经在没有经过任何检查的情况下进入形成用户体验的过程中了。想在已完成的产品中通过用户测试中揭露出这些假设是极度困难的,因为它们藏在了界面和交互的外衣下面。
1700424377
1700424378
很多人提倡将用户测试作为确保良好的用户体验的一个主要手段。这种思路看上去是你应该做一些事,将它们摆到一些人的面前,来看看他们有多喜欢它,然后无论他们抱怨什么都将其修正。但是测试永远无法取代一个考虑周密的、准备充分的用户体验设计过程。
1700424379
[
上一页 ]
[ :1.70042433e+09 ]
[
下一页 ]