UnCD-以用户需求为中心的设计-newTemp.ppt

若还有时间，给每个组5-10分钟讨论，2分钟演讲分享收获。+5分 会后，我会将ppt发给大家，这个片子，主要是站在用户体验的角度来讲述需求采集、分析，有些细节讲的不够深入。我有另一个片子，是从软件工程的角度来讲述需求分析的相关技术，更加深入和全面，会后一起发给大家，大家可以对比来看。 * * 用户研究，是近年流行起来的一项技术。这里给大家推荐一本书，全书讲了各种用户研究的方法创建Persona，然后加以应用，目的就是在设计产品的过程中时刻不忘用户，做到以用户为中心。 这里我截取了书中一张关于用户研究方法的二维图，非常清晰的描述了用户研究的几种常用方法。 说与做：用户怎么说，表现的是目标和观点，怎么做反映了行为。用户说的和做的经常是不一致的。我们应该。。。虽然他会所的不一定是真话 定性与定量：定性研究可以找出原因，偏向于了解，定量研究可以发现现象，偏向于证实。缺一不可。只定量会以标带本，看到问题单不知道原因，只定性会以偏概全，很可能被少量的特殊样本误导思维。螺旋上升 坚决杜绝“经组织研究决定，用户需要一个xxx功能” * 实际工作中，到底采用哪种用户研究方法，往往取决于资源。 需求采集 * 说和做、定性与定量，合理的搭配组合使用，才能发挥最大的作用，而对于一个产品来说，正好在不同的时期可以用不同的方法，下面举一个典型的例子，正好是用到了上述4种办法，按照时间顺序，“自上而下，从左到右”在图里画出一个大写的“Z”： 第一轮，产品规划阶段。听用户定性地说，确定产品方向，做什么？随机抽样了40个用户做访谈，据此写出需求列表。 第二轮，某个项目的早期。听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。 第三轮，项目实施过程中。看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续的找了10个用户来验证，做可用性测试。 第四轮，上线后的优化阶段。看用户定量地做，根据产品的用户使用情况做数据分析，不断地改进产品。 具体怎么做，去看其他材料把。当然，这是一个比较重要的产品，所以在用户研究上投入了较多的时间与人力，更多的时候，我们会视情况采取简化的方案。 * 用户倒不是故意欺骗我们，而可能是，他们被问了自己也没有仔细想过的问题，又不想回答不知道，就在现场编了一个看似有理有据的理由， * * 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。 ? 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。 ? 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。 ? 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。 ? 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。 用户大会：成本高，机会不多，但效率非常高。会前应充分准备，会后应认真整理、分析、总结 * 尽可能覆盖目标群体中各种类型的用户，比如性别、年龄段、行业、收入等，要保证各种类型用户的样本比例接近全体的比例，比如目标用户中男女比例为7：3，那么我们的样本也应该保持这个比例 样本量过少时，采用百分比来分析是没有意义的。这是很多新人会犯的错误，比如只问了5 个人，3 个人选A，就在报告中说有60%的用户选A，这是很不严谨的。因为如果换5 个人再做一次，很可能就是40%了，而这样的数字百分比要具备稳定性才有价值 * * 可用性测试在产品的各个阶段都可以做：无任何成型的产品、只有纸面原型、只有页面Demo、产品已经可以运行 只做一个用户，并且简化步骤，也比不做要好。 测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。告诉用户“来试用一下我们的新产品，提点意见”。 * 千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。 尽快总结，并且发给用户，一方面让用户感到他做了一件有意义的事，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最 重要的，这份总结要用于指导产品改进，这才是可用性测试的根本目的。 * 上述3 种方法，就算做问卷的普查，回收到的有效问卷也可能不到用户总数的10% 数据分析时，根据不同的目的，数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。数据分析的方法，最简单的可以用