怎么做有效的用户调研和需求分析？

1. 怎么做有效的用户调研和需求分析？

用户调研和用户需求分析是做APP产品要做的重要准备，注册下载放单平台小编认为那么用户调研和用户需求分析有哪些方法呢?本片文章就来探测一下腾讯内部用户调研和需求分析有哪些方法。
读完本文你可以得到这些问题的答案：
1.腾讯认识用户的方法论三步曲是什么?
2.乔布斯为什么需要1秒钟变小白?
3.张小龙如何找到微信深入人心的功能?
互联网产品和服务大多以虚拟形式存在于网络上，很多时候用户自己也不清楚想要的是什么。只有在面对产品和服务的具体使用场景时，通过具象的使用和体验，才会对产品给出基于个人使用过程的相关评价。
所以互联网产品要取得成功会比传统产品更加困难，互联网产品要求企业把“了解用户需求”当成是一项自始至终、至关重要的理念秉承下去。
“腾讯以产品见长”，这是中国企业界的共识。
要做好产品，首要的是以用户需求为驱动，以用户价值为依归。
如何更了解用户是打造一个好产品的关键。
最近出版的畅销书《腾讯之道：我们应该向腾讯学什么?》在产品维度就深刻解读了腾讯是如何去了解用户的，是如何做到比用户更懂用户的。它把腾讯认识用户的方法论总结为三步曲：成为用户，懂得用户，超越用户。
一、成为用户
“成为用户”是互联网企业想要取得成功的大道至简的秘籍，最简单、最直接的方式就是天天使用自己的产品。安卓刷下载量

只是，很少有团队能够日复一日地真正做到位。
因为大多数产品经理更沉醉于如何把产品按照自己的想象做出来，把自己的意愿强加在用户身上，陷入了“我认为用户需要……”的黑洞，从而不自觉地忽视了用户看待这个产品的真实态度，最终导致产品的失败。
就像在2015年年末，广受全国网友吐槽的12306网站“验证码门”。追究其原因，就在于产品团队没有让自己成为用户，无法真正了解用户的诉求所致。
这个案例中，产品经理单纯地站在自己的角度看待产品，把屏蔽自动化入侵和非法用户的目的放在首位，采取自认为严谨简单，还有点“幽默”的方式对产品进行设定。
但实际上，用户在使用这项产品时，最希望得到的是简单而快捷的服务：能够顺利购买到指定的车票顺利回家。这是购票者在使用网站场景下，异常严肃和重要的事情。
如果仅需要输入传统的数字验证码，用户还勉强能够接受。如果太过于复杂，且很难通过验证时，就会变为是痛苦的体验。购买车票的预期和产品使用的难度形成巨大的心理反差，让用户的负面评价迅速发酵，并快速形成无法挽回的产品口碑和用户认知。
优秀的产品经理应该忘掉自己产品经理的身份，把自己变身为产品的普通用户。
通过频繁地使用来发现产品存在的问题，找出广大用户对产品的痛点，从而优化产品，使其满足普通用户最朴素的心理诉求。
优秀的产品经理会不断审视自己的内心初衷，不断回答并告诫自己，是为谁在做产品?为用户，还是为自己。
二、懂得用户
“成为用户”只是互联网经理走向成功的第一步，但如果无法真正迈出“懂得用户”这一步，就永远只能止步于“优秀”之外，难再成功寸步。

2. 如何进行用户需求调研？

　　把握用户需求，才能做出用户真正喜欢的网站。如果不考虑用户需求，网站的页面设计得再漂亮，功能再强大，也只能作为摆设，无法吸引到用户，更谈不上将网站用户变为你的客户。
　　1、用户类型划分
　　对用户需求的分析，首先要考虑的，就是用户类型。
　　网站是面对国外客户，还是国内客户？
　　网站是面对经销商，还是面对终端客户？
　　网站是面对家庭购买者，还是面对个人消费者？
　　网站是服务老客户为主，还是吸引新客户？

　　……

　　面对不同的用户类型，网站需要满足的用户需求也不同。

　　2、用户需求分析

　　确定好用户类型之后，接下来就是研究用户所关注的内容了。怎样确定用户关注哪些内容呢，除了向企业的销售人员调研，也可以做一个简单的“角色互换”思考，如果你是用户，那么你会从哪些方面来考察企业呢？如果你是用户，你会希望看到怎样的网站？

　　1）用户的明确需求

　　如产品的展示、公司的介绍、服务介绍等等，这些是属于用户最基础的需求，一般的企业网站都会有，但是不同网站之间的差别在于细节，比如产品应如何展示才更美观？公司介绍要怎样写才能突出企业优势呢？只有将细节做好，才能打动用户。

　　2）用户的潜在需求

　　除了满足用户的基础需求，网站策划者还要深入挖掘用户的潜在需求。比如，一种复杂的技术型产品，用户很可能需要及时的“技术咨询”以帮助了解；而一款家庭清洁的日化产品，如果网站有“家庭清洁常识”的介绍，相信会比单纯的产品介绍更吸引用户。

　　从“ 网络调研 ”到“ 网站诊断”，再到“用户需求分析”，网站策划者完成了网站规划前必要的准备工作，而接下来，才真正到了考验网站策划者功力时候了

3. 如何进行用户需求分析

1.概念
需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.
对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.
近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文档在开发过程中一直起指导作用.
3.需求分析过程
可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:
图4-1 需求工程域的层次分解示意图
需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:
确定产品所期望的用户类别.
获取每个用户类的需求.
了解实际用户任务和目标以及这些任务所支持的业务需求.
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.
将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.
了解相关质量属性的重要性.
商讨实施优先级的划分.
将所收集的用户需求编写成文档和模型.
评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.
需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:
定义需求基线(迅速制定需求文档的主体).
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.
以一种可控制的方式将需求变更融入到项目中.
使当前的项目计划与需求一致.
估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.
在整个项目过程中跟踪需求状态及其变更情况.
以上几点说明是我总结了成功实施项目后系统分析人员的经验,同时也根据国内外的其他系统实施的相关成功经验,进行了总结.
4.需求的类型
下面这些定义是需求工程领域中常见术语的定义.
软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求).
1.业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.
2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明.
3.功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.
在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为.软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用.对一个大型系统来说,软件功能需求也许只是系统需求的一个子集,因为另外一些可能属于子系统(或软件部件).
作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.
下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是:"用户能有效地纠正文档中的拼写错误",该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词".同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换.
从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系,它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的.
5.需求分析的原则
不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的"成功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.
不适当的需求过程所引起的一些风险:
1. 无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程.
系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.
2. 用户需求的不断增加
在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改.
要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中.
产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降.
3. 模棱两可的需求
模棱两可是需求规格说明中最为可怕的问题.它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明.
模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员为错误问题而浪费时间,并且使测试者与开发者所期望的不一致.一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不重写许多测试用例并重做许多测试.
处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍.仅仅简单浏览一下需求文档是不能解决模棱两可问题的.如果不同的评审者从不同的角度对需求说明给予解释,但每个评审人员都真正了解需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大.
4. 不必要的特性
"画蛇添足"是指开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能.经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力"白搭"了.开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而不要未经客户同意,擅自脱离客户要求,自作主张.
同样,客户有时也可能要求一些看上去很"酷",但缺乏实用价值的功能,而实现这些功能只能徒耗时间和成本.为了将"画蛇添足"的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的"来龙去脉",这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能.
5. 过于精简的规格说明
有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,仅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明.这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况.但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品).
6. 忽略了用户分类
大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感到失望.例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难.
7. 不准确的计划
据统计,导致需求过程中软件成本估计极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析.
对不准确的要求所提问题的正确响应是"等我真正明白你的需求时,我就会来告诉你".基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右.要作出估计时,最好还是给出一个范围.未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺.因此我们要尽力给出可达到的目标并坚持完成它.
6.需求分析人员和用户的合作关系
优秀的软件产品是建立在优秀的需求基础之上的.而高质量的需求来源于客户与开发人员之间有效的交流与合作.通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系.双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处.
只有当双方参与者都明白要成功自己需要什么,同时也应知道要成功合作方需要什么时,才能建立起一种合作关系.由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘.其实大家都想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品.
软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求.每一项权利都对应着软件开发人员、分析人员的义务.而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务.如果愿意,可以将其作为开发人员的权利书.
客户有如下权利:
1:要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语.
2:要求分析人员了解客户的业务及目标
通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要.这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件.为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的.如果新开发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处.
3:要求分析人员编写软件需求规格说明
分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息.通过这些分析就能得到一份软件需求规格说明.而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议.软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写.要评审编写出的规格说明以确保它们准确而完整地表达了你的需求.一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品.
4:要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性软件需求规格说明的补充.因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面.所以需求说明中的各种图表有着极高的价值.虽然它们不太难于理解,但是你很可能对此并不熟悉.因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等.
5:要求开发人员尊重你的意见
如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家"兼听则明".参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间.同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激.
6:要求开发人员对需求及产品实施提供建议,拿出主意
通常,客户所说的"需求"已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还应找出已有系统不适合当前业务之处,以确保产品不会无效或低效.在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法.有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性.
7:描述产品易使用的特性
你可以要求分析人员在实现功能需求的同时还要注重软件的易用性.因为这些易用特性或质量属性能使你更准确、高效地完成任务.例如,客户有时要求产品要"用户友好"或"健壮"或"高效率",但这对于开发人员来说,太主观了并无实用价值.正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性.
8:调整需求,允许重用已有的软件组件
需求通常要有一定的灵活性.分析人员可能发现已有的某个软件组件与你描述的需求很相符.在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件.如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发.所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了.
9:获得满足客户功能和质量要求的系统
每个人都希望项目获得成功.但这不仅要求你要清晰地告知开发人员关于系统"做什么"所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制.一定要明确说明你的假设和潜在的期望.否则,开发人员开发出的产品很可能无法让你满意.
客户有下列义务:
1:给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语.但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标.不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的"常识".
2:抽出时间清楚地说明并完善需求
客户很忙,经常在最忙的时候还得参与需求开发.但无论如何,你有义务抽出时间参与"头脑风暴"会议的讨论,接受采访或其它获取需求的活动.有时分析人员可能先以为明白了你的观点,而过后发现还需要你的讲解.这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这对软件产品的成功极为重要.
3:准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的.由于处理细节问题不但烦人而且又耗时,故很容易留下模糊不清的需求.但是,在开发过程中,必须得解决这种模糊性和不准确性.而你恰是为解决这些问题作出决定的最佳人选.不然的话,你就只好靠开发人员去正确猜测了.在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写"DQD:待确定")的标志是个不错的办法.用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方.不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志.尽量将每项需求的内容都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中.如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程.通常使用所谓的原型技术.通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义.
4:及时地作出决定
正如一位建筑师为你修建房屋,分析人员将要求你做出一些选择和决定.这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等.有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定.因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展.
5:尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测).你所希望的某些产品特性可能在技术上行不通,或者实现它要付出极为高昂的代价.而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见.有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,要求某个行为在"瞬间"发生是不可行的,但换种更具体的时间需求说法("在50ms以内",但若没有准确的技术分析不能轻易下结论),这就可以实现了.
6: 划分需求优先级别
大多数项目没有足够的时间或资源来实现功能性的每个细节.决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要部分.只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级.开发者将为你确定优先级提供有关每个需求的花费和风险的信息.当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果.在时间和资源限制下,关于所需特性能否完成或完成多少应该尊重开发人员的意见.尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的.业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷.
7:评审需求文档和原型
正如我们将在第1 4章讨论的,无论是正式的还是非正式的方式,对需求文档进行评审都会对软件质量提高有所帮助.让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性.评审也给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作.如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人员并为改进提供建议.通过阅读需求规格说明,很难想象实际的软件是什么样子的.更好的方法是先为产品开发一个原型.这样你就能提供更有价值的反馈信息给开发人员,帮助他们更好地理解你的需求.必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系统.
8:需求出现变更要马上联系
不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响.变更是不可避免的,但在开发周期中变更越在晚期出现,其影响越大.变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时.所以一旦你发现需要变更需求时,请一定立即通知分析人员.
9:应遵照开发组织处理需求变更的过程
为了将变更带来的负面影响减少到最低限度,所有的参与者必须遵照项目的变更控制过程.这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些变更引入项目中.
10:尊重开发人员采用的需求工程过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性.分析人员采用的方法有其合理性.也许你认为需求过程不太划算,但请相信花在需求开发上的时间是"很有价值"的.如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利.尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动.
系统分析人员在开发过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品.故一定要确保需求开发中的主要参与者都了解并接受他们的义务.如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦.
7.需求文档
需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的.
你可以使用以下三种方法编写软件需求规格说明:
用好的结构化和自然语言编写文本型文档.
建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.
编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.
由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.

4. 用户需求分析的介绍

用户需求分析指在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。

5. 用户需求分析的基本信息

 当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational的Rose工具进行需求的建模分析。如果使用工具进行建模分析，对需求分析人员的要求比较高。需求定义过程中通常会出现的问题有内容失实、遗漏、含糊不清和前后描述不一致。当完成需求的定义及分析后，需要将此过程书面化，要遵循既定的规范将需求形成书面的文档，我们通常称之为《需求分析说明书》。邀请同行专家和用户（包括客户和最终用户）一起评审《需求规格说明书》，尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。需求评审之后，开发方和客户方的责任人对《需求规格说明书》作书面承诺。具体的同行评审详见需求评审章节。 需求状态（Establish Requirement State），顾名思义，状态也就是一种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。为什么要建立需求状态？在整个生命周期中，存在着几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，(1:突出产品的特点优势为你网站埋下购买欲一类是客户可以明确且清楚的提出的需求（经常使用的知道对自己有什么作用的、要什么样的产品） 。对产品的名称、价格、功能、款式、作用、使用效果非常的清楚、明确的知道自己想要什么的客户、然后提出的具体购买需求。（如果我们网站面向这类人需要网站介绍你产品的价格、功能、款式优势和让他看到你产品的绝对亮点和优势能够提升他们工作中的某种技能效率这方面的内容）(2:明确产品使用方向让客户能在你网站上找到明灯另一类是客户对产品有过一定的了解、但对产品的业务和作用不是很明确，还需要等待外部信息。（看到过使用过但不知道有什么作用）。知道这件产品怎么做，但不知道这件产品能给自己带来什么样的优势、能体现出什么样的能力、能提高什么样的效率（这类人需要我们网站提供专家的指导或业务员的对产品的详细介绍、给他一个明确的方向和答案的内容）(3:深入提供潜在需求内容、提高网站转发率一类是客户知道需要做些什么但又不能确定的求。（客户经常看到但没有使用过、不知道具体操作和对自己有什么作用）。客户知道这件产品的名称和作用、做好这件事需要什么产品或工具来完成 ，但不知道怎么使用、不能确定那件产品能给他带更好的效率或要什么其他的产品来搭配使用才能达到想要的效果 （这类客户只需要网站提供简单易懂的产品介绍和产品的操作流程内容、什么样的产品能够做什么样的事能达到什么样的结果和效率）(4:还原产品现场、让客户清晰购买思路还有是客户本身也说不清楚的产品、但知道对自己有用。（听说过这件产品知道自己这件产品能帮助自己完成某些事情）。说不出来是什么产品或不知道产品名称、对产品非常模糊的、不知道产品具体该怎么样去操作（首先要提供解决你产品是不是对他有用的资料、然后你要详细而又全面的介绍你的产品、主要要解决这个客户对这个产品的疑虑和作用、能够解决它现在什么样的现实问题）对于这些需求，在开发进展的过程中，存在着以下几种情况：有可能要取消的；有的因为不明确而可以后延的，同时可能转化为被取消的需求；与客户经过沟通或确认的，此处有两种情况，一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。下面是一个简单的状态例子：CLOSED：经过确认，双方认可并达成共识；OPEN：双方确认，但没有达成共识的需求；待定：客户提出需求，但双方没有经过沟通或确认； （网站需求、财富需求、品牌需求、社会需求、自我需求、）　网站需求基本需求：获取所有的资源，该资源是这个网站独有的或者是独具特色的社会需求：于更多人交流，获取更多资源，自身所需的信息能得到解答尊重的需求：为所交流的人所承认，能获取认知及荣誉自问实现价值：自身品牌得以建立，能获取更大的利益财富需求生理需求、安全需求、社会需求、尊重需求、自我实现品牌需求功能性品牌、规模型品牌、技术性品牌、情感性品牌、精神型品牌社会型需求社会需求生理需求：本能层次的需求，包括食欲、睡眠、欲望等需求安全需求：避免对生命构成威胁的需求社会需求：社会需求，于他人交流相关的需求变得更重要尊重需求：想被他人承认的需求自我实现需求：对理想的实现的需求也称成长需求SEO自我需求分析生理需求、安全需求、归属和爱的需求、尊重需求、自我实现需求

6. 用户需求与研究

就像任何 UI 决策一样，UX 副本也应该依赖于有价值且相关的用户研究结果。无论文案如何对话和直截了当，如果它凭空出现并且不能满足观众的需求，那是没有意义的。
  
 更重要的是，在单词选择方面，用户研究结果可以帮助用户体验作者在与利益相关者、营销团队和其他团队成员的讨论中证明他们的选择是正确的。
  
 好消息是你不需要应用所有的 UX 研究方法和技术来使你的 UX 副本完美。根据您的预算、时间限制和其他宝贵资源选择 1-2 种工具，并根据您的业务目标、产品领域和用户偏好进行调整。
  
 
  
  
 
  
                                          
 1943 年，美国心理学家亚伯拉罕马斯洛发表 了《人类动机理论》 ，提出了人类需求的心理层次结构。他建议，当人们的需求按此顺序得到满足时，他们会更有动力去执行某项行动。
  
 根据马斯洛的层次结构，人类的需求有5个层次：
  
  1.生理需求  是最基本的需求，包括食物、饮料、住所、呼吸、性、舒适和睡眠。
  
  2.安全需求  包括财务和人身安全、社会稳定、健康、治安、情感安全等。
  
  3.社会需求  是指人类对归属感、拥有朋友、爱、亲密关系、家庭、社区和人际关系的需求。
  
  4.尊重需要  基于与社会地位、成就、掌握、声望、成就和其他人的尊重相关的认可感。
  
  5.自我实现需求  占据马斯洛层次结构的顶端，与一个人的潜力、自我实现、个人成长和经验的实现有关。
  
 不管马斯洛的理论受到怎样的批评，它证明了我们的需要和欲望决定了我们的行为。马斯洛还指出，人们更倾向于在满足更高级的需求之前满足他们的基本需求。
  
 这与用户体验写作有何关系？它继续说，您应该首先尝试满足用户的需求。需要先于需要。值得注意的是，两者之间有一条细线——需求指的是  必须  完成的事情。欲望只是我们想做某事或拥有某物的愿望。
  
 写作时，始终质疑每一行：文案是否符合心理等级的任何层次？例如，“今天的课”这句话要求我们愿意学习，但它缺乏足够的动力。一个很好的例子是 Duolingo 的短语，“完成一堂课以加入本周的排行榜”，它吸引了人类对成就、他人尊重和自我成长的需求。
  
 
  
  
 
  
                                          
 归根结底，UX 编写者和设计师不是用户，也不能 100% 确信他们的设计和文案是完全直观和直接的。您可以穿着用户的鞋子走一英里，但仍然对技术措辞和商业术语视而不见，忘记了用户不熟悉这些术语。经济学家 Colin Camerer、George Loewenstein 和 Martin Weber 创造了“知识的诅咒*”* 来描述这一现象。简单来说，就是你周围的所有人（包括你的用户）都有背景知识来理解你的意思的认知偏差。
  
 语言是一个主观的话题，与产品所有者和利益相关者讨论单词选择可能不是一件容易的事。UX编写者需要有价值的 用户研究 来证明他们是对还是错。有几种研究方法和工具可以帮助您使您的 UX 写作完美并与您的受众的心态兼容。调查是获取有关用户的有价值信息的一种廉价、快速且简单的方法。
  
 通过一个很好的问题列表，您可以接近目标用户群并获得诚实的意见和深入的见解。调查为您提供了一个绝佳的机会来查看您的受众在谈论您的产品和领域时使用的实际词语。
  
 为调查选择一个主题或痛点，以获得更相关和更有意义的见解。
  
 
  
  
 
  
                                          
 确保你的话有意义的最容易理解和最简单的方法之一是检查它 谷歌趋势. 让我们想象一个非常常见的场景，其中 UX 编写者不确定一个词或有几个变体并且不知道哪个是最好的。谷歌趋势可能是解决困境的好方法。您只需输入您拥有的术语，用逗号分隔它们，Google 趋势将比较每个术语在 Google 搜索引擎上的搜索请求的频率。
  
 然而，谷歌趋势并不是灵丹妙药。它可以为您提供每个地区或国家/地区最常用的词，但无法评估您的目标受众的偏好。例如，“分享”一词可能更受欢迎，但“告诉你的朋友”这句话可能更适合您品牌的声音，并且可能对寻求社会认可的用户更具吸引力。
  
 请注意：最常搜索的词可能与您的产品上下文无关。
  
 
  
  
 
  
                                          
 了解你的竞争对手总是好的，尤其是他们的优势和痛点。 竞争对手分析 是用户体验研究的最早阶段之一，它提供对竞争对手使用方法的定性（有时是定量）洞察力，您可以战略性地将其应用于自己的产品。
  
 从用户体验写作的角度来看，您可以观察他们的术语以及复制和内容解决方案。提醒一句——你不知道你的竞争对手，即使他们提供了最成功的产品，是否已经测试过这些复制创意。此外，他们的受众可能不同，您的品牌可能传达不同的价值观并承载不同的情绪。这意味着对他们有用的东西不一定对你有用。
  
 以下是进行有效竞争对手分析的一些建议：
  
  • 分析 3-5 家竞品公司 
  
 这个数字通常足以获得有价值的见解，而不会迷失在众多内容解决方案中。
  
  •不要盲目复制他们的解决方案 
  
 相反，请使用他们的文案解决方案作为灵感，为您的产品找到独特的东西。
  
  • 创建比较标准列表 
  
 它可以是一个简单的电子表格，其中包含比较标准列表（例如，说明副本、注册/登录页面、错误页面、菜单和按钮等），您可以在其中分析语气和语音、可读性、主动/被动语态的使用、句子结构和其他基本问题。不要忘记将您自己的产品包括在列表中，以了解它如何与其他公司竞争。
  
  • 不仅包括直接竞争对手 
  
 还要考虑用户体验不太成功的竞争对手。它将为您提供更广泛的市场概览，并教您在产品中避免使用哪种 UX 副本
  
 
  
  
 
  
                                          
 当您觉得有人支持它时，与数字产品互动会更加愉快。独特而真实的 声音和语气 是使您的产品听起来人性化并与用户建立联系的完美工具。
  
 那么如何找到自己的品牌声音呢？是什么让它如此独特和吸引观众？
  
 1.您的第一步是从完全不同的领域调查您最喜欢的产品和品牌。他们使用什么语言？他们如何表达悲伤、快乐、惊讶和赞美？他们听起来像教授还是朋友？他们让你开怀大笑吗？他们如何通过副本吸引您的注意力？每当你发现一个有趣的 UX 副本时，制作屏幕截图，其中产品的副本从舌头上滚下来，感觉非常自然。
  
 2.一旦你看到了其他产品与用户交互的所有利弊，下一步就是搜索你自己的声音。您如何看待您的产品？你希望你的观众如何看到你的产品？他们用什么形容词来形容它？它是更有趣、更随意还是更规范、更直接？您希望用户在与应用程序或网站交互以及完成任务时会有什么情绪？您的用户会喜欢讽刺的笑话还是更倾向于富有同情心的语气？
  
 3.继续测试和学习。不可能一夜之间改变你的产品的声音并让每个人都喜欢它。这需要时间和调查。当您从用户那里获得反馈时，评估您的文案创意并随着时间的推移调整声音和语气。
  
 
  
  
 
  
                                          
  社交媒体 已成为人们表达挫折、失望和困惑的绝佳渠道。论坛、呼叫中心查询、App Store 和 Google Play 上的评论以及社交媒体上产品页面上的评论是获得有关功能的诚实反馈的金矿。 更重要的是，用户体验编写者可以通过这种对话研究 了解用户在谈论产品时使用的词汇和术语。
  
 与面对面采访相比，用户表现得更加自信，并且在社交媒体上分享他们的想法，甚至是关于非常私人的话题时，他们感觉更安全。例如，Flo 应用程序有秘密聊天，女性可以在其中与社区成员匿名讨论生殖问题、性、营养、健康、月经周期和相关问题。
  
 提醒一句——总是用其他方法支持对话研究的结果。您应该调查用户的投诉是否只是少数用户遇到的问题，或者是否值得研究。在您 100% 确定之前不要更改副本。
  
 随着越来越多的人开始在线工作和交流，社交媒体正成为一种越来越有价值的用户体验研究方法。
  
 
  
  
 
  
                                          
 有时， 对用户在自然栖息地的 观察  可以为用户体验研究人员提供最有价值和最准确的发现。要进行 观察性研究 ，您和您的团队应该首先考虑您的用户生活、娱乐或工作的最常见的地方。它可以是咖啡店、艺术画廊、购物中心或学生宿舍，在那里你有一个独特的机会来观察人们做什么（和不做什么）并听他们说什么（不说什么） .
  
 观察性用户研究包括两个主要活动：观察和访谈。虽然采访也可以提供出色的见解（例如，关于用户的词汇），但它可能不准确且不可靠。人们并不总是按照他们所说的那样行事或思考。将观察作为一个有意识的过程，需要关注有助于找到特定问题答案的事物。
  
 观察通常发生在参与者的自然栖息地，有时也发生在测试地点，如实验室。有时，主持人会观察人们执行一项任务，并在此过程中询问他们在做什么以及他们的想法。在其他类型的观察中，研究人员在不打断参与者的情况下进行观察并做笔记。
  
 观察用户体验写作的好处是，您可以看到用户在哪里绊倒、感到困惑、微笑或浏览文本。它有很大的潜力指出可以修改副本的地方。
  
 
  
  
 
  
                                          
  用户访谈 是最流行 的用户研究定性方法之一 。尽管我们不能完全依赖用户所说的话，但用户访谈仍然可以提供有关用户动机、需求和行为的重要见解和定性数据。
  
 用户体验研究人员进行有效用户访谈的主要建议是什么？
  
  • 选择代表您的听众的 3-5 名参与者 
  
 与定量用户研究方法（例如调查）相比，用户访谈不需要大量的人。你可以采访大约 3-5 个人，以了解他们的行为、动机和观点。
  
  • 定义你的目标 
  
 研究目标应该反映用户访谈的目的。你想回答什么问题？用户访谈如何帮助您获得洞察力？定义目标应该先于方法的选择。甚至可能会发现用户访谈不是实现您目标的正确方法。
  
  • 准备面试指南 
  
 这不是您应该逐步遵循的脚本，而是指导您完成面试的建议列表。确保这也符合您的目标。
  
  • 处理面试问题 
  
 深思熟虑的开放式面试问题是用户面试的关键组成部分。他们应该帮助你达到你的研究目标，而不是操纵受访者重复预先设定的假设。
  
 从用户体验写作的角度来看，用户访谈教研究人员使用用户语言，展示他们对品牌声音和语气的理解，并指出阻碍用户前进和完成任务的障碍（模棱两可的词选择或令人困惑的技术术语）。

7. 用户需求分析方法

客户的需求是我们销售行为的关键，但是客户不会每次都会毫无保留的告诉你，所以我们要通过行业分析，客户需求分析，了解客户需求，解决问题。


一、分析竞争对手

想要了解客户需求，就要先了解市场发展及我们的竞争对手。中国自古就有一句古话：知己知彼百战百胜，销售更应牢记这句话，因为只有你足够了解你的竞争对手，才能做出应对。了解竞争对手，不仅要了解竞争对手的价格、特征，还要了解有哪些长处、不足、销量及销售形式等，我们只有足够透彻的了解竞争对手，才能在市场掌握主动权，同时也能从另一方面了解到市场需求。


二、客户特点及习惯

一方面要了解客户的兴趣爱好，消费习惯等，另一方面要从销售本身出发，了解客户的内心，一般客户都比较重视产品质量和售后服务，我们只需要把握好这两点往往销售会比较容易成功。

三、客户的真实需求

要想了解客户的真实需求需要寻找客户需求、仔细发现、等待客户需求呈现、确认客户需求、最后成交。了解客户需求是成交的必要条件。


四、满足客户

要学会维护客户自尊，沟通过程中多用：有什么我可以帮您的吗？您的事我一直放在心上，会尽快给您处理的；您好有眼光等等。可以让对方感觉到受到了尊重和重视，同时客户也会感觉有良好的消费体验。

细心聆听客户心声，沟通过程中多用：您的意思是......对吗？原来是这样；我知道您的感受或心情等。要认真听客户讲的话，体会对方感受，并及时给予回应，说出自己的想法。

8. 什么是用户需求分析?为什么要做用户需求分析?

用户需求分析是指在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。
例如采用Rational的Rose工具进行需求的建模分析。如果使用工具进行建模分析，对需求分析人员的要求比较高。需求定义过程中通常会出现的问题有内容失实、遗漏、含糊不清和前后描述不一致。
需求状态（Establish Requirement State），顾名思义，状态也就是一种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。
为什么要建立需求状态？在整个生命周期中，存在着几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，
对于这些需求，在开发进展的过程中，存在着以下几种情况：
有可能要取消的；
有的因为不明确而可以后延的，同时可能转化为被取消的需求；
与客户经过沟通或确认的，此处有两种情况，一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。