贴士手取用文件原型

本教程中讲述了如何建立一个文件原型，并准备可用性测试做walkthroughs 。原型创作和漫游活动出现反复-作一些原型件，扎扎实实地漫游，数字出了什么问题或失踪，并有重复。有没有硬性规定时间有多长花每一次迭代中，这个过程通常需时，共有2个或3天，也许蔓延出超过一两个星期。

列表件所需的任务

使名单上白板或倒装图表的所有屏幕上你的原型将需要支持的任务，你所创建的-步骤从你的完成任务，范本是一个很好的起点。保持名单相当高层次的，你不需要指定每一个菜单或下拉列表中，因为人在屏幕上是负责其细节。举例来说，任务是打开一个退休帐户中，在财经网站可能需要以下画面：

浏览器窗口与控制
主页
现有的用户数在
创造新的帐户屏幕（）
定期/罗斯，爱尔兰共和军的解释
帐户摘要
隐私政策
条款和条件
退休储蓄计算器
共同基金筛

名单中并没有被任何特定顺序，因为这只是为你的好处，在确定哪些准备。它的通常是最快的，以创造这一名单看，在现有的接口，如果有一件;否则，你的风险使到成为一个讨论目前设计

不要忘了数据

有可能产生一些数据与任务，你需要准备太多，不只是一张空白的屏幕。开发商习惯于以思想的数据来看，结构（帐目说明的是一个20字符的ascii字符串），而不是内容（麦克的爱尔兰共和军）。但内容是什么用户关心的事了。在他们进入的数据是有意义的压给他们，他们期望的接口，以反映他们的资料输入。接口是真的只是达到目的的一种手段，因此，用户很可能会多加留意数据比他们向构件即弥补界面。

很多时候，它的重要用户，看看如何，他们的个人资料将出现在其他地方，在这个制度。如果用户是建立一个在线分类广告以填写表格的形式，他或她可能想要预览认为广告在同一格式，该系统将使用展示。如果你问用户根本想象的东西（ "它会让你预览你的广告" ），你可能会错过重要的反馈，例如， "哦，观望了这些额外的空白线，我想它有" 。

数据您使用应具现实性不够，用户可以与它以一种有意义的方式。这一点尤其重要，当用户领域专家在此事的界面。

要确保数据的"挂起来" ，在一个前后一致的方式在全国各地的任务。如果你问用户找到所有三个卧室的房子出售，但你表明，他们的搜索结果，其中包括约4间卧室，用户可能不知道他们所做的是错的。（当然，如果你是聪明与可拆卸磁带，你可能都无法掩盖的4间卧室的房屋，因此，解决这个问题就飞）。

你应该还包括一个现实的复杂程度，在你的文件中的原型。如果你的网上五金店卖37无绳演练，但你假装有企业只有3家，你会设计演练页的方式未必规模。这是不是说你需要的产品页面，为所有37 -你可能会制约任务，以这样一种方式的用户可能会看，只有6人。

如果你得到实际的数据？一些公司已经开始适当地完成数据库，这是用于质量保证测试，或者营销有某种联系，他们使用的演示。但是，如果你的测试数据库包含大多胡说八道填料，如" test1 " ， " asdfasdf " ，你最好创造你自己的。如果你有麻烦，拿出了切合实际的情况下，谈以人在你的公司，他们所接触的用户。只是不使用一个数据库，具有真正的人的资料，在这-那太现实了！

隔膜等impera

最好的办法，以营造原型取决于规模和组成的团队，并有多远沿线发展。在一个极端，如果你正在生产样机的一个现有的接口和它有一个简单的序列屏幕，你可以简单地作屏幕捕获并打印出来并以此为基础将你的原型（这是一个伟大的任务，为一名实习生）。在这种情况下你可能会宣布休会，直到第二天，当你有屏幕上打印出来，然后做你的第一个漫游。

如果接口不存在尚未实施或正在实施实质性的变化，有一些设计所需要的工作。如此分而治之：每个人对团队把他们的英文缩写对名单旁边的屏幕，他们将做好准备。离开的名单，每个人都可以看到它，让他们都知道，他们的工作对什么人可能想通过沿想法或合作。

这种分治的想法最初是使一些人产生紧张，因为感觉像我提倡设计委员会，一个委员会说，可能包括一些nondesigners 。但在实践中，这是不是会发生什么。该文件原型是由核心团队，其中由定义包括那些负责界面，使该原型始终保持在适当的手中。最原型有一些屏幕是明确界定，并相对轻松地创建，如浏览器背景或日志-在屏幕。我发现，是该团队成员较少的设计专长倾向于签约，为方便件，留下重型起重机械为主导设计师（）。最终的结果是，这项工作是拆散了，在适当的方式和每个人的利益，成为熟悉的界面。（假如有一优设计理念是否能够蠕变，可用性测试会被清除出）。

这是没有错的，有整个原型创造的一个或两个人，如果说的是什么你最舒服。但也可能是有利的分工，落实工作，因为我已经在这里描述的，或什至尝试并行设计。

现有银两新设计？

有时辩论的时候，是否它的更好，以测试一种原型的现有设计或废料，它在主张一种新的方式。无论答案是错误的一份文件，原型可以演变，从任何起点，因此，这里有一些因素要考虑：

成本的错误是低，如果你尝试新事物，它失败，你有没有浪费太多时间。而且往往你将学习资料，这将帮助你，即使你在维持现行设计。举例来说，一个团队原型向导，以帮助一个配置任务。他们不知道是否他们的发展时间表，将让时间来落实向导，但他们仍得到反馈的术语，概念，及如何协助用户需要作出决定，在前进的道路上。所有这些信息是有用的，尽管它原来，他们始终坚持更改现有的设计。
不重新设计的东西你没有进行测试，如果你不是有共识的有什么不对现行版本，你可能会想用它来首对夫妇的试射，直到你明白你的问题，亟待解决，然后做你重新设计。人们很容易落入陷阱的改造和抛光设计之前，使用者看到的，只是遇到的第一次可用性测试显示，某些巨大的问题，逼着你重新设计。在另一方面，如果你的客户已经告诉你是什么毛病，你有想法，如何修复它，去为它。（作为一个开发商曾经对我说： "我们知道，这部分是坏的-有没有必要找1 0人，在这里只是告诉我们它的坏" ）。
限制时间，而不是创造性的，你不想花长的时间设计没有得到用户反馈-将战败的目的文件原型。其中一个方法来管理，这是建立一个上限金额的时候，你会花创造你的原型。当你达到这个极限，考验你。

有一个好处，纸张的原型是，你可以原型的东西没有考虑，是否真能建成。这也是它的一个弊端。在何种程度上的技术限制，应考虑取决于不管你是原型的东西，你打算释放在3个月或3年的时间越长，你的时间内，能够更多的注意力集中在用户需要，然后计算出后，如果和怎样建设党。有一种类似的说法，为坚持界面风格指南。如果你的公司有一个公司的风格，引导和它的不可转让的，它的可能，最好是让你的文件中的原型符合风格指南。但是，如果你正努力使情况改变这些准则的，你可能会故意做一些不同，以确定它是否会更好地开展工作。

手得出银两屏幕快照？

或许还有的一个现有版本的界面和有人说，你首先使屏幕快照。以下四个因素来考虑。

多少，你期望改变它，你还不如用一个屏幕上打的东西，你知道你不能改变的，例如一个屏幕上，从作业系统。但是，对于屏幕你期望演变（这也许是他们大多数），你可能会希望借助他们的手，让手取用的变化将不会坚持指明了方向，他们会如果你使用屏幕快照。
哪种方法速度快？虽然好像它会以更快的速度来创造一个原型从屏幕快照，在实践中，这是情况并非总是如此。考虑到时间步行到印表机，等待你的屏幕上走出来（其中一半是停留在队列后面的人，印刷20份的功能规格），即可获得拦途截劫，有人想讨论昨天的会议上，等等。问一问自己，你是否可以素描部分的屏幕速度更快，尤其是直截了当。
哪里是来的数据？如果你的界面显示的信息从一个数据库（例如，一个产品目录），你恰巧有一个合适的数据库，另一方面，印刷屏幕快照可能是最快的方法，以获得实际的数据。在另一方面，如果你有，以弥补自己的信息，它可能只是作为容易引起场面手。
请问列印被可读吗？列印的屏幕快照有时难以阅读。没有涉足的技术细节，颜色，你可以看到屏幕上往往不出来不少，同时对文件（反之亦然）。油墨是一个不同的培养基比轻。灰色的背景下运作良好，在屏幕上可以看看泥泞对印刷画面一枪。根据该决议的打印机，图标和图像有时失去其清晰度。因此，如果你打印屏幕快照，并发现他们很难读，最容易的事，可能重新划定他们的手。你们已经有了设计，所以这并不长。

虽然我不知道有任何实际证据，我认为，一个混合的手制订和印刷帘仍能充分地传达给用户，该设计是在不断变化，从而鼓励他们的反馈。我还发现，原型即开始了与尼斯，整齐的屏幕快照，通常会演变成搜集屏幕快照，屏幕快照与手工更正，有的已被重新设计，并得出手。因此，当屏幕快照是容易做，我觉得这是可以使用它们作为出发点和重划屏幕，如果当你找到需要的。

如果你的手手绘更正印屏幕快照，用户有时会聪明地认识到，用手拉校正是这件事他们应该把重点放在。（但仍然有大量的案件- i'd说，大多数的情况似乎并不是这样的情况，可能是因为屏幕上仍然有几个问题。），如果您担心手取用改变可能提供人工线索无论是重划几个周边元素，另一方面也（这就是广泛可拆卸磁带是有用），或重做屏幕上的说明。

greeking和简化

greeking就是要用胡说八道的话，代表文本。在一份文件中的原型，你可以使用squiggly线，而不是胡说的话，以服务于同一目的。 greeking不需要在许多原型，但它的价值认识。以下是三个原因，你可能需要使用greeking -第一个原因是最常见的，和其他两个更不寻常。

您还没有完成设计界面，因为纸原型，让你测试一个界面之前，它的设计完全，有可能是部分的介面，并没有被创造。举例来说，你可能知道你的软件应用将有意见，并帮助菜单，但你却没有给任何思考其内容。因此，你可以创造greeked意见，并帮助菜单，而所有的选择都squiggly线。如果用户试图去有些事你greeked ，你告诉他们， " squiggly线意味着你了解这里的一切，但它不是你要找的对象" 。当然，如果用户保持gravitating向一些你恰巧有greeked ，你也许要考虑把什么，他们实际上却在寻找。
为了简化零件的界面，你无法控制，一个典型的例子是，档案开放的对话框。如果一个任务需要用户打开一个文件，你可以创造一个简化版本，包含了刚才的文件名，他们需要执行这项任务。有没有真正的好处眼看着人们使用更为现实版的对话框，如果你不打算作任何改动。此外， greeking避免了需要有用户浏览，通过一个文件结构，是人为的对他们来说，这是较有趣的，你看，相对于其他的东西，他们可以做的事。
为了防止用户从越来越被拖入内容。举例来说，当仲介业者的可用性测试房地产申请时，他们不断想要阅读的描述，加上房子，我们需要从老了。因为我们正试图测试只是其中的一部分功能，导航，搜索引擎，整理，而不是格式的说明，有房子的描述是一件分心的事情。因此，我们greeked说明，使大家有目共睹，用户信息为代表的一所房子的描述，但不让他们侧重于它。

当人们第一次了解greeking ，他们的想法是诱惑，过度使用它。以往的例子，应该被视为战术运用在特殊情况下，而不是你做的是一个理所当然的。不希零件的界面，是有关什么你试着考验。例如，在一个下拉式选单，你当然不希望希腊所有的选择，除了一个你希望用户选择-这使得任务人为地方便了，你可能不知道某些重要的东西。这也很重要，在许多情况下，有实际内容的原型，因为它的有趣收看用户作出决定此基础上的内容。

以下是一些提示，以使你避免花太多时间准备，另一方面拉帘。

洁净也不指望（多）。本文原型应该公正整齐足以让阅的，但没有neater 。它的优良提请徒手而不是用直尺。如果别人能读你的文字，它的不够好。抗拒诱惑，重新划定东西，以"整治乡村起来" 。机会是，你就会想要改变它，因为一旦你测试过，所以，你还不如等到你知道什么问题，你试着去解决。不健全的设计您还没有考验，因为大部分的努力将付诸东流。
单色的，是好的，正如俗语说， "你可以把口红就一头猪，但它仍然是一头猪" 。彩色救不了本身设计有问题。事实上，它是一个很好的策略，以设计出一种界面单色首。颜色和其他视觉修饰，可以说，后来一次，你确定你的设计并不是猪。但是，如果你要坚持与黑色的，这也是可以的。
大小（通常情况下）不打紧，如果用户将书面资料上的原型，你需要使编辑领域，大到足以容纳他们的写作。绘制原型有点大于生命，也有利于观察员观看行动。除此之外，大小通常不打紧太多。它的好，如果原型是不会引起大规模的，有的屏幕上可以相对较大的比别人。作为一项规则，概念" ，使所有符合"之前，应很好地理解什么是"它"构成的。如果你还在确定的功能和内容，你大概可以推迟你的关注屏幕的房地产，直到晚一些，在这个过程中，只要你保持你的设计合理。如果你需要，又要着眼于空间限制，你可能会想用图形文件或干脆计数性状和/或线路作为替代空间。

使用屏幕快照

假设你想用一些屏幕快照，在你的文件中的原型，这里有一些东西，你可能想知道的，因为你做你的准备：

放大，使观察员可以看到，这可能没有必要，如果你有一个真正好的照相机安装或只有一两个观察员，但如果你有几个人坐在一张桌子，大部分将无法看到实际尺寸文件中的原型。它也可以被用户很难写在编辑领域，是为大中屏幕上，尤其是具有透明度的标志。你也许要放大的屏幕，约30 ％至50 ％，用一台复印机。
消除拖欠白化出单选按钮和复选框，然后取代他们的版本就可拆卸磁带。单选按钮可能不是太大的困难，因为它的相当清楚地表明可拆卸磁带取代了原来的默认状态的按钮。如果用户unchecks一格，但是，它可以引入混乱后，在任务，如果你的原型仍显示x在盒子。
网上具体： 明确的联系，历史上 ，在浏览器，然后才作出屏幕快照。如果您不这样做，你几乎探索出了一条以显示使用者的正确道路-访链接通常出现在一个不同的颜色，即使你的打印灰度的。我的一位同事ruefully报告说，她的用户很快就捕获到访问环节正在正确的道路，并破坏了大部分的价值可用性测试。
网上具体： 捕捉整页一次。并非所有屏幕抓斗工具可以做到这一点，虽然这一特点日益普遍。 snagit从techsmith是一个例子，一个公用事业部门已自动卷轴功能，或者你也可以简单地打印从浏览器（正如我刚才解释，你不必包括浏览器帧和控制，如果你创造一个浏览器背景）。绝对避免任何工具，需要你去粘贴局部屏幕加上手工完成。

当你考虑到这些因素，账户中，你可能会认为它只是作为快速写生有的屏幕上的手。通常最好的行动就是要为所欲为，是最快的，可以带你原型在一起，然后修改它根据需要，由于可用性测试

分离分子

最界面，无论是他们的网页或软件，有部分地区仍然存在明显的大部分时间。例如，软件应用系统通常有一排菜单和图标全国最高，也许有人在底部。有些申请使用左手手树结构，扩大并坍塌。网站往往会产生持久性排链接在顶部，左侧导航面板（有时变化，在较低层次的地盘），和一个区。

你的第一个冲动，可能使屏幕快照的每个整个画面中，其中一款置换你期望用户看到的。但是，如果你决定要做出改变，以一个持久面积屏幕上，如左边的导航小组，你必须作出这样的改变，同时在每一页。因此，它的，往往容易分割萤幕纳入其主要组成部分，以方便修改只是萤幕的一部分。（有时，它可以补充有点混乱，有几件是代表一个屏幕，而只是告诉用户， "这是所有在一个屏幕上的"通常的把戏）。

组织原型

毫无疑问，文件原型是狼籍。挑战之一是组织所有在纸上，让电脑能够很快找到下一个。有没有正确的方式来组织一个文件原型-每台计算机将发展他或她自己的系统定位件很快。但这里有一些提示。

定购 ... 不要啊的，通常无法确定确切的秩序，在这种秩序屏幕将用。即使有预期的步骤顺序，用户可回来了，跳跃前进，做一些事造成错误讯息，看东西的帮助，等等。但是，如果你可以相当肯定用户会期一系列的屏幕在一个固定程序（例如，一个补习），它可帮助有多少，他们就回来。
表或三响粘结剂。大部分的电脑我已经共事会蔓延出一堆堆文件，摆在桌面上，但有些人用3环粘结剂，以容纳所有的屏幕和翻盖来回奔波，向适当的页面。我从来没有使用粘合剂，因为它似乎有点局限-你可以不看多件事情的时候，它可能需要更长的时间才能找到下一个画面时，你不能看到的一切。另一方面，关于粘结剂是更轻便，所以做为准工程给你。
组织的任务与功能，有时它可以帮助组织得粉碎任务，一切为了任务1云在一个文件夹（或栈），一切为了任务2在另一个文件夹，等等。不过，有些作品可能需要多种任务。如果你不指望这块改变（也就是说，档案开放对话框），你可以简单地创建多个拷贝，并把一个在每一个文件夹。如果是有可能改变的话，你要记住，以创建多个副本的修改版本。这可以是一个痛苦，如果接口正经历快速迭代的，所以你可能会得到更好的起飞创造只有一个版本的每一块，并把它在它的文件夹中，将第一次使用。在以后的工作，采取件，从文件夹中较早任务，你需要他们。在考试结束后，以一对夫妇分钟内把一切都回到那里，你就会想要它才开始的下一个考验。
使用的信封。下拉式选单，通常写在小纸上，所以他们可以很容易迷失在一个文件夹充满较大件。有一种想法是符合他们并排在一个开放的信封，让你可以迅速找到你需要的。如果件都很小，你甚至可以缩减战线的一个信封，让他们都看得见。
"画廊的恼人件" ，越小件，越有可能他们会迷失航向。这一切都为双事情的对可拆卸磁带在这个过程中学习桌对面时，电脑总是结束了与不端原型零件坚持他或她的手肘（记录我见过这么远，是三）。为了减少这种问题，可以指派一纸作为"画廊的恼人件" 。所有的小件-其中包括那些前来松散测试期间去那一张纸，而他们比较容易找到。

设计审查

有可能是很可观的效益，以产品团队，在用了一份文件原型，以步行通过自己的任务，如果没有用户。我要区分两种类型的walkthroughs - 内部漫游，它是用来准备原型（及团队），可用性测试，并设计审查，凡文件，原型是用来作为一种手段，在讨论与界面利益相关者。你可以听到这些名词用不同的，比我已经确定了他们在这里，并在一定程度上他们是重叠的概念。本节简要论述了设计审查;

我的许多客户都对我说，刚才的过程中创造的任务和纸原型，让他们看看在不同的界面，甚至在第一届可用性测试，它已经是一个有益的演习。有些产品团队，创造纸原型，并利用他们在内部设计审查，从来没有进行可用性测试。文件中的原型，不仅可以促进富有成果的讨论，特别是对那些可能有困难，可视化行为的一个界面，从规格。设计审查用文件的原型，使产品开发团队的看到界面，从新鲜的角度- they'll公告烦恼像繁琐开关间来回奔波两帘或联系的人失踪。它们也可能找出较大的问题，如一名失踪的要求。虽然设计审查，并不能代替可用性测试中，他们可以帮助产品团队，并提供了补丁的问题，在界面上。所以考虑采取纸原型，以你的下一界面审查会议。

内部walkthroughs

内部漫游，因为我已经确定了它是一种活动，是帮助产品开发团队，准备进行可用性测试与纸的原型。 1漫游类似可用性测试中，你有一个原型和任务，但在这方面不存在外部用户。相反，调查组的一名成员作为一个"专家用户， "表演的任务，方式，产品开发团队的期望它做的。

1漫游，是一次实战演练，是帮助团队：

确定零件的原型，还需要创造。
准备不同的道路使用者可能合理地采取（正确或其他方式）。
看看如何接口，是为了工作，这是特别有用的那些创造文件或训练的人或新加入开发团队。
让计算机实践操作所有这些在纸上。
查明有关的问题在技术上的可行性。通常情况下，这些都是研究后，漫游。

你应该拥有你的第一个漫游一旦你认为你最有什么样的，你必须找到至少将通过其中一项任务。视乎大小的团队工作，对原型，它可能会更容易些等到你准备步行通过的各项任务，一时间，或者，你可能想对付他们的一个或两个晚上。这也依赖于复杂的界面和信心，你已在设计。如果你正在打造一个全新的东西，它的往往是有用的，把作品连同早通比晚通好，公正，以确保所有的挂在一起。

如何做漫游

举行一次漫游，你需要一个表，这是大到足以蔓延出样机。转让人以下作用：

电脑的人，组织和操纵那些比特的文件（可多于一人）。
专家用户，一个产品团队成员扮演这个角色，担负的任务，作为一个专家（有人理解接口），将应该做的。它的并没有参与这方面的角色，使离奇失误或其他激进偏离规范的离开，对于真正的用户！
抄写员，这个人写所有失踪件，问题，以及问题上来了。它的情况并不总是最好地利用时间，让整个团队讨论每一个问题就当场来决定。该抄写使得名单，使这些事情可以得到解决后，漫游。关于小队伍，抄写员的作用，可结合其他任何角色。
调解人。严格来说，漫游不需要推动者，虽然它没有伤害有一个指定的人，带领会议，并确保不偏离太多。谁图，以方便可用性测试应该参加一些walkthroughs做准备; walkthroughs是一个伟大的方式，以熟悉的功能和行为的接口。对于新的主持人，这也是一个机会，来实践。

当然，其他成员的产品开发团队也能在场，以帮助失踪原型件，发现潜在的问题，学习有关的接口，或者干脆希望能更好地了解纸张的原型。

正如专家用户，通过社会各界的任务，面临的问题及问题，将出现和抄写写这些了，随着失踪原型件。在去年底，抄写原文名单和队员们决定谁做什么，才下漫游。同意的时候，下次漫游前分散，以个人做的工作。我在咨询实践中，我已经发现， 15至30分钟，通常是足够的人来研究一两个问题，并作出了一些屏幕-换句话说，做出足够进展，它的价值做的是另一套漫游。如果你让太多的时间，你就会失去你的势头。

注意：这不是可用性测试！

还有的往往是一个强有力的诱惑，把漫游到过早可用性测试提出一项共同工作者发挥用户。通常情况下，有人会说， "嘿，我们为什么不如此，并因此成为注册用户？她从未见过这样的材料，以前如此，她也会非常大" 。抵制！存在一些问题，这都明显与隐蔽：

你是不是准备为黄金时间。原因walkthroughs是为了准备可用性测试。你一定能找到尚未解决的问题，其中有些你会最终讨论对现货，这是好的，为你们这些人的工作界面，但浪费了时间，为的人，你问帮你。他或她有更好的东西，这样做比听你辩论是否按一个钮，应被禁用，或者是您如何将处理特定的错误。
合作的劳工并没有真正的用家。合作工人通常并不能代表真正的用户，即使他们倾诉用户每天或曾经是用户自己。你的合作工人知道的东西，真正的使用者不，如贵公司的业务策略，缩略语，自创品牌外，其他产品等。很可能，你的合作工人更多地了解你的界面，即使他们没有看到，它比真正的用户做的。因此，行为的一个协调工人通常不是一个好的替代什么真正的用户有这样的要求。（可能的例外是：你正在设计一个内联网或其他界面专为雇员贵公司），如果你把一个协调工人真正"知道什么" ，对自己在做什么，那么你可能会碰到相抵触下一个问题。
有道德和法律上的考虑，当你可用性测试与内部员工，你实际上有更多的道德和法律责任比，如果他们被陌生人。 It's one thing if you have a bad test (one where the user feels foolish or appears ignorant) with a stranger, but it's quite another if you have to see that person in the cafeteria every day. It's even worse if that person is your boss! There are even potential liability issues: If a co-worker participates in a usability test and feels (correctly or otherwise) that their performance was perceived poorly by others, you could have a lawsuit on your hands. Of course, the likelihood of this is small, but you should think twice before asking someone outside the product team to play user.
You don't want more opinions. I've yet to work at a company where there's a shortage of opinions. The whole purpose of usability testing is to gather data from real users, not yet another internal opinion. It may not be wise to redesign an interface solely on the basis of internal feedback. If a co-worker gives you feedback that you don't want to act upon (at least not yet), then you're put in the awkward position of explaining why you're apparently ignoring the valuable advice you asked him or her to give.

Keeping the aforementioned cautions in mind, sometimes it can be valuable to ask a co-worker to play user for another purpose: to introduce them to the concepts of paper prototyping and usability testing. Some of my colleagues have reported very positive results from inviting an influential manager or VP to play user after first carefully explaining the technique of paper prototyping and the purpose of the walkthrough.

Who Should Be the Computer

People sometimes think that you have to be a software developer to play Computer, but that's not necessarily the case. In fact, it can be valuable for a tech writer or trainer to be the Computer because this gives them experience with the interface. It's true that the Computer needs to understand how the interface behaves in response to the user's inputs, but one can usually pick up the necessary knowledge simply by watching someone else walk through the tasks a couple of times. Just as the interface isn't expected to be perfect, neither is the person playing Computer—if the Computer makes a mistake during a usability test (which is not uncommon for more complex interfaces), there's usually another team member present who will notice and help get things back on track. (It can also take some of the pressure off users to see that the Computer makes mistakes too.)

When practical, it's good to have more than one person who is prepared to be the Computer. You don't want to cancel a usability test because your Computer is home with the flu. Also, it's fairly demanding to be the Computer. In particular, it's hard for the Computer to also take notes, which is an important thing for the lead designers to do. So try to spread out the effort a bit. Some teams have two or three people who take turns playing this role, or they may have different Computers depending on the task. I've done paper prototype tests where Person A kept all the pieces for tasks 1 and 2, Person B was responsible for tasks 3 and 4, and so on. (While the Computers are changing places, I joke with the users that we're giving them a hardware upgrade!)

Some teams have a Co-processor work with the Computer. The Co-processor finds pieces, puts pieces back when they're no longer needed, writes things on the removable tape, and otherwise helps keep the prototype from becoming a disorganized mess. For example, when a user clicks "Add to Cart" on an e-commerce site, the Co-processor prepares a piece of removable tape to represent how that line item will appear in the shopping cart.

When (and When Not) to Redesign

Sometimes even an internal walkthrough is enough to expose major problems in the interface. The mere act of performing the steps as users are expected to do can reveal aspects of the interface that are cumbersome or even technically impossible. When this happens, it's appropriate to come up with an improved version of the design even before the first test. It makes sense to redesign the prototype if the team agrees that the issues found during walkthroughs are valid and serious. (As an example that may seem extreme but that occasionally happens, sometimes even one of the lead designers can't do a task.)

On the other hand, you should resist the temptation to redesign based solely on someone's opinion or the desire to try a different approach without understanding the strengths and weaknesses of the existing one. The problem with doing redesign before testing is that you don't yet know what you don't know. Once you watch users work with the prototype, you'll better understand the problems you're trying to solve. So if design ideas come up, jot them down and save them until you have some data from testing—then you'll know which of your ideas you truly need.

The Final Walkthrough—the Usability Test Rehearsal

The usability test rehearsal is basically another internal walkthrough, but with a few extra elements added. A rehearsal is not specific to paper prototyping—it's an important step in preparing for any usability test. Ideally, the rehearsal should take place the day before the first usability test. It often involves a larger group than those who worked on the prototype.

The purpose of the rehearsal is to make sure everyone (the Computer, facilitator, and observers) and the prototype are ready for usability testing. The facilitator runs the rehearsal in a similar manner to how he or she will conduct the usability test, but with several differences. Instead of focusing attention on the user (who in a rehearsal is still one of the product team members), the facilitator's goals during a rehearsal are as follows:

Familiarize observers with the prototype. It's hard to get much use out of watching a usability test if you've never seen the interface before. That's especially true of paper prototypes because they change rapidly; the design you're testing tomorrow may not have existed yesterday. Because observers aren't allowed to talk during a usability test, encourage them to ask questions during the rehearsal. Once they understand the interface and the test procedure, they'll be prepared to get the most out of watching the usability tests. (Caveat: The observers aren't allowed to redesign the prototype at the rehearsal. If they have ideas, they should write them down and save them until the team is ready to make changes to the prototype.)
Collect people's questions. Let everyone know at the start of the rehearsal that you want to gather all their questions about how well the interface will work and what real users will do. For example, "Do users realize that they can sort by the column headings?" The test facilitator should write down these questions with the aim of getting as many answers as possible during the usability tests.
Estimate task timing. Although it isn't possible to say with any confidence, "Task 1 will take 14 minutes," timing the tasks during the rehearsal will give you a sense of how long it takes to complete each task (assuming all goes well ) and whether you have about the right number of tasks to fill the time allotted for the tests. During a rehearsal there is usually some discussion among the product team. To some extent, this discussion is a proxy for the amount of time that users will spend thinking aloud or getting stuck in the usability tests.
Decide when you'll intervene. If there are doc/help writers on the team, they may be very interested to learn if the material they've written is useful. But many users don't go to the help or manual of their own accord. Discuss if and when the facilitator should intervene to suggest that they look something up. You might also want to agree on at what point the facilitator should step in and help users complete a task in the interest of moving on to the next one. (To an observer, it can be nerve-wracking to watch a user struggle with a task that is meticulously explained in help, to the point where that observer can no longer concentrate on what the user is doing. To forestall some of this stress, it can be helpful to discuss when and how the facilitator will assist users. You may also want to include this information in the Notes section of the task template.)
Create a "game plan." It's not necessary to use the same tasks for each usability test—paper prototyping allows some room for improvisation in the test structure depending what you're learning. At the rehearsal, the facilitator should get a rough idea of which tasks are of greatest interest to the developers and under what conditions it may be appropriate to skip or reorder tasks. This is what I call a "game plan." An example of a game plan might be, "We'll do the first 3 tasks, and then depending on how much time we have, either go on to 4 or skip to 5." Like its sports counterpart, a usability test game plan is not a rigid structure but can be adapted depending on circumstances. For example, if a team member is very interested in task 5 but she can attend only two of the usability tests, in those sessions you might decide to do task 5 earlier to ensure she'll get to see it.

Pilot Tests

Unlike a usability test rehearsal, a pilot test is not something you'll do for every usability study, although there are situations in which one can be useful. A pilot test is a cross between an internal walkthrough and a usability test. Its main purpose is to refine the tasks and methodology used in the main tests (as opposed to a usability test, which is used to refine the interface). Unlike in a walkthrough, in a pilot test you bring in a representative user. Unlike in a usability test, you ask this user to give you feedback on the tasks and instructions, not just to do them. You can also time the pilot test to get a better idea of how long it will take users to accomplish the tasks. In a pilot test, it's appropriate to interrupt the user (politely, of course) to have a discussion with your teammates about how you want to change the tasks or methodology—this is not something you want to spend time doing in a usability test.

A pilot test is useful when you don't want to change the tasks during the usability study. For example, I tested a live Web site in the United States that was also being tested in Denmark. My Danish counterpart created the tasks, and I conducted the pilot test. I then reported back to her my results such as, "Task 2 will take more time than we thought, so we should allow up to 40 minutes. But task 3 and task 5 cover similar ground, so let's eliminate task 5." The pilot test helped us coordinate our methods so that our test findings would be comparable.

I reserve pilot tests for situations in which there is a high degree of rigor needed in the testing methodology, such as a competitive evaluation of two released products. Because a paper prototype is continually evolving, there is less need to hold the methodology constant, so I don't bother with pilot tests. However, there is no reason not to conduct a pilot test if you feel the need for one. In particular, a pilot test can be a good opportunity for a new facilitator to practice under the guidance of a more experienced one.

this is an article added by Judith Kreempy