《精益创业UX篇——高效用户体验设计》一第2章 在对的时间做对的研究

本节书摘来自异步社区《精益创业UX篇——高效用户体验设计》一书中的第2章,第2.1节,作者【美】Laura Klein,更多章节内容可以访问云栖社区“异步社区”公众号查看

第2章 在对的时间做对的研究

精益创业UX篇——高效用户体验设计
本章概要

了解在产品生命周期的每个阶段里,哪些调研最适合你的产品。

获得并不常见的那些节省时间和金钱的调研方法。

当你与用户交流时,了解你几乎肯定会犯的错。

有很多创业者和企业家来找我想要“做更多的用户研究”。虽然他们想做研究这很不错,但是他们根本不知道应该做什么样的研究。本书最后一章会讲到应该做哪些研究以尽早验证想法,不过在此之前让我们先谈谈其他的一些研究方法。

有数以百计的不同方法来收集用户相关信息。其中一些可能现在就可以帮到你,而有些可能会浪费掉你大笔的财力。你知道它们的区别吗?如图2-1所示。

5517.png

图2-1 这是研究方法,你知道哪种适合你吗?

当然,只有那些真正想要在第一时间做调研的产品负责人才会遇到这样的问题。我只是经常听人们说一些类似这样的话:“哦,我们没有时间去做用户研究。”

你猜怎么着,自作聪明吗?如果你没有时间去做用户研究,一旦你开发错了还要另花些时间来修复产品,我敢保证这肯定会发生。事实是,你并不是没有做研究的时间。

我会给你一个例子,但我要你知道到这是唯一一个我已经听过无数遍的故事。

有家公司刚刚发布了一个全新的用户界面。因为这是昂贵的企业产品,所以这意味着它的用户数量并不多,而且为了使用这款产品,用户为此花费了数万美元。

公司认为这个产品已经过时了,是时候更新视觉包装了。这些所谓的“只是视觉更新”的东西却改变了关于产品的几个相当重要的部分,其中包括用户如何读取他们的文件。

当管理者向我展示了新的视觉包装时,我问他们在新功能上线前做了多少的可用性测试。他们说:“没有做过,我们有紧迫的最后期限,况且也没时间。”

接下来,我问他们用户反馈如何,答案是“不太好”。

果不其然,改变用户读取文件的方式,却没有首先了解用户过去如何读取他们的文件,这就造成了一系列问题。用户立即开始抱怨并要求回退到以前使用的老版本。想必这肯定不是公司预期其庞大而昂贵的优化设计所应带来的结果。

最后发生的可能看上去很熟悉。该公司花了几个星期做减损控制,并寻找方法来重新设计以找回漏掉的那些用户功能。他们还花了很多时间舒缓用户情绪,给用户支付了一大笔钱,并安抚他们,承诺这样的问题不再发生。

当然,如果公司仍然不对其设计做可用性测试,可以预料到这些问题依旧可能发生,而且会一遍又一遍的发生。

这个故事最可悲的是,也许一个星期的用户研究就可以预防大多数的问题。公司可以通过观察用户使用产品的情况来避免更改了关键的用户功能。如果让用户使用一些原型设计产品,他们很快就能够发现这个全新的视觉设计其实破坏了产品的重要流程。

换句话说,要节省大量的时间和金钱,就要在第一时间做对的事!

道理其实就这么简单——如果你在对的时间做对的研究,你最终会节省时间和金钱。

所以现在我们可以得出结论,那就是用户研究非常重要,但很难弄清楚在这个点上哪种研究刚好适合你的产品。让我们看看为了能获取到产品反馈我们都有哪些选择。

我已经提到过你应该做的几种不同类型的用户研究:用户验证和原型测试。现在我想分享几个你可能没有考虑过的快速方法来测试你的想法。

竞争对手测试
你的竞争对手是谁?不要跟我说:“我们没有任何竞争对手!我们颠覆了行业!”一派胡言。我知道你是独一无二的。但请现在停下来,找出你的竞争对手是谁。

如果你真的想不出任何人,想想哪些产品可能同样是给你的目标群体使用的。

现在去测试他们。

你的竞争对手犯的错误
这就对了。去测试别人的产品,你要做的不是去帮他们修复问题,而是要避免他们犯过的所有错误。

你看,无论他们有多强大或他们拥有多少市场份额,你的竞争对手也在搞砸一些事情。这就是你去利用他们弱点的机会。

这不仅会帮助你识别出哪些是你不应该犯的错误,而且还可以提供真正抓住产品核心的方法。这是在企业软件或复杂的应用程序中使用的非常有用的方法。如果可以争取到一直使用复杂产品的10%的用户,给他们提供简洁和优雅的用户界面,你就可以打败用户日渐讨厌的复杂且畸形的产品。

这一类测试的好处在于,在制作产品之前你可以随意做这些测试。甚至在有产品想法之前就这么做。这是一种寻找到真实的用户问题,并且也正好是你有能力去解决这些问题的好办法。

立刻行动起来
这很简单。发布一些Google、Facebook或者Craigslist[1]广告,找到四五个竞争对手的用户。如果他们就在附近,那就去拜访他们。如果他们离你很远,可以使用共享屏幕的视频聊天软件和他们取得联系。安排时间去观察这些用户,在自然情况下观察他们如何使用竞争对手的产品。

注意,起初仅仅只做观察。观察了一段时间后,再问他们一些问题。下面是一些好的例子,当然也可以基于你的观察提一些你觉得有必要的问题:

你喜欢这个产品的什么地方?

你不喜欢这个产品的什么地方?

你对这个产品的哪里感到困惑?

这个产品有什么让你感到特别不爽吗?

这个产品缺少什么吗?

你如何学会使用这个产品?

你是在哪里听说这个产品的?

你试用过其他类似的产品吗?

为什么你选了这个产品而不是其他的呢?

(用于企业产品)哪部分工作是你必须要做、但这个产品却没有提供相应功能的?你是如何看待这个问题的?

五秒钟测试
你可以做另一个非常快速、低成本而且很容易的测试去观察用户如何使用你的产品。请记住,尽管你已经知道你的产品是做什么用的,但你还是会惊讶于用户压根不知道你是谁,你的产品是什么,或他们为什么要用它。更可怕的是,在他们见过你的真实产品之后往往还会有这种感觉。

在你打算创业时最重要的决策之一就是如何对用户描述产品。如何解释这是什么,如何让用户理解你要提供给他们的好处和特点是什么,这是你要传递的消息,你需要从一开始就测试它。它起始于你的着陆页。

着陆页如此重要的原因在于这关乎人们对你的第一印象,甚至有时是把访客转化成用户的唯一机会所在。如果有人点击了你的着陆页却很快就离开了,那就已经失去了潜在的收益。

无论你是想要说服人们注册互联网的服务,或在线订购产品,还是让用户打电话给销售代表索取样品,在着陆页上失去你的潜在用户都是大概率事件,不是因为人们不想要你正在贩卖的东西,而是因为他们不知道这个产品到底是个什么东西。

着陆页的目标应该是将访客转换为用户。指标数据可以告诉你是否做对了。A/B测试可以告诉你在各个着陆页中哪一个效果最好。

但这些都不会告诉你为什么着陆页在转化用户。找出用户对你的着陆页反应的唯一方法是回答下面的问题。

用户觉得这个产品是做什么的?

用户认为这个产品是给谁用的?

用户知道如何获取该产品吗?

换句话说,你需要测试信息传递、品牌和产品里的关键环节。

你可能想知道为什么需要测试信息传递和品牌之类的东西。毕竟,你可能已经请了一个不错的视觉设计师来画一些很好看的界面。你也可能已经雇佣文案编辑写了一些华丽的文章。你大概已经围坐在一间会议室里,并与他们详细讨论了这些东西。

但问题是,你的视觉设计师和你的文案编辑,还有你的整个团队知道你的产品的具体细节,然而对于第一次访问你的着陆页的访客来说,他们很可能不会在页面上停留多久的。

你需要弄清楚,页面上阅读起来极其痛苦的长篇大论和华丽的视觉设计真正给访客传递了什么信息。要做到这一点,你需要用真实用户来对着陆页做测试,这可以让你获得用户在最初看到这个页面的时候最直接最真实的反应。

立刻行动起来
这里有几个很简单的方法。首先是拉拢陌生人。

去当地咖啡厅、熟食店、酒吧,或其他看起来不太奇怪或不太容易被打断测试的地方。带上你的电脑或平板,里面有好几个不同版本的着陆页。着装得体,带上钱。

告诉人们只要他们观看你的创业产品的页面就可以换一杯饮料。向他们保证不会推销任何东西。接下来就可以向他们展示你的着陆页。

然后变换着问他们一些我在前面提到过的问题,例如:

这个产品是做什么的?

这个产品是给谁做的?

如果是朋友推荐或者点击广告之后来到的这个页面,你会怎么做?

随和并礼貌地问人们对这些问题是如何考虑的。不要太苛刻,记得给他们买饮料。

如果你想要征求更多的意见,不仅仅是从家附近收集到少量的反馈,可以试试一个叫UsabilityHub的产品,我用过,效果不错。它叫做五秒钟测试。

只要提供一个着陆页的静态模型,输入上面那3个问题,并申请10或15个测试者,然后离开一段时间。

当你在等待的时候,UsabilityHub里的用户会只有5秒钟时间来查看你的着陆页。然后他们将被要求回答你指定的问题。你会得到一份关于所有答案的统计报表以及最常用词汇的标签云。

这种方式非常简单,并且便宜得不得了。最棒的是,你会发现,当人们是否决定注册使用你的产品时,你给用户留下的最初印象到底是什么样的,如图2-2所示。


6def6f8900d354892bc88571d0a2154be3cfc289

可点击的原型测试
你过去使用某个产品并试图执行某些任务最后的结果却只是沮丧和困扰吗?如果你的答案是没有,我劝你最好还是再仔细想想,你这可是在面对一本书里的假设问题公然说谎。

现在你需要意识到在一个产品发布之前,那些真正令人失望的绝大多数功能是可以完全避免的。方法就是做出最常见功能任务的原型,并且在你还未写下一行代码之前测试它们。

在前几章讨论早期验证的时候我提到过原型测试,接下来我会告诉你,原型测试在什么时候是最好的测试方法,在什么时候可能会被误用。

你必须小心处理原型测试,因为它是这一章中最重要的方法。你看到的其他测试方法能在一小时,或者几分钟时间内做完,但原型测试要求你创建一个原型,而这就要花些时间了,如果对原型的保真度有更高的要求,花费的时间还会更多。

一个可点击的原型可以简单到仅仅是把几个线框图链接在一起,以便当用户单击按钮时可以跳转到另一个静态页面。也可以是复杂到构建整个用户界面,使得用户看到的是和真实产品几乎一模一样的东西,但背后其实并没有任何实际的程序在运行。原型越接近真实产品,得到的反馈质量就越好。

那么在什么时候,那些你认为不得不去开发的复杂功能到最后却可能被完全抛弃呢?答案很简单:当你要开发的一些很有可能会让用户困扰或沮丧的交互功能的时候,并且如果你没有做正确的测试,再加上这些功能也不容易被验证到的时候。

有个例子,我曾经在一家C2C网站工作,那些曾经在互联网上尝试过销售东西的人会知道,在线销售确实是个既麻烦又复杂的过程。你至少需要产品简介、价格、运费,一些实物照片。另外还要添加很多其他的东西让你销售得更快。

通常来说,在你销售多种类型的产品时,销售流程会变得复杂,每个都可能会要求不同的信息。比如说卖烤面包的需求可能就跟卖车的不一样。

这些复杂多变的交互流程势必会造成潜在的让用户困惑的地方。实践是检验真理的唯一标准,因此,想要知道设计到底是好是坏,正确的做法是观察用户在没有外界帮助的情况下如何使用产品。

如果等到产品已经被开发完毕了才进行这些测试,这就意味着一旦产品出现问题,对其进行修改将带来更多的工作量,如果出现的问题还比较严重的话(这是大概率事件),可能你不得不丢掉一切重头再来一遍。

就个人而言,我宁愿扔掉快速构建出来的原型,也不愿白白浪费几周的工作时间。很大程度上来说,我发现工程师也同样喜欢这样做。

另一方面,有些时候你根本不用费心去做一个完全交互的原型。例如,着陆页通常只不过是一些文字,还有一些允许用户登录或注册产品的简单按钮。

这并不是说你就可以不用做测试了,事实上必要的测试还是要做的,并且我已经给出了几个很不错的、简单的方法。就像让开发工程师花尽可能少的时间开发真实页面那样,你应该尽可能地先做个假的页面。如果产品非常容易修改(换句话说,你的团队在使用持续部署,持续优化,并且设立了良好的度量指标的话,你很容易就能对产品做出修改的,对吧?那有些时候直接把产品发布出去,拿真实的用户来做测试也是可以的。

是的,我承认在这两个例子之间有灰色地带。有些时候不得不凭借自己的经验去做判断。下面是一些应该采用交互原型的例子:

产品一旦出错就很难对其做出修改,或者修改非常耗时——例如,你制作的是盒装软件或者硬件产品。

你所制作的产品人命关天,或者一旦出错将会造成严重后果——例如,你正在开发医疗设备或选票。

预期的用户流程比点击单一按钮复杂得多——例如,用户必须通过在几个区域移动或输入各种信息,其中每一步都可能影响之后的决定。

如果你的设计是错误的,你的工程师会生气因为他们要抛弃之前所有的工作——例如,我见过的每一个工程师都是如此。

立刻行动起来
步骤1:使用交互原型。有很多方法来执行此操作。我不会把每种方法都讲一遍,因为已经有人做过了。我喜欢用HTML和JavaScript制作高保真原型。有人喜欢Axure,有人喜欢Flash,虽然我从没见过这种人。

关键在于选择你用着顺手的可以快速开发和迭代改进的方法。记住,你的产品或者设计很可能会出错并且需要做出相应的修改,因此得想办法让自己执行得更快。

有一些人会使用PowerPoint或Keynote构建原型。他们错了。使用这些本来是用作其他用途的工具进行原型开发会使得后期的维护工作变得非常困难,并且为了设计出更好的用户体验,通常设计师会花双倍的时间来和这些工具做斗争。即使要花些时间学习和使用前端开发技术,不过使用专门用来制作交互体验设计的工具整体上还是会大大提高你的效率。

步骤2:确定要采访谁和执行什么任务。我不会专门介绍这个过程中的每一个具体细节,有成百上千本书已经对此有过介绍了,例如Morgan Kaufmann写的《Observing the User Experience》[2],可以教你如何招募参与者,如何评分审核和创建任务。

最重要的是要弄清楚你想要做什么测试,然后要求一些陌生人来尝试用你的产品执行些任务。如果你有已经制作好了产品的话,尽可能让用户试用你的产品。他们能让你知道你的产品模式是否符合他们当前的行为。

下面这些是我测试过的功能。

超过一个步骤的注册流程。

购买流程。

搜索和浏览体验——例如,查找某一特定产品。

分享经验——例如,拍摄图片或留下评论。

文件上传和编辑。

整个产品导航。

硬件产品上的物理按钮。

可以依据不同平台按需安装不同种类的产品。

其他任何超过一个或两个步骤的流程。

步骤3:招募3到5人来进行测试。你可以在自己的办公室里测试,也可以在他们家里或他们的办公室,或使用远程共享桌面软件,例如GoToMeeting。

例如,如果你要测试结账流程,要求每个参与者使用你的原型产品去尝试购买某类产品。然后观察他们是如何执行这项任务的,把他们感到困惑的地方记录下来,并询问他们整个过程的感受。

一旦发现一些用户抱怨的问题,则对原型产品进行优化然后再测试一次。反复尝试,直到用户能顺利完成大部分任务。

如果你有好几个原型产品,并且每一个的用户体验都不一样,你甚至可以要求测试参加者在这几个不同版本的原型产品上执行相同的任务,以发现效果最好的那一个。别忘了向不同参加者以不同的顺序展示原型。每个参加者都会在使用第三个原型产品的时候做得比第一个原型要好,因为此时他们已经对产品有了大致的了解。

游击队式的用户测试
很久以前,用户测试又贵又耗时。首先你需要租一个配备了大面积单向镜子以及昂贵视频系统的实验室,然后还要聘请像我这样的专家去向你的用户提问,并给他们分配任务。专家会写下三十页的报告,也许是产品哪些地方应该被改进优化的PowerPoint文档,然而这些东西并没有什么用。没人会读这份报告,文档会被遗忘在服务器的某个地方,一切都会变回原来的样子。

坦白说,这非常令人沮丧。

这就是我如此喜欢游击队式的用户测试的原因。它成本更低、更快并且更加可操作。它能让你快速的找出产品中的可用性缺陷。

换句话说,你会看到用户在努力理解他们到底应该怎么做。

由于游击队式的用户测试自身性质,你不太可能对当前用户进行测试,所以请确保你用它来测试新用户可能会遇到的问题,例如登入、信息传递或早期转化。

当然了,游击队式的用户测试在对那些不需要用户具备多少专业技能的产品进行测试的时候会收到更好的效果。我可不会在星巴克费心去测试一个新的导弹发射系统,除非这家星巴克的隔壁恰巧是美国国家航空航天局。

立刻行动起来
去你最爱的一家咖啡店,在你的笔记本电脑、平板或手机上加载你的交互原型、真实产品或别人的产品。如果参加者花个10分钟看了你的产品,请给对方买一杯咖啡。

一旦有了测试者,就给他一项任务去执行。不过得保证他至少对于产品中的某些基本概念有所了解。例如,如果你要别人来测试照片共享应用程序,请确保他之前用过Facebook或Twitter,并知道如何分享一张照片。

然后让他执行任务,你在一旁看着就行。不要给予帮助,不要提示,不给他做演示。不要花五分钟时间来解释你的产品是什么,仅仅只是让他尝试执行任务就好,观察他卡在了哪里。聆听他提出的问题 (但此时不要回答!)。当他做完任务之后,问他对于这个任务是如何想的。

然后给他买一杯咖啡,感谢他,并寻找下一个人。

在找到四五个人执行了任务之后,你应该对产品是否有可用性缺陷以及到底是什么缺陷都有了最佳判断。如果每个人都轻而易举地完成了任务,做得好!那就给自己买杯咖啡,或者一个松饼,如果它们看起来还很新鲜的话。接下来挑出另一项你感到好奇的任务,再找五个人去测试它。

另一方面,如果你发现这五个人在执行任务的过程中遇到了共同的问题,那就回到办公室,并找出解决问题的方法。优化原型或产品,然后再次测试来看看问题是否被解决了。

提醒一句:并不能以这种方法真正了解到人们是否会喜欢你的产品。你只能搞清楚人们是否了解你的产品。但是坦白说,游击队式的用户测试依然还是相当重要的。

还要补充一点:请闭嘴!以及一些获取反馈的窍门
我花了很多时间要你去问用户问题,并获取反馈。不幸的是,这是另一个看上去很容易但其实每个人都会做错的事。

例如,一位工程师讲述了他在创业过程中第一次收集用户反馈的经历。由于这是一个小公司,产品还没有真正开发出来,该公司为收集用户反馈定了以下目标。

获取人们是否认为该产品还不错的信息。

为市场营销和长远研究目标找出潜在的客户类型。

和尽可能多的潜在用户交流,获取广泛的反馈意见。

保持尽可能低的成本!

毫无疑问,他开发了一些错误的功能,并且在他同很多用户交谈之后得到教训。他分享这个故事给我时,有个想法一直在我脑海里徘徊:“这当然是不工作的!你为什么不事先学习一下收集用户反馈相关的知识呢?”

很明显,他不得不一切从零开始学习,因为他还没有浏览学习上百种关于可用性的课程,或接受任何用户访谈的培训。许多用户研究人员认为理应知道的东西,对他来说都是闻所未闻的。

为了帮助其他没有用户体验背景的人不再犯同样的错误,如果你想获得客户反馈而又没有太多经验,我为你整理了五个你几乎肯定会犯的错误的列表。

即使有多年的用户访谈经验,你可能仍然会做错这些事情,因为我见过那些理应懂得更多的人也会犯这些错误。当然,这个列表并不全面。据我所知你还可能犯下其他许多错误!但只要修复了这几个小的问题,就会大大增加你的用户反馈的质量,不管你在做的研究类型是什么。

请闭嘴
这是你要学习用户访谈的最重要的一课。你是在对他们进行访谈,你不是说的一方,你是倾听的一方。你需要他们的意见,而不是你自己的。为了得到这些反馈,你必须闭嘴并且让用户给出他们自己的选择,而不是让用户觉得受到了外界的干扰,从而变得有所抵触、戒备。

你还需要多给他们一些时间,让他们自己去摸索产品,而如果不去打扰用户的话,反而还会有助于缩短这个时间。

请记住,你可能已经盯着设计几个星期或几个月了,但作为参与者的用户可能还是第一次听说你的产品。当你第一次共享屏幕或提出一项任务时,你可能想立刻开始对参与者发问。请忍耐几分钟!给人们一个机会让他们自己去理解你的产品。在他们对产品感到适应后,会有足够多的时间去和用户交流,而且你也将获得更多更深入的反馈信息,所以没有必要急着向用户提问。

不要给导览
在客户访谈中我遇到的最常见的问题之一是缺乏经验的主持人在开始前给了用户过多的产品相关信息。

无论他们是想炫耀产品还是试图“帮助”用户不会迷失,他们在开始测试前,会有一段关于产品是什么,给什么人用,想要试图解决的问题是什么,以及有哪些炫酷功能的详细介绍。在导览结束时,他们会问这样一个问题:“所以你会使用这个产品来解决我跟你说的这个问题吗?”用户们除了说“呃……应该会吧?”之外,可能很难给出其他答案了。

与其给用户提供导览,不如让用户自己去探索。然后给用户尽可能少的背景信息去完成一项任务。例如,若要测试新的购物应用程序,我可能会给用户设置一个场景,就像:“你打算在网上买一条新裤子穿去上班,并且有人告诉你这个新的应用程序可能会帮到你。你已经把它从App Store里下载到手机上了。请为我展示一下你是怎么找到那条裤子的”。

我给用户的唯一信息是个基本场景,在这个场景里他已经找到并且安装了这款应用。接下来我就得让用户自己去弄清楚这个应用程序是什么,是如何工作的,以及是否解决了他们的问题。

开放式提问
当你开始问问题时,不要给参与者只是简单的回答是或否的机会。要通过提问来展开一段讨论。

以下这些问题是不太好的开场。

“你觉得这很酷吗?”

“这用起来方便吗?”

以下的问题会更好:

“你觉得这个怎么样?”

“进行的如何了?”

让问题有更广泛、更开放的结尾,越少引导用户就越有可能获得有趣的答案,甚至是你根本没想到要问的问题的答案。

追问
像下面这样的谈话在每个测试中至少发生过十几次。

我:“你觉得这个怎么样?”

用户:“这很酷。”

我:“到底是什么地方酷呢?”

接下来用户就会告诉我他觉得具体哪些地方很有趣并且对他而言很有帮助。

参与者在回答一些问题的时候,往往会用一些词表达他们对于产品的感受,然而这些词并不能传达出他们产生这些感受的原因。像“酷”“直观”“有趣”和“混乱”这类的词虽然很不错,但知道是什么引起用户的这种反应将会更有帮助。不要自以为知道是什么让产品很酷!

让用户失败
这可能是很痛苦的,我知道,尤其是造成用户失败的原因是你的设计或者产品的时候。我有遇到过这样的情况,开发人员在观察到参与者刚刚露出一丝犹豫迹象的时候就夺过鼠标给他们演示如何操作。

但问题是,你并不是在测试能否教会用户使用产品,而是在测试用户是否能弄明白该如何使用产品。很多时候,我发现自己从失败中能学到更多的东西。当四个参与者在执行任务时都以同一种方式失败了,也许这意味着这个产品需要修改,从而让用户可以以最顺畅的方式来执行任务。

另外,参与者无法立即执行一项任务并不意味着他就无法通过一定的探索发现正确答案。观察用户最初探索了哪些地方可以有效帮助你去理解参与者对这个应用程序的心理模型。所以让他先失败一会儿,然后给他一个小提示,帮助他继续朝着目标前进。如果他还是不知道该怎么做,就再多给点儿提示,直到他完成了该任务,或者你也可以直接进行下一个任务,并且把你找到的需要修复的地方记录下来。

通过这些技巧可以得到一个成功的用户研究吗?好吧,答案是不一定。但它们是避免反复错误的解决方案,尤其是对于没有多少经验或没有受过多少用户交流培训的人而言,会帮助他们得到更有质量的信息。

立刻行动起来!
从你的竞争对手的错误中学习:尝试对别人的产品进行可用性测试。

今天就去收集关于你的想法或产品的反馈:无论你在做的是什么,现在就尝试一种类型的用户研究。

更好地与用户交谈:尝试跟某人坐下来进行用户访谈,并且让他对你在做的错误功能提出反馈。

[1] Craigslist,一家网上大型免费分类广告网站。

[2] Observing the User Experience一书已被翻译出版为中文版《用户体验面面观》。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值