存档

2011年2月 的存档

手机客户端交互适配设计之我见

2011年2月25日 没有评论

简摘:本文从手机平台、机型(触屏和键盘)及屏幕大小三个方面简单的讨论了一下手机客户端的交互及适配特性及一些原则。

手机客户端软件虽只是手机中一个功能,但它却要比设计单款手机更为复杂。在设计单款、单系列手机时,需要考虑这款手机的软、硬件优势及不足,考虑其特性、其UI Style Guideline ,确定这些内容后,整个平台的UI也找到基础了。说起来,这至多是考虑某个系统、某个屏幕的特性而已,而不同功能的所有设计基础都是一致的。

但是对于客户端,咋一看,好像很简单,就是设计一个应用。实则不然,客户端重在适配,客户端不仅仅会用在一个型号的手机中。这样问题随之而来,如何能适配不同的手机呢,手机千变万化,我总不能只针对一款手机,一个平台吧?当然也有些客户端确实是这样的,只能使用Windows Mobile、Symbian、iOS、Android、Java(非系统)等的某个平台。但是即使对同一个平台,问题还是很多,是要在触摸屏中来用,还是在键盘机中使用?是在大屏幕中,还是小屏幕中等等。 如何处理???有待大家讨论,这里只是抛砖引玉…

客户端在不同的平台中,界面展示和特性各不相同

所以,本文中,我想简单的总结一下手机客户端的交互适配方法,希望能更好地来指导当前移动应用的设计需求。

一、 手机客户端的适配分析

对于手机客户端的适配,我想首先需要做的就是如何适配,我要在什么样的手机上使用?在设计上,我会从平台、键盘机与触屏机、屏幕大小三个维度进行分析:

1. 平台:

不同的平台手机的设计风格、操作方式、硬件配置都存在很大的差异。当前的主流平台主要包括 iOS、Android、Symbian、Blackberry、Win Phone7、Web OS等。

每个平台都有各自的设计指南(UI Style),其对应的手机的硬件也有各自的特点,如iPhone的home键,Android 的back键,blackberry的滚轮等等。特别提一下Palm,Palm的web OS真的值得手机交互设计师研究一下(手机 Palm pre)。因此,在设计上,不仅要了解平台的设计指南,同时需要考虑平台的硬件特征,使自己设计的应用不仅符合平台的交互特性,并能兼容平台上硬件使用习惯,提高应用的可用性。

Win phone 7 系统的几个特点

iOS系统的几个特点

Android 系统的几个特点

由上图可知,几个最新的平台也存在较大的不同。对于手机的平台特性,会在未来的博文中再详细赘述。

2. 触屏机和键盘机

键盘机和触屏机在操作方式上很不同。

下面简单总结一下键盘机和触屏机的特点。

  • 键盘机:

1)键盘机的操作方式采用Soft Key 与屏幕软键标签一一映射(左右软键、对话框的按钮等都需要与键盘的标签一一对应),对所有的屏幕元素,都需要用五向键(滚轮)导航;需要用光标来操控屏幕上的所有元素。

2)一般左右软键上有一个【返回】键。用户可以通过软键快速的返回。

3)由于用键盘操作时,每次选择项目都需要从上到下依次浏览项目,因此重要性高、使用频率高的元素应放在屏幕的最前面。

4)按键可以根据数字键来设置一些快捷的操作;通过长按来设置快速翻页。

5)除了网页的形式,绝大多数的操作都是在菜单里完成。

6)文字输入的方式,通过键盘来输入,全键盘和数字键又有不同。

  • 触屏机(屏幕尺寸会略大):

触摸屏手机最主要的特点是直接操作屏幕对象。对用户来说,不需要进行映射的转换,因此易学性更强。但是由于手机的使用场景很特殊,或站着,或在行走,或只能腾出一只手等等,在这些时候要精确指点操作也有一定的难度。

触屏手机也有两种操作形式,用手指直接操作或者用笔操作。但是当前的屏幕发展及推出的机型来看,主要会针对用手指直接来操作。如果用户操作后,有屏幕的力反馈,则效果会更好。

1)操作对象的大小符合手指的操作,按键的大小设置规范:

  • 食指点击的间距 约为7*7 mm, 1mm间距,
  • 拇指点击8*8 mm,2mm间距。当前推荐的值为9mm 大小,最小应不小于7mm。
  • 当然一些重要操作,或者频繁点击的区域可以设置的略微更大一些。

2)由于单手操作时,只能使用拇指操作,因此,使用最频繁的按钮大小必须根据拇指的大小来设置;拇指辐射的范围主要在屏幕的底部,因此需要把这些操作放在稍微靠下面的位置更好。

3)信息显示:大屏幕可以显示更多的内容,但是避免信息显示过于拥挤。

4)手势的定义:当前手机上我们可以看到一些基本的手势操作,如拨动、拖拽、双指放大/缩小、双击等最常用的操作。其实还有很多其他的手势形式,如画圈,打勾,打叉,双指点击,双指滑动等等,这些需要根据手机本身的配置来使用,不建议随便使用特殊的手势来定义常见的操作行为。

5)输入的方式:输入时会起一个虚拟键盘,键盘的显示与隐藏都需要考虑,同时,可以根据当前输入的目的,直接做操作的按钮。

3.屏幕的大小

在考虑手机屏幕大小时,一定要区分物理尺寸与分辨率的关系。物理尺寸的大小和分辨率并非一一对应,例如对于HTC的S1 2.8 英寸,分辨率为320*240;Nokia n81 2.4 英寸,但是分辨率也是320*240。因此,对于相同分辨率大小的图标,在 S1 中看起来就要更大些,但是图标可能就没有那么细腻了。

在视觉设计时,需要首先考虑这个问题,在首次设计时,应该更勤于导入设计视觉图片到目标屏幕中去检验,看看设计是否合适,别到都完成了视觉设计,才发现设计的图标太小或者不够精致。

对于2.8 英寸 及320 * 240 (含)以下的屏幕,在现在来说都是小屏幕界面,在这个档次上,应该是键盘机占主导地位。在键盘机的设计上应该更多地去参考Nokia的规范(对于可用性,Nokia的设计还是无可挑剔的)。

对于3.0 英寸 及 480*320 以上的屏幕,可以认为是大屏幕,并且是以触屏机为主的。【随着屏幕技术的发展,屏幕的密度已经越来越大,这样的值也只是一个参考值。】

1)屏幕信息布局

小屏幕和大屏幕在客户端信息内容的布局上会存在较大的差异。屏幕大时,除了考虑信息架构外,需要考虑在界面上放哪些信息和操作;屏幕小时,更需要考虑信息架构,对信息更好地分屏,信息之间的联系等。

2)不同屏幕设计特点

a) 大屏幕的设计特点:

  • 在界面中,展示更多的信息;包括界面内容、导航和操作按钮;
  • 大屏幕以触摸屏为主,更多地以手指来直接操作;
  • 在屏幕上,显示的信息不宜过多;信息密码过高,不利于信息的搜索。

b) 小屏幕的设计特点:

  • 在界面上先展示客户端的功能及结构;
  • 以键盘机为主,操作方式;
  • 先导航,后显示内容,内容的分屏合理,符合用户的期望。

对于手机的屏幕大小适配,会在未来的博文中再详细赘述。

二、手机客户端的设计原则及适配步骤

1. 客户端的设计原则

1) 手机本身的物理特性受限引起的指南:

a)   客户端的文字输入,必须要降到最低:由于手机在输入上的低效性,在设计的过程中,应尽量减少用户的输入,如果有可能可以设置默认值,或者让用户选择目标值。

b)   客户端的信息结构好,屏与屏之间的逻辑关系清晰:由于手机屏幕都普遍较小,即使有4吋屏,那也只能展示较少的信息量,因此,在手机设计上,更需要有清晰的信息架构,用户知道当前在哪儿,并能返回到哪儿。

c)   客户端的操作、功能不要隐藏太深,重要功能都需要在界面中有适当的提示:由于手机屏幕较小,不能展示所有的信息。因此,对重要的、使用频率高的功能或信息放在最重要的位置,并在首页上展示或指示。

2) 手机的移动特性引起的指南:

a)   客户端的最主要的功能操作,用单手可以完成:手机的使用情景多样性,在很多情景下,用户都只能单手来操作手机,因此,在客户端的设计过程中,需要考虑最重要的核心功能,能否单手操作完成。

b)   客户端的界面必须简洁、操作简单,操作步骤少:由于用户操作情景复杂,在使用客户端的过程可能有额外的认知负荷,因此,在设计客户端的过程中,逻辑必须简单,操作步骤也要减少。

c)   客户端的界面层次不要太深,最好不要超过3级:

d)   客户端的提示包括界面、声音、振动多种形式:用户在操作手机时,往往不会一直盯着手机屏幕看,因此,很多手机状态页面的切换,脱离了用户的视线,这时,必须要提供视觉之外的其他感觉通道的信息(如听觉、触觉等),来对用户做提示。

3)其他原则

a)   客户端UI的适配不必恪守所有的平台都保持一致,只要一些品牌的关键元素能体现即可:

b)   客户端的主要操作方式(框架、导航、按键功能及软键对应方式等)应与所承载的手机操作系统保持一致:客户端都承载在某款具体的手机平台中,而用户会对当前的手机平台很熟悉,因此,在设计的过程中,需要更好地理解当前的手机平台,并使客户端的设计与手机系统的设计逻辑保持一致。

2. 手机客户端设计适配的步骤:

个人认为,客户端的适配要以一个平台为起始,但是要着眼于多个平台。

1)  根据公司的战略,选择一个最先切入的平台;

2) 了解该平台的UI 设计规范,可用的UI 控件及交互原则;

3) 确定切入的屏幕大小,以此来设计第一个客户端,但是要考虑适配其他屏幕的可能性,是自适应来扩展或者缩小;

4) 根据平台及屏幕大小,来选择一款最典型的手机,开始客户端的交互设计。

5) 确定客户端的核心目的。如为娱乐为主的,应在设计方式更娱乐性;功能性完成目的为主的,以更易用性为主;

6) 根据客户端的功能和内容,来设计客户端的信息架构;

7) 根据UCD的原则,来完成客户端的交互原型;

8) 在交互原型的过程中,需要考虑手机适配的三因素(平台、屏幕、触摸/非触摸),以便将来的适配。

分类: 9其他 标签:

手机端阅读类产品的信息架构

2011年2月25日 没有评论

手机端阅读类产品的信息架构

[  2011-02-23  |   交互设计 ]

信息架构是产品和用户认知之间的沟通桥梁,是评价一项设计产品的重要标准。本文就以手机端阅读类产品为例谈一点对信息架构的认识和理解。

一、什么是信息架构?

信息架构是在信息环境中,影响系统组织、导览、及分类标签的组合结构,是信息直观表达的载体。

信息架构会影响信息的可用性和可寻性。换而言之,信息架构的核心工作是建立恰当的导航,将组织过的、有序化的信息呈现给目标用户以方便获取和管理。

二、手机端信息架构的影响因素

手机端产品有其自身的特点,比如手机屏幕尺寸的限制、操作方式的局限,以及手机随时随地的便利性等。信息架构的设计必须符合手机端特点,发挥其优势,做到独一无二的设计,而不是简单的进行PC端网页迁移。手机端信息架构的影响因素众多且处于激烈的变化中,但其中最为深刻也是较为稳定的两个因素是用户环境和显示空间。

1.复杂的用户环境

好的信息架构是围绕产品的用户环境建立起来的,因此有必要简单了解一下手机端阅读类产品的各种用户环境。出于全面的考虑,将用户环境划分为用户群、媒体环境和物理环境三部分进行简单的分析:

  • 依据某主流市场调研机构的研究,手机端阅读产品的用户群主要为:1.白领和学生;2.都市“草根”;3.时尚高端人群。
  • 访问网络时所用的设备叫做媒体环境,主要为智能手机。平台众多、机型复杂,呈终端碎片化特点。其中具有宽大屏幕的触屏手机最适合手机阅读。
  • 用户访问网络所处的位置被称为物理环境,决定着访问信息的方式。手机阅读类产品的物理环境主要为等车、排队等碎片时间,另外还包括一些闲暇休息时间,主要目的是打发时间。

2.有限的显示空间

相对于PC端,手机屏幕的显示空间无疑成为信息展示的瓶颈。PC端网页可以承载丰富的信息内容并能保持良好的显示效果;而手机端显示空间却显得异常宝贵。请看二者的对比图示:

以上提到的用户环境和显示空间是影响手机端阅读类产品信息架构的重要制约因素,决定了其“窄而浅”的基本特点。这几乎属于所有手机端产品信息架构的共性。但是,具体到阅读类产品需要采用哪些相应的信息架构策略呢?

三、手机端阅读类产品信息架构策略

Donna Spencer提出用户搜索信息的四种方式。用户访问阅读类产品,正是典型的搜索信息获取信息的过程;而如何引导用户顺利、高效地到达目标信息则是信息架构设计的职责所在。个人以Donna Spencer的四种搜索信息的方式为维度,对手机端阅读类产品对应的信息架构策略进行了简单归纳。

1、Known-item已知项目

在已知项目搜索中,用户

  • 知道他们想要什么;
  • 知道用什么词语描述他们想要的信息;
  • 明白从哪里开始。

解决此类需求,最典型的信息架构策略是提供搜索框。用户输入明确的关键词,一次点击就能找到所需信息。这是已知项目搜索最为快捷的导航方式,各大手机阅读类网站几乎都设置有搜索框:

2、Exploratory探索

探索性信息搜索中,用户对所需要的信息有所了解,但不知道用什么词语可以将它准确描述出来。并且用户不知道从哪里开始,即使找到了较为符合的内容,也不知道这些内容是否足够。

这种情景下,用户需要一个学习的过程,从而缩小固有认知和目标信息的差距。因此,信息架构设计必须允许用户通过尝试和摸索获得对网站全局的概括了解。导航(Navigation)是解决这部分需求的典型架构策略。由于手机端信息显示空间的限制,很难承袭PC端网页的tab导航方式。业内较为常用的导航方式有:站内信息板块化提炼、导航多级别化设置、热频链接的提供等等,如下图所示:

3、Don’t know what you need to know无特定目标

有时候用户为了打发等车或者旅途中的无聊时间,而毫无目标的来到阅读网站“闲逛”。他们不知道自己需要什么内容,换句话说,读什么并不重要,只是为自己找个事情做。

解决这部分需求最典型的信息架构策略是提供榜单列表。人们都有同理心,大家好评度最高的电影一般不会坏到哪里去;同样,点击量最高的小说也都比较精彩。所以,毫无目标的情况下,榜单列表是引导用户阅读最好的建议式指南针。这种榜单形式已被各阅读类网站广泛应用。

4、Re-finding返回寻找

用户可能会返回网站继续上一次的阅读,但要记住上一次读到了第一百三十章还是第一百三十二章确实很难。用手机浏览器添加书签固然可以解决问题,但需要频繁操作,相当疲惫。可以考虑的架构策略是为用户提供最后一次阅读章节的“记忆”链接,减轻用户的操作负担以及记忆负担,让用户充分感受该产品的智能和温馨。

四、需要经历的信息架构三境界:

要做好手机阅读类产品的信息架构不可能一蹴而就,产品的日臻完善需要一个循序渐进、不断优化的过程。基于对相关产品的研究和个人理解,手机端阅读类产品的信息架构一般需要经历三种境界:

第一境界:“斜月沉沉藏海雾,碣石潇湘无限路。”

信息架构的组织不明晰、导航不明确、分类不恰当,导致信息的无序化。将用户陷于迷宫之中,搜索变得困难重重。例如用户登录某个阅读网站,刚进入页面的第一屏就被淹没在大面积的广告中,丧失了信息方向感;接下来的内容信息在有限的显示空间中隐藏过深,需要点开层层链接才可以到达正文页面;加上有的标题文气十足,每一步操作都会引起用户思考,如此冗长的操作流程实在是手机网页设计的大忌。

第二境界:“两岸猿声啼不住,轻舟已过万重山”

信息架构的组织较为明晰、导航简短便捷、内容分类一目了然。用户凭借有序化组织架构的引导,可以快速了解和获取目标信息。这就需要手机端阅读类产品的导航窄而浅,做到宽度和深度的恰如其分、相得益彰。此外,导航标题的语义应当具有较强的排他性,不与其他标题有语义重叠区,也就是语义的典型化。如此,用户的操作流程可以缩短、思考的时间可以减少。

第三境界:“近水知鱼性,近山识鸟音。”

搜索个性化是未来的发展趋势,如果应用恰当,可以明显提高手机阅读类产品的用户体验。例如自动识别用户兴趣和地点的自我推送功能,更加适合手机端阅读类产品。首先用户的阅读兴趣稳定性非常大;其次在流动的地点和碎片的时间里用户搜索信息的耐心十分有限,需要一个更加便利的信息获取渠道。当用户每次访问网站,都可以收到高匹配度的内容推荐,这份知己的温馨已经可以和老朋友相媲美了:)

原文地址:

http://mux.baidu.com/2011/02/442/

分类: 9其他 标签:

如何与设计人员沟通

2011年2月25日 没有评论

最近做图烦死了,不停的改图,改图……。烦,倒不是因为改,而是反反复复的改,人都会死。很多需求人员不知该如何与设计人员沟通,不明白如何使设计人员知道他所要的效果,结果只能是沟通变成了扯淡,改图变成了应付。

那应该如何与设计人员沟通呢?

我认为设计人员与需求人员先天就存在语言障碍。对一个合格的设计人员来说,整天玩的都是点、线、面、配色,哪种构图看起来协调;哪种配色看起来合理心里跟明镜似的,而需求人员却对此一无所知,只知道“我要的是那种,那种效果!”到底是哪种?不知道。这也并不是说要让需求人员都会讲色相、明度等一些专业术语。只是表达时换一种方式也许让设计人员更快明白其用意。

1、需求应该怎么提

很多需求人员在提需求时会犯一个错误,就是自己先把所有东西都想好,哪放按钮、哪放图片、哪用什么颜色真是比设计师还“专业”。我还看过一份广告需求写着“左边有棵圣诞树,树下摆满了礼物。右边天空上圣诞老人坐着雪橇在空中,洒下三个礼物盒……”别笑,这样的需求还有很多。还好他们不会PS不然设计人员都要下岗了。

其实在提需求时想法应该越少越好,特别是一些主观想法应该坚决剔除,因为这样设计人员的发挥空间才会大。那么你可能又会想总不能什么都不写让设计人员天马行空的做吧?要写,而且以下几点必须写:

a) 目的(主题)
需求人员一定要明白这个项目应达到什么目的应该得到什么结果。一个广告要突出什么主题传达什么信息,这都必须让设计人员明白,方向明确了劲才能使到一块去,如果这一点也没有那么这个需求完全没必要提。

b) 目标受众
这个需求针对那些人?;项目的用户群是哪些?都要让设计人员了解。这样设计人员才好根据这些人的喜好做出相应的风格。

c) 项目背景
假如该设计人员是此项目“御设计师”那这一项也可以不写,但对于对此项目不太了解或新进设计人员来说,项目背景还是有必要了解一些的。这一想不用写的过于详细只需说明一个大概即可。

d) 时间安排
在填写时间时最好先与设计部经理了解一下目前设计人员的工作量如何,或与相关设计人员协商后再填写。

另外还要写上项目负责人(谁拍板)、项目联络人(谁跟进)等相关人员信息,如果维护类需求还应写上原设计人员的名字。需求提交后还应与设计人员一到二次的当面沟通,把需求上没有说清楚或设计人员没看明白的位子解释一遍。

2、图应该怎么改

改图是不可避免的,但是我们要把这种频率减到最低。注意我这里说的是改图而不是所谓的迭代。假如需求人员与设计人员配合的足够有默契,其实也很容易得到各方所要的效果。视觉这东西很大程度上是一种主观感受,每个人喜欢的风格不同,品味不同,当然都会有各自的想法。但首先设计人员应该把自己认为最好的效果呈现给大家,如果连自己这一关都过不了还怎么都说服大家?而需求人员在提建议时最好先想想这是否是你的主观想法。喝百事与可口都可以降署解渴,怎么能因为你不爱喝可口就也不让别人喝可口呢?其实达到目的即可。

在提建议时也因注意一下,多提一些实际性的建议不要来虚的。比如“这个图还没上调子”,不如说“这个图的这个位子太暗了”。

语言上也不要太文艺,就说最容易明白的语言即可,比如“能不能做出光泻在叶子的感觉?”不如说“能不能做一道光照在叶子上?”。

还有一些需求人员喜欢提一些看似专业而非专业的建议,比如“这个文字太暗了,能不能再亮点,背景也要调亮点。”其实此时文字已经是纯白了,之所以不够亮是因为背景不够暗显不出文字的原因,其实需求人员只要说文字不够突出就可以了。

总之建议应多提硬伤,主题是否已突出?条例是否清晰?达到目标即可。提建议时应用最简洁明确的语言沟通,大家就不要秀文采比修辞了,这又不是对对联。

分类: 9其他 标签:

漫谈互联网产品商业需求文档(BRD)的设计

2011年2月25日 没有评论

9153703052

BRD是英文”Business Requirement Document“的缩写,根据英文直译过来就是”商业需求文档“的意思,指的就是基于商业目标或价值所描述的产品需求内容文档(报告),其核心的用途就是用于产品在投入研发之前,由企业高层作为决策评估的重要依据

BRD与PRD的差异

BRD不同于常见的MRD(Market Requirement Document-市场需求文档)和PRD(Product Requirement Document-产品需求文档),既然是用于产品实施之前的决策评估依据,必然对其文档(报告)的内容和格式要求够直观、精炼,要点突出。作为报告的撰写者,你必须让高层明白,你的报告中将展现出怎样的商业价值,如何用有力的论据来说服企业对你这个项目的认可,并为之慷慨的投入研发资源及市场费用。如果说PRD的好坏,直接决定了项目的质量水平,那么BRD的作用,就是决定了你的项目的商业价值。优秀的BRD文档,可以让决策层充分被你的报告观点所吸引,或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动;或许技术主管会因为项目的牵涉面广泛而头疼不已;又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景……

说白了,BRD需要产品经理(产品设计师)像对待PRD一样,充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。基于这样的状况,显然不是给大家一份完整的BRD标准格式规范,就能够搞定一切的!哈,也许有人会说这有点危言耸听,不过我一向赞成,面对一切“产品”,都应该用设计的眼光看待它。

首先,你应该把决策层当作你的产品——BRD的受众群体,一切从这里开始……

BRD的受众群体

不同的企业,不同的时期以及不同的决策环境,使得BRD的决策层必然存在着较大的差异,很多人都会疑惑,究竟决策层都会有哪些人?为什么是这些人对BRD进行评审,而不是技术经理或项目经理之类?其实这都不是问题的关键,无论是企业的老板还是CEO、COO、CFO之类,又或者VP或各类部门主管,什么样的人参与BRD的评审都是可以的。作为产品设计师,你对受众群体的分析,不是要关注他们是什么职业,又或是什么Title,是男又或女,你应该抓住这些受众群体的核心需求:“他们为什么要评估你的报告?评估后的决策,究竟决策什么?”

再细致回顾一下,通常我们会在什么情况下撰写BRD报告?一般都是在年初大家做年度规划的时候,又或者是产品经理在日常产品管理过程中,通过一系列的市场分析或调查,掌握到了一个潜在的、未被满足的大量用户需求,而这些需求背后将映射着一个广阔的市场空间。产品经理因之而激动莫名,匆匆写了一个数十页的报告,找到上级领导,领导的领导,领导的领导的领导……一番唾沫横飞的演讲后,也许就提出了以下这些要求:

  1. 这个项目很重要,希望领导支持我来做这个项目;
  2. 这个项目很有价值(社会价值——造福全人类?;商业价值——未来的赢收主体?;用户价值——引领用户潮流?比如说Iphone;市场价值——也许明年我们的市场份额就会扩大一倍;投资价值——我们将全面进入一个新兴的领域),希望公司能重视这个项目,并纳入未来战略计划中;
  3. 这个项目很庞大,需要公司提供足够的研发资源和市场费用,希望公司能审批一笔预算并给我一个专属的项目团队,这样我才会最大限度确保项目成功;

BRD的决策参与模型

通过上述的分析,我们似乎找到了撰写BRD背后的目的:我需要一笔费用;我需要一些资源;我希望公司高度重视;我希望各级领导支持;基于这些目的性,我们可以把决策参与人分成以下几类,先看看我整理出来的BRD的决策参与模型(如下图)

BRD的决策参与模型

  1. 资本型:这类角色一般就是为我们提供足够的产品研发经费,自然以CFO(首席财务官)、财务总监之类为主;
  2. 市场型:这类角色一般就是为我们提供未来市场营销和商业运营方面的支持人员,通常以市场总监、运营总监之类为主;
  3. 研发型:这类角色一般就是为我们提供技术性支持的主管,比如技术总监或研发总监之类;
  4. 战略型:这类角色一般就是企业的老板(董事长)、CEO(首席执行官)、COO(首席运营官)或直属VP(副总裁),这类人,通常能够为你提供产品在企业内受到足够高度的重视,让你实施项目畅通无阻,而是否纳入1~3年的战略规划,也是这个层面的人说了算;

如果你充分掌握了以上这些信息,事实上你就已经为你的BRD获得审批通过成功了一半了,剩下的,就是看你对报告细节的把握能力了。确定报告的大纲,充分论述报告的各方面重点,利用你擅长的沟通表达能力,用最简洁的语言、条理清晰的思路来陈述你整个报告的核心部分!

接下来,我们进入BRD报告的核心环节——“设计”(抱歉,这里需要的是你的设计思维而非展现你深厚的文字功底)一份出色的分析报告!

上篇谈到BRD撰写之前的决策模型,其目的就是为了让大家明白一点,写BRD,不应该站在自已的角度来写这份报告,充分了解决策层,也就充分把握到了报告编写的要点。站在评审方的角度来写报告,你的报告成功的可能性就已经占了很大一部分了。

BRD报告要素

前篇中我们谈到决策的角色分类有资本型、市场型、研发型、战略型,我们现在就针对这几个角色,定义出BRD报告的要点。

  1. 资本型:假设你现在是一个财务管理人员,大家都知道,管钱的人对数字敏感,对“付出”抠门,因为对财务来说,付出都是负资产;对“进入”欢喜,最好的方式是只进不出,那样就是只有利润没有成本。哈,天下自然没有这么便宜的事,所以退一万步说,追求投入产出比是他们的首要关键,不在乎投入多少钱,而最在乎的是投入产出的比率,也就是追求利益的最大化。所以在BRD中,要专门针对这一方面,做一份详细的报告。而通常而言,做一个互联网项目,主要的投入在于“人力成本”“运营或营销成本”“时间成本”“软硬件成本”“环境成本”,如果单给出成本计划,财务肯定不乐意了。所以,一定要明确给出收益预测,而有时候项目不是关注短期效益,更多的项目在初期通常不大可能获得大的效益,这就需要报告中体现出长远的效益预测。设想一下,如果你跟管钱的人说:“做这个项目,我投入1万能赚1万……”,财务肯定拒绝投资,这种没有利润的买卖他们肯定不干(有一句话怎么说来着?资本家的本质就是追求利润的最大化!);但是如果换个说法“做这个项目,一个月内能赚到2000,二个月之后能赚到5000,三个月后能赚到一万……”,同样是投入产出1比1,为什么财务会更倾向于投资后者?相信很多人想到了区别——增长率!前面我们说到了,管钱的都对数字敏感,他们专业内对增长率和趋势预测那是基础知识,前面一种说法表达的意思是增长率是零,后面一种说法则更具体,更有说服力,有高增长率,而且将来收益会越来越多。你现在投不投钱?所以说,这是一种报告的技巧,但注意:技巧不等于虚假,你要有严谨的数据或论据支撑你这样的预测,别当别人是笨蛋!
    1. image
  2. 市场型:假设你现在是营销总监。做市场,最关注几个方面:有没有成熟的推广渠道,有没有竞争对手,外部环境如何,有没有营销资源市场占有情况,市场空间有多大等。我们仍然从营销总监的角度看这些问题:有成熟的渠道,我们营销工作就容易开展,如果没有,项目难度就会大增,有可能根本就无法落实。比如,一个项目要求快递公司要在保证全国二线城市1小时内配送到货,这很显然是不现实的,大家都知道目前的快递行业根本没有这么成熟的渠道,怎么可能做到这点?而有没有竞争对手,则要考虑我们是先发还是后发,做互联网产品,先发绝对具有优势,如果是后发,还要考虑竞争对手有多强大,它们有没有同类的产品?我们有没有跟它们在市场上直接竞争的实力?没有,那就免谈!外部环境,通常指行业环境和市场环境,政策环境,越成熟的市场环境,对新兴项目越不利,而越规范的政策环境,也对项目越不利。市场占有情况和市场空间的关注是相似的,就是要看我们有大的市场蛋糕可以吃。
  3. 战略型:你现在是VP或COO了。这个层次的领导,可能有些人接触不多,所以对这个角色的代入感比较弱,把握不到其关注的重点。其实,做到这一层面的领导通常眼界都会比较开阔,战略眼光高,看得远,想得透,抗风险性强!他们通常不会注重短期效益,而且也不仅仅只是关注单一的“钱”的效益,还包含关注是否是潜在市场新兴市场,是否有长期投资的价值,未来的趋势是不是很好,风险是什么等等。举例来说,“做这个项目,对我们企业的好处是什么?”你不要光谈钱,前面说了,Boss级的人,好处不再仅仅是钱上面。假设你的项目是目前市场上的蓝海,恭喜你,你的报告已经成功了一半;假设你说“我们目前的客户只占了整个市场了50%,还有30%的潜在客户,通过这个项目能够挖掘到。”同样恭喜你!假设你预测到2010年微博将会大热,而你们公司的产品又是一个大的门户,你及时发现了这个商机,你认为未来5年将会是微博的天下,那就再恭喜你!这有长期投资的价值!风险是什么?风险就是你要告诉我,我们失败的原因,失败后的损失。有多少失败的原因是我们可控的?如果大多数都是不可控的,那这个项目的风险就太大了。失败后的损失是不是公司可以接受的?可以,那就值的做!
  4. 研发型:研发型专业性比较强,大多数人是不具备技术知识背景的,包括大部分的产品经理人员,所以,对于写报告的人来说,研发这块可尽量简化表达,目的就一个,让研发的Boss充分理解你想做的项目是什么样的,主要有什么功能模块(确定架构设计)是什么类型的网络功能(确定性能支撑),比如微博项目,最大的难度在于海量、碎片化的数据存储及应用问题;比如电子商务,最大的难度在于大的订单量以及订单背后复杂的商务逻辑造成的系统复杂度和压力。

BRD报告汇报过程

掌握了关注点,再预演一下BRD报告的过程:

会议开始,你总得先给与会的领导介绍一下你的产品要做什么吧?(解决什么问题或满足什么用户需要)

为什么要做?谈谈背后的原因(背景、市场空间、竞争对手、环境)

打算怎么做?(产品规划、模块规划、研发计划、运营计划)

需要多少资源?(人力成本、软硬件成本、运营成本)

最终能获得什么收益?(带来收入、带来用户、扩大市场、占有市场先机、满足未来三年战略规划等)

做这个有没有风险?(开发失败?失去市场机会?失去先机?竞争不过对手?没有带来收入?没有带来用户?与公司战略背道而驰?)

OK,一切都已经明朗,细节就不用再说了吧?最后给大家提供一个BRD的模板吧!


分类: 9其他 标签:

需求分析:解剖产品想法

2011年2月25日 没有评论

产品人总会产生各种各样的新想法,这其中极少数“应景且靠谱”的想法会成为产品、惠及网民,而更多产品想法只会成为谈资、或博文素材,比如下文中的这片想法。那么,产生不应景、不靠谱的想法是不是错误呢?我认为不是,这种“产生想法——想法博弈——想法毁灭”的过程,对于一个产品新人来说,至少算是一种对互联网市场的猜想、对用户需求的分析、对产品策划模型的创造。关键在于,自己是否可以通过简单的市场调研、理性的需求分析,对一个自己中意的想法做一次解剖,洞悉其价值。这种解剖分析的过程,就是锻炼和成长的过程。

所以,我把以下这个想法拖上解剖台,按照“产生——分解——分析——实现——再回顾——评估问题”的过程,简单评估一下其应景与否、靠谱与否。

需求产生我在PC上阅读的时候,总会在某篇文章中发现一些“或拍案叫绝、或醍醐灌顶、或发人深省”的片段内容。每当此时,总希望轻松存储这些片段,以便收藏并回顾,又不会干扰阅读进程。提升一点儿档次的说法,即所谓的“知识管理”行为之一。

需求分解1、在PC上阅读,所以场景有可能是浏览器、阅读器、WORD等;2、阅读过程中存储片段;3、存储快速,以后可以阅读曾经存储的内容。

需求分析
层一:有用
●实施文字存储行为,并方便以后的回顾阅读;存储行为在阅读过程中完成,要求快速且便捷。

层二:易用
●网络存储:最好玩点儿云存储的概念,我走到哪里都可以把片段往云彩里塞、或从云彩里看。
●分类索引:分类、标签不能少,甚至注释、来源也可以有。一是方便我对内容的管理;二是说不定以后有大用处~~
●如何快速:“浏览新浪博客时,选中片段即可发布一条微博”——这种方式值得借鉴。在此过程中加入分类、标签、注释的交互过程,并淡化存储行为。造就一种“一片好知识,不知不觉已上云端”的完美感觉
●方便阅读:以某种方式让我舒服的阅读这些片段即可,比如网页方式。

层三:爱用
背景:满足了“不打扰阅读行为的快速存储、有效索引、便捷阅读”这一基本需求之后,我所积累的知识就会不断的往云端里塞啊塞。如果这个产品被我的100个其他同行使用,我们101为同好者就会不知不觉建立起一朵肥硕的云彩,关于某一类主题知识的云。
基于以上两行之背景,则会出现如下之场景:
●第一:所有知识均为用户筛选,基本全属于优质内容。
●第二:分类索引,让同主题的内容可以有效聚合,并含有注释、来源。
●第三:有了优质内容、主题聚合,分享欲望油然而生。我当然希望浏览同行们认可并收藏的知识片段。

需求实现:
现有工具:
●onenote、EverNote、wiz。试用了WIZ,索引及分类不清楚、存储有些迟钝。另外两个没用过,EVERNOET本身50M+,软件本身就够重的,有些麻烦。客户端嘛,最大的麻烦就是要安装和管理,一台PC一种情况,带不走。
●阅读器,比如谷歌。可以在有限内容源内收藏、分享内容,但其与需求本身还有着本质差异:阅读器,并非知识管理工具,不能对片段精华的知识进行有效的存储、管理、索引。

实现方式:
●客户端——沦为现有工具之列,加入竞争。另外,客户端+网页的方式,也加大了用户的理解和管理成本。内容源:可以照顾各种内容来源,包括网页、WORD等。
●浏览器插件——比客户端轻、比“下面的方式”重。内容源:比客户端缩小一圈,可以照顾所有网页内容。
●某阅读器文摘功能——最轻,内容源也最小,限于阅读器订阅的内容。有可能背离最初需求,沦为第二种“现有工具”。

最终方式:浏览器插件+云端存储+网页展示。

靠谱吗?回顾需求
即,回顾最初的需求是否得到了很好的满足,应该从虚拟场景中判断,功能是否抓住了用户的痛点(分析用户需求:在场景中寻找痛点):
●场景一:我安装了浏览器插件,以后无论在网络中阅读到任何对于自己有价值的内容,均可“选中内容——选填标签、分类、注释,并自动记录来源——完成云端存储”。
●场景二:我若需回顾自己积累的网络文摘,便可以“点击浏览器上的插件按钮——打开网页——按照预设分类及标签阅读浏览”。
●场景三:承接场景二,我还可以在网页中“点击公共标签、公共主题分类——浏览他人产生的优质文摘内容——关注某用户及其文摘知识 or 点击文摘来源,直接到来源网页浏览 or ……”,社区形成。

问题:1 用户对于“阅读过程中记录精华、笔记类内容,并作为知识管理、回顾阅读”的需求有多强?2 由用户产生的“片段化的文摘、笔记类内容”,其可读性、可分享性有多强?
●第一个问题,决定了这个产品本身的“产生意义”。
●第二个问题,决定了这个产品“到底是做一个纯粹的知识管理工具,还是借用户产生优质内容之东风,做一个知识分享社区。”
解剖完毕。我对于这个想法的评估,最后简单归结为以上两个问题。当然,由于个人能力和阅历所限,我这种自娱自乐式的解剖,会在过程中产生各种偏差或偏执。所以,最好的方式,是邀请其他同事、同行一起围观解剖台,对自己的想法评头论足,以保证下刀精准、方向正确,从而让自己这次需求分析的锻炼过程,更具备群众智慧和参考价值。

总之我认为,产品人就是要不断产生想法,然后毁灭想法,再产生,再毁灭…………直到这种反复自我毁灭的过程中,拼杀存活下来一些惠及网民的好产品,自己也就可以欣然的修成正果、立地成佛了~

分类: 9其他 标签:

无觅相关文章插件,快速提升流量