下篇现在才更新，最后一篇我们聊聊容错性设计方法的应用关键。
1、用户使用场景模拟
用户使用场景模拟是传统的用例分析方法，可以分析用户可能会用到的功能以及产品使用流程，进而分析用户可能会犯的错误。但故事板相比传统的用例方法，会更细致的对用户使用场景进行模拟，通过诉说一个故事，营造一种情境包括使用背景，环境状态等，去模拟产品的使用场景，通过将故事视觉化，描述用户使用产品的过程，来评断设计构想是否符合设计主题，从而进行产品修正。
2、用例模型分析
用例猛地一听像是程序设计或者测试方面需要的，但是我们知道做产品的朋友在写需求文档的时候，虽然因为多方面因素，可能是因为公司习惯、人员配备等等因素写法并不一样，但或多或少还是接触过用例这样的一个概念。
做产品经理都知道，面对的交流沟通的人比较广泛，不仅要和市场销售提交需求部门沟通了解需求内容，同时设计产品的时候需要交给UI、前端、技术来实施。但是在实施的过程中怎样让技术更明确产品的需求呢？以前在设计产品前的用例设计、时序图设计都是技术部门完成，现在很多公司也要求PM来做用例图和时序图等这些工作，而不是技术来完成这些了。
用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的”角色”关系，以及系统内用例之间的关系。
用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统，用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素，用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
同时，用例图也可以把日常、业务、系统实现需要的一些逻辑，很好的通过图示传达。用例图是一种描述产品需求的方法，使用用例的方法来描述产品需求的过程就是用例模型，用例模型是由用例图和每一个用例的详细描述文档所组成的。在技术和产品的工作领域里都有用例模型的技能知识。技术人员的用例主要是为了方便在多名技术人员协同工作，或者技术人员任务交接时，让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时，让参与者更好的理解功能的逻辑。
产品用例是一种通过用户的使用场景来获取需求的方式，每个用例提供了一个或多个场景，该场景说明了产品是如何和最终用户或其它产品互动，也就是谁可以用产品做什么，从而获得一个明确的业务目标。
3、故事板
大多数产品经理都知道说用户体验设计，但是对于用户角色模型和用户场景却了解较少，而在产品设计中“设计故事板”能够直观地体现出用户和产品使用情境。
那么，故事板是什么呢？故事板，起源于电影和动画行业。在电影电视中，故事板的作用是来安排剧情中的重要镜头。他们相当于一个可视化的剧本，导演会用这种形式预先过一遍镜头和机位故事板展示了各个镜头之间的关系，以及他们是如何串联起来，给观众一个完整的体验。
现在，“故事板”在产品设计过程中也被广泛的采用，虽然产品设计故事板和动画、影视制作故事板都是用一系列的图片和语言组成的视觉表现形式，但是之间的所表达的信息和目标用户却是不一样的。我们在做“产品设计故事板”的目的是让产品设计师在特定产品使用情境下全面理解用户和产品之间的交互关系。
4、人物角色模型
虚构出的一个用户用来代表一个用户群。一个persona可以比任何一个真实的个体都更有代表性。我们通过调研去了解用户，根据他们的目标、行为和观点的差异，将他们区分为不同的类型，然后每种类型中抽取出典型特征，例如：一些个人基本信息，家庭、工作、生活环境描述，赋予一个名字、一张照片、场景等描述，就形成了一个具象的典型用户画像。人物角色一般会包含与产品使用相关的具体情境，用户目标或产品使用行为描述等。为了让让用户画像容易记忆，可以用具体的名字、标志性语言、几条简单的关键特征进行描述。一个产品通常会设计3～6个角色代表所有的用户群体。
用户模型看起来比较像用户市场细分。用户细分通常基于人口统计特征（如性别，年龄，职业，收入）和消费心理，分析消费者购买产品的行为。用户模型更加关注的是用户如何看待、使用产品，如何与产品互动，这是一个相对连续的过程，人口属性特征并不是影响用户行为的主要因素。用户模型是为了能够更好地解读用户需求，以及不同用户群体之间的差异。
某个人物角色能代表多大比例的用户？首先，在每一个产品决策问题中，“多大比例”的前置条件是不一样的。是“好友数大于20的用户”？是“从不点击广告的用户”？不一样的具体问题，需要不一样的数据支持。人物角色并不是“平均用户”，也不是“用户平均”，我们关注的是“典型用户”或是“用户典型”。创建人物角色的目的，并不是为了得到一组能精确代表多少比例用户的定性数据，而是通过关注、研究用户的目标与行为模式，帮助我们识别、聚焦于目标用户群。
人物角色实际上并不存在。我们不可能精确描述每一个用户是怎样的、喜欢什么，因为喜好非常容易受各种因素影响，甚至对问题不同的描述就会导致不同的答案。如果我们问用户“你喜不喜欢更快的马？”用户当然回答喜欢，虽然给ta一辆车才是更好的解决办法。所以，我们需要重点关注的，其实是一群用户他们需要什么、想做什么，通过描述他们的目标和行为特点，帮助我们分析需求、设计产品。
用户模型（人物模型）能够被创建出来、被设计团队和客户接受、被投入使用，一个非常重要的前提是：我们认同以用户为中心的设计理念。用户模型（人物角色）创建出来以后，能否真正发挥作用，也要看整个业务部门/设计团队/公司是否已经形成了UCD的思路和流程，是否愿意、是否自觉不自觉地将用户模型引入产品设计的方方面面，否则，用户模型始终是一个摆设、是一堆尘封的文档。
5、用户行为观察
这是最直接的方式，但成本也很大。通过直接观察用户使用产品的过程，来发现他们操作时的错误。通过访谈来获得发生这些错误的真实原因，进而指导错误反馈设计。对于移动互联网产品，产品经理需要自己去用你的产品，在不同的时间，不同的地点，不同的心情，各种各样的场景下使用，发现产品存在的问题，培养自己在设计App时的场景感。腾讯有一个“10/100/1000法则”：产品经理每个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验。这是一个比较有效的做出好的产品和设计的笨方法。另外，如果产品设计地足够简单，错误会变得很少。
总结：
首先我们介绍容错性设计是什么？
容错性设计是从计算机等相关领域传来的概念，运用到互联网产品领域的话，指的主要是产品对于错误的容纳和解决能力，这包含了两个方面：
二是产品使用过程中错误的解决效率。
那么为什么产品要做容错性设计呢？也是两个方面：
一是因为用户容易出错
如之前所说，容错设计包含两个方面，一是用户在产品使用过程中出现错误的概率，二是产品使用过程中错误的解决效率。那么评价容错性好坏的标准就是，出现错误的概率越低，错误解决的效率越高，产品的容错性就越好。又因为容错性属于产品的可用性范畴，所以我们也可以这样理解，那就是产品的容错性越好，产品可用性就越好，那自然产品的用户体验就越好，这也是容错性设计的最终目的，就是让产品更可用、更易用。
那么倒推回去，出现错误的概率越低，错误解决的效率越高，这样的标准应该满足哪些设计要求呢？就出现错误概率低这一条看，应当满足突出正确操作、规避错误操作发生风险、减少误操作概率这些方面，就解决效率高这一条来看，应当满足出错信息提示到位、能解决的错误系统自行解决、其他错误提供有效解决方案这些方面。
其次我们谈到了容错性设计的方法
这一内容主要包含五个方面，分别是“正确有效的引导和提示、避免用户出错的障碍和限制、给予反馈和帮助、错误的恢复和减轻用户的负担”。
先说第一点，“正确有效的引导和提示”，也就是在用户操作前即给出正确且有效地引导和提示，有助于减少错误发生的可能性。这有以下几点方法，一是提供说明文字和引导方向，二是说明与引导要突出易懂，三是当操作不可逆时，提示用户可能发生的后果。
第二点我们说的是“避免用户出错的障碍和限制”，就是通过设置一些障碍或提出一些限制性要求来增加用户某些操作的难度，从而避免用户犯错。有几点方法，一是增加不可逆操作的难度，二是限制用户的某些操作。
第三点我们谈到“给予反馈和帮助”，这是对于用户一旦出错之后而言的，那么它包含的几点方法分别是：出错信息文字表达到位、出错信息友好，不威胁和责备用户、尝试减少用户的焦虑感和挫败感、及时反馈错误并提供建设性纠错帮助这样四点。
第四点我们提出“错误的恢复”，就是在用户出错之后应当如何恢复或者减少用户损失，包含两个方面，一是允许用户犯错，并使操作者能够撤销以前的指令；二是能帮助用户在发生错误后迅速回到正确状态。
五是我们讲的是“减轻用户负担”，也就是如何让用户能够自然的去使用产品，为用户减负，让用户少出错。我们从三个方面来讲，分别是记忆上、识别上和操作上，记忆上我们说应当尽可能减少用户记忆负担、识别上我们说应当在视觉上避免用户认知混淆，在操作上我们说应当减少不必要的操作步骤。这些方式都有助于减轻用户的负担，从而降低用户的出错率。
最后我们分享的是“容错性设计方法的应用关键”
用户场景模拟要求我们把自己作为用户，看看使用产品过程中会出现哪些问题和错误，最终明确用户使用场景不同对应的不同情况，容错设计是否实现了覆盖和满足。用户场景模拟的方法我们介绍了用例模型分析、故事板和人物角色模型。
用户行为观察要求我们观察用户使用产品的过程，来发现他们操作时的错误，获得发生这些错误的真实原因，进而指导错误反馈设计。这里谈到两个方面，一是注重用户真实声音的收集，二是对于用户实际操作的观察。
