需求不等于功能,或者说你最终设计出来的跟用户告诉你的他需要的“功能”一模一样的功能并不等于他真正想要的功能。
用户告诉福特,他需要一匹更快的马,最终福特给用户的是汽车。
用户告诉你,他需要一个公告板,他要用来展示自己的新产品、自己的新资质荣誉、自己的特价供应、…,你就给他一个公告板,允许展示图片、超链接、产品、视频的“公告板”?
用户告诉你,他需要一个可以收藏自己喜欢的商品、可以合并在一起付款的功能,你是给他一个购物车还是给他一个收藏夹还是同时给2个?
产品设计人员在产品规划的初期直奔功能和表象而去,把自己的思维限定在一个很狭小的范围之内,用户想要什么就给什么,最后只能被用户带到沟里。何 况,很多时候其实用户是不知道自己到底需要一个什么样的功能的。如果我们能试图去挖掘一下用户提出需要“XX功能”背后的需求来设计一下,把他提到的这个功 能进行延伸与扩展,给他一个全新的不一样的功能,反而会获得更好的效果。
我们可以把得到的需求可以分为三个主要类别:
1)最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法,会寻找各种途径进入最终产品。
2)有时人们口中说出来的、所期望的功能并不是一个很好的主意,但是它们代表了一条通向下一个版本的路径:用户实际想要的东西。用户的需求有时是行不通的或者治标不治本的,通过与用户探讨这些建议,有时可以得出真正解决问题的、完全不同的需求。
3)人们不知道他们是否需要的特性。
因为用户群体之间存在着很大的差异性,所以确认用户需求是复杂的。我们可以把大量的用户需求划分成几个可以管理的部分,这样通过用户细分来完成。把用户分成更小的群组,每一群用户都由具有某些共同关键性特征的用户所组成,可以通过人口统计学的标准来划分,也可以通过心理方面的数据来描述。
细分用户不仅仅因为不同的用户群有不同的需求,还是因为有时这些需求也是相互矛盾的。对新手用户而言他可能需要把一个系统分成若干简单的步骤,而相对于专家级用户而言这样的分解可能会妨碍他的快速操作。很明显的是,我们无法提供一种方案来同时满足这两种需求,此时,我们需要要么选择针对单一用户群设计,要么为执行相同任务的不同用户群提供不同的方案。
撰写需求的几个原则:1)乐观。描述这个系统将要做什么事情去“防止”不好的情况发生,而不是“不应该”做什么不好的事情。比如,“这个系统不允许用户购买没有风筝线的风筝”替换成“如果用户想买一个没有线的风筝的话,系统应该引导用户到风筝线页面”效果会更好。
2)具体。尽可能详细第解释清楚情况,这是决定一个需求是否被实现的最佳途径。
3)避免主观语气。需求必须可验证,就是说,它必须要能证明这个需求可以被满足。比如,“这个网站的风格应该是时尚、闪耀的”这样的需求是无法被验证的,我对于史上的定义也许并不符合你的,而Boss对时尚可能有完全不同的看法。
4)用量化的术语来定义需求。比如,“具备高级别的执行能力”可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。
搞清楚了“用户具体需要的是什么”、“企业需要得到什么”这样2个问题之后,我们才能配合着网站的运营开始把用户需求和网站目标转变成网站应该提供给用户什么样的内容与功能,进入到具体的功能设计层面。
本文来自:http://www.ikent.me/blog/1546#ixzz0HFXgvPCV&B
分享到:
相关推荐
系统的完整性指为完成业务需求和系统正常运行本身要求而必须具有的功能,这些功能往往是用户不能提出的,典型的功能包括联机帮助、数据管理、用户管理、软件发布管理和在线升级等。。。。。。。。。。。。。。
由于已有的模型不具备明显的解释功能, 所以将Web软件所特有的非功能需求属性添加进原有模型对其进行改进, 将原有模型中的12个子属性扩充为18个子属性, 进而利用问卷调查确定原有模型与改进模型中各属性的评价值, ...
经过提炼,将需求(资料的、功能的以及行为需求)模式化,最后得出一份需求报告。在这一过程中,系统开发者扮演的角色就是利用高度的沟通技巧、采取各种不同的形式,将潜在的需求发掘出来,将可能被误解的或是模糊不...
3.4. 不支持的功能 4. 数据描述 5. 性能需求(可选) 6. 运行需求(可选) 6.1. 用户界面 6.2. 硬件接口 6.3. 软件接口 6.4. 通信接口 7. 其它需求(可选) 8. 特殊需求(可选) 9. 不确定的问题(可选) 10. 编写...
急诊信息系统、卒中中心信息系统及创伤中心信息系统功能需求 13 急诊信息系统、卒中中心信息系统及创伤中心信息系统功能需求 急诊信息系统功能需求 急诊信息系统、卒中中心信息系统及创伤中心信息系统功能需求全文共...
比如项目要交付的时候,交互或需求不明确或者有歧义导致项目返工或延期,安全问题考虑不周导致生产环节被攻击者恶意攻击,没有考虑性能导致遇到高流量的时候就悲剧了等场景。今天的话题,我们就来聊聊《非功能性需求...
BBS论坛系统功能需求: 系统可大致分为以下流程:用户登录进入论坛(若为游客,有时还要注册为会员),就某个话题(帖字的主题)展开讨论。通过发贴功能发布新的话题;通过回帖功能回复已有的话题;通过搜索功能...
本书向您解释如何才能成功...功能性需求;非功能性需求;编写需求规格说明书;验收标准;质量关;原型和场景;重用需求;鉴定需求规格说明书;需求向何处去;附件A Volere需求过程模型;附件B Volere需求规格说明书模板
该文档首先给出了整个系统的整体网络结构和功能结构的概貌,试图从总体架构上给出整个系统的轮廓,然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。其中对功能需求的描述采用了UML的用例模型方式,...
珍藏的非标准不锈钢门制造业ERP功能需求。详细非标准不锈钢门制造行业的实际的ERP功能需求
该软件的具体功能需求以及各个功能需求的具体说明如下表所示: 软件功能需求表 功能名称 具体说明 用户注册 获取用户关键信息并进行汇总、分类。 稿件处理 收集稿件,审阅分类处理,并反馈具体信息 资料检索 提供...
由于时间比较短,使用计算机不方便以及对于网络变成不熟悉,因此本宿舍管理系统并没有提供数据的远程访问功能。对信息的保护手段仅限于设置用户级别,以及提供数据文件的备份,比较简单,安全性能有待进一步完善。 3...
在软件需求设计过程中,需求分析人员最容易忽略的部分就是非功能需求...非功能需求更加靠近的是技术,是设计,是实现,是架构师应当关注的内容,它是需求人员最不擅长的方面,这就是非功能需求为什么常常被忽略的重要原因。
需求获取不等同于“收集需求”,也不是简单地 将用户所说的全部记录下来。 获取是一个综合性协作和分析的过程,其活动 包括收集、发现、提炼和定义需求 获取的目的是为了发现业务需求、用户需求、 功能需求和非功能...
是为使用户、软件开发者及分析人员对该软件的初始规定有一个共同的理解,它说明了本产品的各项功能需求、性能需求和数据要求,明确标识各功能的实现过程,阐述实用背景及范围,提供客户解决问题或达到目标所需的条件...
原型并非是一个实际应用产品,但开发人员能将其转化、扩充成功能齐全的系统。 应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象,并尽量将分析进度提交给用户。在不进行直接指导的前提下,让...
1.3 什么情况将会导致好的群体发生不合格的需求说明 5 1.4 高质量的需求过程带来的好处 7 1.5 优秀需求具有的特性 7 1.5.1 需求说明的特征 7 1.5.2 需求规格说明的特点 8 1.6 需求的开发和管理 9 第2章 客户...
这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时,对于非功能性的需求例如性能、可用性等,亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考,看看其中...
目录 CATALOGUE 背景描述 态势分析法 宏观环境分析 用户访谈 USER INTERVIEW 竞品分析 COMPETITORS ANALYSIS 选题背景 BACK GROUND 需求功能提炼 DEMAND FUNCTION 用户体验旅程地图 痛点分析与功能转化 特色功能...
这份软件需求说明书重点描述了Saas小区物业管理系统的功能需求,明确所要开发的软件应具有的功能、性能与界面,使系统分析人员及软件开发人员能清楚地了解用户的需求。 1.2Scope范围 该文档是从用户角度出发来导出...