<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>刘钢的博客 - 我是UED &#187; 可用性</title>
	<atom:link href="http://www.iamued.com/tag/%e5%8f%af%e7%94%a8%e6%80%a7/feed" rel="self" type="application/rss+xml" />
	<link>http://www.iamued.com</link>
	<description>http://www.IamUED.com</description>
	<lastBuildDate>Wed, 18 Jan 2012 02:51:35 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>可用性测试过程中需要关注的一些细节</title>
		<link>http://www.iamued.com/user/593.html</link>
		<comments>http://www.iamued.com/user/593.html#comments</comments>
		<pubDate>Sun, 22 Nov 2009 05:37:51 +0000</pubDate>
		<dc:creator>RichieLiu</dc:creator>
				<category><![CDATA[用户研究]]></category>
		<category><![CDATA[可用性]]></category>
		<category><![CDATA[测试]]></category>
		<category><![CDATA[用户]]></category>

		<guid isPermaLink="false">http://www.iamued.com/?p=593</guid>
		<description><![CDATA[原则： 1. 我们测试的是产品可用性，不是使用者的个人能力 2. 尽量不要打断用户的操作 3. 尽量让用户独立完成 4. 测试环境和场景任务应当尽量符合用户使用产品的真实环境 5. 要让测试用户感觉到自己是被充分尊重的，尽量使其心情平和放松 其他： 1. 每次用户测试前先要把测试用电脑的缓存和历史记录清除。 2. 测试前一定要做预测试，把发现的问题记录下来，并在测试前把问题解决。 3. 用户到体验室后，不要马上开始，先和用户聊聊天，拉拉家常。让他放松，告诉用户先休息几分钟，过会我们正式开始，再向您介绍本次测试的主题等等。考虑准备一些和用户的沟通的东西。 4. 要和用户说明本次测试的产品、测试的目的、和测试大致的步骤以及可能花费的时间。 5. 注意和用户沟通的语气，语速要慢。如果担心用户对自己表达的内容没有完全理解，可以说“我把我的意思表达清楚了吗” 和用户说话时要尽力看着用户，保持微笑。 6. 过程中请尽量不要打断用户。 7. 用户碰到问题情绪记得事先安抚用户。如“这个问题很多用户都碰到了”或“这个问题不是很重要，我们先放放。” 8. 用户碰到问题时，可以提醒用户，不要代替用户操作，更不要说“您只要点一下这里就可以了”和不需要那样做等等，会让用户觉得他很无知。可以换种说话如：您可以试着这样操作看看 9. 不要问用户“你为什么要这样做。。。”可以换钟方式如“我刚才看到您是这样操作的，能和我们说说你的理由”或“当时您是怎么想的” 10. 如果用户操作的流程中并不是我们关注的流程，而用户由碰到了问题，这时候我们可以主动帮助用户。 11. 当我们决定介入用户操作时，先询问用户是否需要帮助，用户现在想做什么，碰上什么问题。 12. 引导员和观察记录员的电脑最好不让用户使用。 13. 如果用户不是在关键任务上出现问题我们可以主动提供帮助， 14. 如果在用户操作出现错误并遇见到他不能通过自身能力解决时应当主动帮助解决。 15. 不要说“你有没有听懂”，要说“我有没有说明白” 16. 当用户犯错误时要安慰他说“不只是您一个人有过这样的问题，很多用户也出现过类似的问题” 17. 不要把体验问题归结到谁的身上，无需给用户解释原因，不要承诺什么，只需记下问题反馈给相关人员 18. 不要问用户你为什么这样操作，要说“能告诉我你是怎么考虑的吗？”]]></description>
			<content:encoded><![CDATA[<p><strong>原则：</strong></p>
<p>1. 我们测试的是产品可用性，不是使用者的个人能力</p>
<p>2. 尽量不要打断用户的操作</p>
<p>3. 尽量让用户独立完成</p>
<p>4. 测试环境和场景任务应当尽量符合用户使用产品的真实环境</p>
<p>5. 要让测试用户感觉到自己是被充分尊重的，尽量使其心情平和放松</p>
<p><strong>其他：</strong></p>
<p>1. 每次用户测试前先要把测试用电脑的缓存和历史记录清除。</p>
<p>2. 测试前一定要做预测试，把发现的问题记录下来，并在测试前把问题解决。</p>
<p>3. 用户到体验室后，不要马上开始，先和用户聊聊天，拉拉家常。让他放松，告诉用户先休息几分钟，过会我们正式开始，再向您介绍本次测试的主题等等。考虑准备一些和用户的沟通的东西。</p>
<p>4. 要和用户说明本次测试的产品、测试的目的、和测试大致的步骤以及可能花费的时间。</p>
<p>5. 注意和用户沟通的语气，语速要慢。如果担心用户对自己表达的内容没有完全理解，可以说“我把我的意思表达清楚了吗” 和用户说话时要尽力看着用户，保持微笑。</p>
<p>6. 过程中请尽量不要打断用户。</p>
<p>7. 用户碰到问题情绪记得事先安抚用户。如“这个问题很多用户都碰到了”或“这个问题不是很重要，我们先放放。”</p>
<p>8. 用户碰到问题时，可以提醒用户，不要代替用户操作，更不要说“您只要点一下这里就可以了”和不需要那样做等等，会让用户觉得他很无知。可以换种说话如：您可以试着这样操作看看</p>
<p>9. 不要问用户“你为什么要这样做。。。”可以换钟方式如“我刚才看到您是这样操作的，能和我们说说你的理由”或“当时您是怎么想的”</p>
<p>10. 如果用户操作的流程中并不是我们关注的流程，而用户由碰到了问题，这时候我们可以主动帮助用户。</p>
<p>11. 当我们决定介入用户操作时，先询问用户是否需要帮助，用户现在想做什么，碰上什么问题。</p>
<p>12. 引导员和观察记录员的电脑最好不让用户使用。</p>
<p>13. 如果用户不是在关键任务上出现问题我们可以主动提供帮助，</p>
<p>14. 如果在用户操作出现错误并遇见到他不能通过自身能力解决时应当主动帮助解决。</p>
<p>15. 不要说“你有没有听懂”，要说“我有没有说明白”</p>
<p>16. 当用户犯错误时要安慰他说“不只是您一个人有过这样的问题，很多用户也出现过类似的问题”</p>
<p>17. 不要把体验问题归结到谁的身上，无需给用户解释原因，不要承诺什么，只需记下问题反馈给相关人员</p>
<p>18. 不要问用户你为什么这样操作，要说“能告诉我你是怎么考虑的吗？”</p>
]]></content:encoded>
			<wfw:commentRss>http://www.iamued.com/user/593.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

