产品经理如何定义需求与界面的关系

需求

对于一些产品经理或设计师新人,常常会犯一个毛病“接到需求之后就开始尝试做原型,画界面。卤煮也曾为自己可以迅速通过交互原型和界面表达产品需求而沾沾自喜,那时候还只是产品立项工作阶段,现在想想觉得十分鲁莽,还好导师的及时纠正。

其实从需求到界面(原型),中间隔着一扇门。直接穿过以为是捷径,殊不知容易当头一棒。耐心打开这扇门,才能见得真面目,这扇门就是产品信息的组织和任务的设定。

信息分类

信息分类与组织是一个产品的基础,符合现实场景使用逻辑,满足商业需求将广告和有效信息合理编排,才能给以用户流畅清晰的体验。

常见的分类方法有:

①逻辑分类:将对象按照一定的现实逻辑进行分类组织。例如,在生活中,要买一个洗衣机,在百货商城中依次找到家电卖场→大家电类→洗衣机品类→(品牌、容量、是否智能、缸数等)。相应地,一个电子商务网站的信息组织形式类似设计。

②卡片分类:具体操作是邀请用户“把类似的东西放在一起”(把标有产品元素的标签提供志愿者进行阅读理解并分类),这种方法在产品设计的初级阶段可以容易获取用户对产品内容的期望,为信息架构的搭建提供依据。对现有产品迭代改良时,卡片分类还可以检验架构的合理性。

卡片分类还可以具体分为:

开放式:(用户完全自行确定分类的组数和卡片数),优势在于提供更加丰富的分类结果,但也容易造成结果不可控。

封闭式:先将导航架构设计好,再由用户分别归类卡片,结构有限可控,一般是对信息设计的结果进行验证之用。

导航设计

完成正确的信息分类之后,下一步开始导航设计。

①导航的自我解释:虚拟的互联网世界没有现实世界中明显的方向感,不清晰的导航往往导致用户流失。一个好的导航设计最基本的任务就是要让用户知道“我从哪里来?”“我现在在哪里”“我能去哪里”。下图是在京东商城上搜索购买洗衣机的面包屑元素。

注:面包屑通常水平地出现在页面顶部,一般会位于标题或页头的下方。它们提供给用户返回之前任何一个页面的链接(这些链接也是能到达当前页面的路径),在层级架构中通常是这个页面的父级页面。

②深广度平衡:在导航的信息组织中,层级的数目一般称为导航的深度,每一层级中包含的菜单项数可以称为导航的广度。在导航设计中,需要兼顾深广度的数量,保证用户的浏览路径足够便捷(选择少,跳转少,简单明了)。

过度追求少层级或者浅层级。对于导航设计没有严格意义上的多或者少,需要结合产品本身的设计来规划,当然也要考虑平台特性。尤其是PC端移植到移动端的产品,往往有“庞大”结构,这时候需要做“减法”,针对新平台的用户使用习惯,重新调整导航设计,凸出更核心的业务,精简聚合。

想起前不久深圳PM大会上鹅厂前辈分享QQ的年轻化之路,有谈到新版手Q底部导航浓缩成3个tab的改进。在4tab当道5tab拉风的时代,敢推出3tab的设计,并且获得用户的认可,这少不了优秀导航设计的功劳。

平衡商业需求

设计除了考虑用户的信息需求,还要了解产品背后的商业目的。保证用户体验的时候,别忘了是谁给你发工资的呢。

先看看亚马逊广告的植入方式:

在二级品类导航页中植入相关广告,比起某些站点密密麻麻全屏+各种浮窗广告的设计,会不会小清新一些。

广告植入贴近用户当前搜寻的需求,不强行妨碍用户操作。

设置快捷入口

除了有完整且有逻辑性的导航供用户一步一步体验产品,往往还需要为重要功能或者常用功能提供快捷入口,一步到位,减少重复操作的繁琐。

例如:逻辑上看购物车属于我的淘宝,但是因为其属于常用功能,故单独列出来作为一个快捷入口。

需求文档中的功能和内容一般比较零散,通过信息架构将零散内容分门别类封装之后,下一步需要任务设计来将它们串起来,成为可以一步步跳转的功能。

任务流程是一个产品的骨架,支撑起整个产品,为各个模块的功能内容提供基础。

例如一个LBS社交产品,可能采用这样的任务线:初启动进入消息页面(阅读欢迎信息)→LBS搜索附近用户/群→与新朋友(群组)互动→发表自己状态→体验其它增值服务(如游戏)–纯脑补。

任务线一般还有主次之分

结合信息结构分解用户任务

然后进行优先级排序(用户数、使用频次、重要度)

接着组合性质相关的任务(例如社交产品中搜索附近的用户和附近的群组性质是一样的,归为一类)

这样才可以得到比较有条理且主次分明的任务线。

完成任务线的设计还不够,用户素质参差不齐,即使PM或者设计师看起来再“合逻辑”的设计,依然会有大大小小的用户搞不懂,我们需要多想一步,通过科学的方法引导用户完成任务:

①相似性引导:如果功能元素的页面表现具有大小、色彩、形态、视觉等上的相似,可以牵引着用户的视觉,引导用火操作。

②方向性引导:通过整齐的指引性箭头、排版和线条,引导用户去完成相应的操作。

③运动元素引导:用户完成一些操作之后,相应的页面元素发生变化,直观地显示引导操作,例如移动端常见的抽屉式设计。

④向导控件:明确告诉用户,完成一次操作有多少步骤,当前处于哪一步,下一步需要做什么。

在前面的文章讲了怎么发现用户需求和怎么判断用户需求,这篇文章接着来说需求分析,主题是怎么定义用户的需求。我会从下面三个部分来来阐述:

  1. 第一:为什么要定义用户需求
  2. 第二:怎么定义用户需求
  3. 第三:怎么管理用户需求

一.为什么要定义用户需求:

想想这样的场景,作为产品经理的你,邀请了产品、运营、研发、测试、设计师等在会议室进行需求讨论和评审,在会议开始的时候,大家还心平气和,然后因为一个问题开始意见出现分歧,慢慢开始自说自话,吵成一团,进而形成鸡同鸭讲的局面,最后变成了“谁对谁错”的争论,甚至有的人恼羞成怒,开始进行人身攻击;大家纷纷为自己的想法和观点辩护,但没有一个人站在用户角度说话。

这样的事如果只是存在于会议讨论部分,可能仅仅只是一场失控的,无效的会议,如果这些事存在于产品研发的整个过程,则注定会成为一个失败的产品,如果整个公司都这样,想想这个公司得有多糟糕。

造成这种情况最重要的原因是我们对需求没有进行一个很好的定义,这样就没有一个讨论的基础,在目标不清晰,没有共同认知的前提下,每个人都在表达自己的想法就不奇怪了。

我们要制造一辆自行车,首先要定义什么是自行车,这样才能制造出自行车,否则我们造出来的可能是奇形怪状,千姿百态的各种车,而不是今天在路上跑的自行车。需求分析也一样,我们要解决用户需求,首先要做的也是定义用户需求。

定义用户需求就是人为的把问题进行一个约束,把问题限定在一定的范围内进行讨论和解决,目的是为了清晰目标,建立共识,减少分歧。定义用户需求是后续工作开展的基础,一切工作围绕定义的这个用户需求展开,而不是围绕某个人的想法和意见展开。很多人会容易忽略这一部分,直接把痛点,想法等因素和需求画等号,但想法随时会变,痛点也会被越来越多的发现,如果按照想法和意见来展开工作,很容易导致后面的工作失焦。

二. 怎么定义用户需求:

定义用户需求一般从下面三方面来展开:

  • 构建用户角色

  • 描述使用场景

  • 定义用户问题

一. 构建用户角色

第一步:确定目标人群

在前面的文章中,我们已经讲了怎么通过一个痛点,逐步的挖掘出这痛点背后的人群,但是这个人群只是潜在人群,并非目标人群。一般公司都会因为人力,物力,财力等各种条件的限制,不可能一下满足所有潜在人群的需求,尤其是在起步阶段,什么都缺的情况下,必须有所取舍,去选择最符合公司利益的一部分人作为目标人群

比如你做一个考研的产品,理论上考研的学生都有可能需要,但是你的老师只有四五个,只能搞定北京的市场,那么你的目标用户是北京高校的大学生,而不是全国所有高校的大学生。

第二步:用户角色划分

目标人群在整体上方向是一致的,但是这其中个体的差异会非常大,这种差异在教育方面体现到尤其明显,在一个班里,所有人都是同一个老师,但是最后学习成绩差别非常大。所以为了我们把需求定义的更准确,还要将目标人群划分成不同的角色,具体的划分方法,根据不同的产品有不同的方式;

以学英语为例,我们可以根据学习目的划分成练口语的,考四六级的,考雅思的,以k12教育产品为例,我们可以把用户角色划分成学生,老师,家长,然后在学生里面又可以划分成小学生,初中生,高中生,根据学习的科目又可以划分成学语文的,学数学的,学外语的等。

理论上用户角色粒度划分的越细,需求定义的也会越准确,但是实际情况往往是不允许的,除非做个性化定制产品,否则我们也没有必要做到太细。

第三步:构建用户模型

在上面我们划分了用户角色,但是用户具体是什么样,在我们心中还是非常模糊的,这时候就需要使用用户画像的方法构建一个典型用户,用这个典型用户来代表该角色的用户群体。

在典型用户的模型中通常会包含性别、年纪、工作,收入、地域、情感,目标,行为等,一个产品构建的典型用户数量通常在3~6个,如果数量太多,就得考虑我们的目标用户是否选的准确,就需要优化目标用户,让人群更加聚焦。

通过确定目标人群,用户角色划分,用户模型构建这三个步骤,我们就可以完成用户角色的构建了,在这里需要注意的是,最后构建的这个典型用户并不是真实的用户,而是代表所有真实用户的虚拟用户。

一个从零开始的产品,产品比较简单,用户角色往往比较容易构建,表达起来比较清晰,在产品成长迭代过程中,用户的角色可能会发生变化,角色数量会变的非常多,分析起来就没有那么简单了。比如现在风靡小黄车,最初起步于清华北大,最初以这些学校的学生为模型,慢慢向全北京的高校扩张,现在向社会开放,各种各样的人都有可能使用,用户模型已经变的非常复杂。

二.描述使用场景

大家都有过等电梯的体验吧,一般等待的时间在1~2分钟左右,在这个时间,干点什么时间太短,不干点什么电梯迟迟不到,又特别无聊,特别焦虑,尤其人多的时候,眼睛都不知道放什么地方,有一个人发现了这个情况,给电梯口挂了一个广告屏,让大家在排队的时候看广告,这个人叫江南春,他的公司叫分众传媒,这是为数不多的把广告做的不让人讨厌的公司。

为什么大家愿意看电梯口的广告,就是因为抓住了用户停留时间短,又无聊的场景,把以往被动接受的广告变成了主动接受。分众传媒成功后,很多人想模仿,比如在出租车,洗手间,医院候诊室等

地方安装液晶屏,都不怎么成功,就是因为没有找到这么好的场景。

所以我们在定义需求的时候,场景非常重要,切记要描述这个需求是在什么场景下发生的,否则这个需求可能就不成立了,场景一般由背景诱发因子期望组成,描述场景应从这三方面着手来描述;

比如上面分众传媒的例子,背景是等电梯,诱发因子是无聊,不知道目光放什么地方,期望是摆脱这种无赖,滴滴打车的例子,背景是你要去见一个客户,诱发因子是你打不到车,时间又快到了,期望是帮助你快点打到车

下面我们来看一个基于场景设计的例子

左右这两个都是iphone的来电显示界面,为什么要有两个接电话的界面?注意细节的小伙伴会注意到

左边的界面是手机在锁屏的场景下显示的,在锁屏的时候,手机可能在口袋或者其它地方,这时候不仅要让用户能方便的接听电话,还要防止误操作,所以设计了滑动的方式让用户来接听

而右侧是在未锁屏的场景下显示的,未锁屏的时候手机一般处于使用状态,可能是在刷微信或者玩游戏,这时候误操作的情况就不需要考虑了,怎么方便快速的让用户完成决策是最重要的,所以将接听和拒绝分开设置成两个按钮,使用点按的方式来操作。

三.定义用户问题

在定义需求的时候,用户角色和场景都是前提用户的问题才是这里想要表达的最终意思,后期产品设计也是基于用户问题来设计方案,进而解决问题,下面我们先来看下面一个例子:

有一个出色的主管,她十分热爱自己的工作,能力也不错,但有一个问题,就是与上级的关系处理得不好,最后闹得不可开交了,没有办法,她决定离开那个公司。于是她就把自己的资料送到猎头公司,请他们为自己另找工作。

这个主管回家一脸丧气,把事情告诉了她的老公,老公就帮忙分析了一下,告诉她这个问题的根本只是你与他分开,而不是辞职离开公司。既然是只要你与他分开就可以,那么,不一定是你走,让他走也行。”

于是,这个主管将解决问题的方式颠倒过来,为她的上级准备了一套资料,送到猎头公司。结果你懂得,猎头去联系了这个主管的上司,这个上司也厌倦了他目前的工作,而且新工作待遇更好,就欣然接受了新的工作,从现在公司辞职了。

从这个例子中我们可以看到,一个好的解决方案,往往是从定义问题开始的,如果没有定义好问题,就盲目的解答,只会白白浪费时间和金钱,最后得出没有意义的答案。

定义问题,就是透过用户的反馈,找到问题的本质,多问为什么?搞清楚用户真正需要的是什么?

比如我们经常在工作中遇到用户反馈产品烂,产品难用,有可能不是真的产品有多烂,而是因为网速不好,这时候问题的解决方案是引导用户解决网速问题就可以了,有可能一句文案就解决了,而不是根据用户意见改进产品;再举个我们都非常熟悉的例子,如果你是一个淘宝店主,用户给了你的店铺差评,可能并不是对商品不满意,而是因为物流太慢了,这时候更换快递公司即可,没有必要下架商品。

三.怎么管理用户需求

我们定义了用户需求后,需要把它记录下来,一个是用来不断的优化完善,另一个是需要和团队来交流沟通,在这里推荐使用描述用户故事(user story)的方式来记录。这个方法来自敏捷开发方法scrum,一般的描述格式为:

作为一个<用户角色>, 我想要<xxx>, 以便于<商业价值>

比如:作为一名老师,我想要查看报名的学生人数,以便于更好的安排课程计划

可以使用下面这样的表格来管理

每行写一个story, 怎么写story,大家可以在网上找相关资料自行学习,后面有空了也会再写相关文章。

四.小结

通过构建用户角色,使用场景描述,定义用户问题三个步骤,我们就可以清晰了定义用户需求了,一个用户需求的描述常见的格式是:xxx用户,在xxx场景下,遇到了xxx问题.

切记我们要分清楚潜在用户和目标用户,也不要抛开场景谈需求,而是要谈什么样的人在什么场景下的需求。

这篇文章就写到这里,后面有空会接着写第四部分,怎么定义产品需求。也欢迎在互联网公司工作的,想进入互联网行业的朋友来交流沟通,一起学习进步。

 

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/493.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息