如何写一份交互说明文档

离开交互圈已经有段时间了。但由于博客还在,还是能够偶尔收到一些邮件,上周有位同学问我:我在求职,我看到很多招聘说明上需要交互设计师编写界面交互设计文档,请问界面交互设计文档是什么文档?怎么编写呢 这让我想起来2009年自己在项目里也大力推行过交互说明文档(在下文中,简称为DRD),格式倒没什么限制,交互设计师自己写到界面上也行,单独文档成文也行,总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来,降低项目里的沟通成本和风险。今天整理电脑,翻出以前的PPT,分享之。   这将涉及到几个问题:   一. 什么是交互说明文档(DRD)? 所谓DRD即是用来承载交互说明,并交付给前端、测试以及开发工程师参考的文档。 在项目中,交互设计师的主要产出物可能依次是:site map,page flow,wireframes。有的大型项目前期,交互设计师有可能还会产出用户需求分析文档(与PD产出的市场需求文档不一样的是,URD更多侧重于对目标用户的需求分析)。 DRD则很少有人专门撰写。如果需要对交互设计进行说明,聪明的交互设计师往往会直接标注在线框图里,或者在项目中不断和前端工程师和开发工程师口口相传,反复验收,不断迭代修改来确保所有的交互设计意图最终得以呈现。 二. 为什么要写? DRD非项目必需环节,一般情况下也不会为交互设计师专门留出相应的时间预估。没有这份文档,项目也会继续,但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话,项目的质量也会受到影响。所以写与不写,交互设计师需要做把握,时间被统一包含在“线框图”环节内——如果你要写,请在评估时预留1-2天的时间。 那么,结合我过去的经历,谈一下此文档的必要性。 下图是一个产品开发项目基本的流程。   敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的FRD已经全部敲定,交互设计师再开始去画线框图,固然会减少沟通成本和返工风险,但是同时意味着交互设计师的很多想法不被采纳。如果产品经理再强一些,他甚至会在FRD里连原始的DEMO也一并绘制出来了,功能性的需求和界面交互的需求有时无法区分太清楚——比如他会在FRD里直接要求每页条目40条,超过40条即分页。而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和……所以,我们希望是和产品经理同时开始工作,在术业有专攻的时候相互补充。 同样,开发工程师也希望及早介入需求,在FRD并未确认的时候就了解需求,进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单(这个清单,大部分叫做UC,即USE CASE),当这份清单由程师需求分析师——在过去,这个角色被叫简称为RA,但是目前已经取消此专门的职位,而是由开发工程师代表担纲此环节工作,为了便于描述,在此文里,我仍然将做这件事情的人称为RA——交付给具体的执行工程师后,执行工程师基本上可以当作一条条的checklist开始高效工作,而不必再思考商业逻辑和需求。同样,测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试,这也是基于UC和FRD去撰写工的。 所以,开发需求分析是个很重要的环节。那RA是如何来完成需求分析工作的呢? 前期介入,对PD进行开发需求评估支持; 参与每次的FRD评审会; 详细审阅FRD文档并不断与PD确认。 对于做这件事情的人来说,足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出,但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递,却存在很多问题。除了线框图,没有“详尽的说明性的文档”告诉他们。比如:   一方面,交互设计师对产品经理说:这块由我们来考虑,你的文档不必包含设计上的说明,这随时会调整的。 另一方面,线框图的评审有时会让RA参与,有时却没有叫他们。即使叫上了他们,他们也会发现交互设计的需求变化要比FRD变化快。另外,他们会认为UC不必写太多关于交互设计的需求。 在某个大型项目结束后,作为交互设计师,我进行了一些调研,听听这相关人员是怎么表述问题的: 开发部门的需求分析师: 每次变动都很痛苦,设计变了之后,我就要跟着改UC,改截图,有时候UED改了还忘了通知我们,导致UC有问题…… 页面交互的需求容易漏掉,因为UC里面不可能写太多交互方面的东西。 希望UED能够在提交HTML DEMO给RA时,能同时给出一份页面元素描述文档,需要介绍html demo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多,经常要和UED去确认这些内容。 产品经理: 前期RA和PD沟通过程中,有很多交互点点不能够明确,比如“默认显示多少属性值”,“标题显示多少字符”等。在以往的需求和项目中,对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求,往往会“越俎代庖”,直接在FRD注明这种需求(对于交互设计师来讲,却又导致没有发挥余地) 走访了一些交互设计师后,他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑: 交互认为很平常的设计需求,如果不表达出来,还是容易被前端和开发忽略掉。我经历的一个项目,前端从头到尾更换了三个人,每次我都要重复去讲解下设计需求,讲得口干舌燥。而且做好后,还需要去验收。 DRD做为参考手册,一定程度上避免不吻合的问题发生。 即使有问题发生,也可以作为界面验收时的Checklist。将“我对A说,我对B说,A对B说”,转变为“A和B共同参考同一份文档”,减少沟通成本及信息不对称。 全程影响用户体验(一直到测试,都需要参照设计文档)。 可是以下问题都可以通过一份DRD来解决吗?   三. 写什么不写什么?   要明确文档的定位,从写什么与不写什么开始,划清DRD以及FRD的边界。 1. 不写视觉规范规格标注 这些说明与功能实现没有太大关系,主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图:   2. 不写功能实现逻辑。 如下图所示,作为DRD,你有必要传达清楚Browse by category区域的设计:链接的可点击性,链接的指向,字符与条目的数量限制等,但是具体二级类目排列是按产品数目排还是按字母排,还是人工运营,是FRD要解决的任务。   那么文档写什么呢?   举例子说明下: 1. 字符限制 [...]

Advertisements

7 No-Nonsense Pieces of Startup AdviceI Wish I Got When I Started

There’s no shortage of advice for startup founders on the internet. But sadly, most of it isn’t helpful. The bad advice⁠—the variety that makes up the overwhelming majority of those search results⁠—typically falls into two categories: Advice so fluffy and vague (“product/marketing/support is everything”) that you don’t actually know what it means or what to [...]

※产品设计的从0到1全流程:以优惠券为例

文章以优惠券功能为例,分享了一个产品功能设计的完整流程,希望能够给你带来启发。 如何将产品从需求调研到落地的全流程拆解? 我们刚开始做产品时,可能都会有这样的困惑:老板说要做某个新功能或模块,但是不知道从何下手,怎么做?做成什么样子?怎么样才能做完业绩蹭蹭涨呢?而老板说的做xx,可以详细拆解成数步。产品经理每天要做的,就是把需求做好、落地。本文以优惠券功能为例,主要谈下我自己在做产品设计时的总体思路,期望用这个文章让大家把每一块散点的技能串联起来。 注:优惠券品类比较多,本篇仅讨论商家优惠券。 产品设计的从0到1总体全流程图(重要) 一、需求分析 1、回答一个填空题:什么用户,在什么场景下,遇到了什么问题。 (注意:这个用户可能是多方的,不仅仅是一方) 消费者:购物时发现无优惠活动,平台一直无优惠活动,不能减少成本。 商家:在平台销售,无法进行相应运营活动,为消费者让利,促销 平台:无优惠券这类营销方式,不利于运营推广,吸引消费者 2、一句话描述清楚产品需求(即对上方填空题的回答):给产品增加优惠券的需求,可以让平台上的商家定向或者公开的向用户发放优惠券,用户在下单时候可以使用优惠券,抵相应金额的功能。 注意:谁提出的功能,和谁在使用这个功能可能是两个人,一定要考虑清楚,比如某个功能可能是老板提出的,老板想要。但是真正使用功能的用户是基层员工。所以在设计产品时一定要考虑实际使用的用户是谁,要最大化减小产品的学习成本。否则有可能功能上线,无人使用,白费功夫。 同时也可以整理一份原始需求记录,将产品的根本目的、注意点记贴在墙上,时时提醒自己,为后面设计不跑偏做准备。一般我会在PRD最后贴上客户原话或者聊天记录,因为你翻译后的定位可能会有偏差。 可参考的竞品:京东、淘宝等主流电商网站 二、流程梳理 1、先分析功能的关键逻辑 先分析一个优惠券最主要的逻辑,不考虑任何异常情况,其实就是: 2、补充关键逻辑中细节功能,每个里面细节就是核心的功能点 可以看出沿着主流程这个图已经丰富了比较多的内容 3、泳道图(复杂多角色流程) 上面讲的是简单流程图的设计,若涉及到多角色,可以将其绘制成泳道图,泳道图绘制可以看下方步骤: 1)分析关键逻辑:确认角色、事项、信息流向 角色:都有什么角色参与到功能里 事项:每个角色要做什么事情 信息流程:要完成任务,顺序(流程)是如何的 以优惠券为例,我们可以画出各个角色及事项: 2)明确开始于结束路径 每个功能模块从哪里开始,哪里结束。一般开始和结束只有一个 3)确认核心路径和功能模块 确认都有哪些模块会参与到流程中,主流程就是功能目标一定要清楚 4)不断调整并优化,补充异常流程 泳道图中,主泳道图可能不会那么细致的将全部都画完,可以将其功能模块其中部分拿出来细化到PRD中 成型的泳道图:拥有角色、事项、各流程 注:对于产品设计来说,很多时候都是一种逻辑分析的能力,流程图在产品设计中,会占据很大的作用,只有流程图清楚,才能整体设计保持清晰。千万不可一上来,找两个竞品,开始抄界面,即使是竞品分析,先分析竞品的整体流程,才能猜透整体逻辑。要学会拆——合,抽茧剥丝。 三、信息结构及功能结构图 经过需求分析和流程图设计后,我们已经确认了整体大致方向、流程,接下来进行功能结构图或者信息结构图的发散、收拢。 就可以将优惠券功能填充完整。 对于功能结构图与信息结构图的区别:功能结构图,是为了梳理需求,防止出现缺页面,缺模块的现象,以鸟瞰的方式对整个产品的页面结构形成一个直观的认识;而信息结构图,是要罗列信息,作为开发建立数据库的参考依据。 1、功能结构图(xmind) 比如针对优惠券功能,我们把主流程设计好了后,可以以下几步: 在思维导图中,先写出主流程,作为子主题,比如仍然是创建——领取——使用——查看 再进行每个模块详细的发散。比如创建优惠券,可能要设置相应条件、发放渠道。创建后需要进行数据查看等等,可以先广泛发散 进行连接:每个连接都是页面与页面的连接关系。为等会原型设计做准备。其实在功能结构图这步,下一步就可以按照功能结构图去绘制各个页面及页面间的关系了 2、信息结构(xmind或者Excel) 关于创建优惠券的部分信息结构。信息结构关注的是单个页面的元素,信息来源,字段限制等,而非结构化的信息,有时用表格来展示,或许会更加清晰。这个清楚的部分,就可以将其到时候放置到你的PRD中了 3、优先级及版本计划 优先级确认:可以根据重要、紧急程度确认优先级。具体不在此阐述,在此主要提出这个是为了说明,作为一个产品版本计划的重要性。需要用最小可行化产品,确认每一期功能、目标,层层迭代。同时在最开始的时候和团队成员达成一致,让开发、视觉清楚后面的计划,可以让他们在开发拓展新或者设计拓展性提前准备。这样他们会觉得你这个产品经理比较靠谱,更加有利于后面的合作 四、原型设计 1、手绘(铅笔) 可以在刚刚的思维导图基础上进行原型绘制,比如四条路径,每个路径具体细节和连接交互。基本思维导图边绘制时候,脑中原型基础可能也就出来的。 2、axure 使用铅笔绘制后再进行axure绘制,同样 搭左侧菜单框架(将页面关系先在原型中建立好)——粗的绘制板块——细节填充——异常流考虑 五、完成PRD书写 [...]

运营数据运用

作为运营设计经常会和PV、UV、转化率、点击率、曝光率、留存、DOSU、DAU、WAU等数据名词打交道(不了解可自行度娘)。数据指标是运营设计的命脉,在结果论的时代,我们该如何运用这些数据? 那么多数据,如何get关键指标? 当收集到的数据越来越多,很容易「数据迷失」,面对大量PV、UV等可视化数值时,却有可能找不到能促进业务增长的关键指标。虽然每个公司和部门的指标都不同,但是仍可用以下两种方法去进行关键指标的提取。 设置用户行为 设置 (首页→栏目A→参与→下载)类似的用户行为为转化路径,统计阶段时间内达成转化的用户数。不仅分析流量,更要深入分析用户。 成立关键指标组合 好的数据指标一定通俗易懂,且是一个比率,甚至是组合。 除了数据,你还要懂漏斗原则 从以上的漏斗流量(金字塔)图来看,分析每层漏斗的流失率,快速找到问题所在。比如活跃低了,那可能是渠道出现了问题。以此类推,找到该数据的上级就能快速解决这个问题。 流程是从下至上,而验证则是从上至下。 数据验证分析?该如何下手 度量:指量化的数值。一般都有个名称,比如网页浏览次数,网页浏览时长等等。一般我们会称之为“指标”,但是你需要知道,指标和度量还是有些差异,比如某些场合,他们会用指标特指一些经过计算的度量结果,比如拿度量A(网站总浏览次数),除以度量B(网站总浏览人数),得到一个新的指标(网站人均浏览次数),用以衡量网站粘性。但其实两者是可以通用的。 维度:指我们看事物的角度。比如,网站浏览次数(PV),我们可以从日期角度去看,也可从流量来源去看(来自直接访问的、来自微博的、来自搜索的等),也可以以新老用户分群来看。更多的场景是同时以两个维度的组合去看。 如何区分他们? 维度,一定是有成员值的,且成员值是可以枚举出来的——不管它有多少,一定是可以枚举的,且会维持一定的稳定性。 比如,日期这个维度,几月几号一定是有限的,一年也就365天,如果是年这个维度,也是一样的。城市这个维度更好理解了吧。 说的再细一些 度量:除了指标这个有着略略差异的俗称外,有时还会遇到衍生指标这个说法,比如拿指标A和指标B做运算得到的指标C就叫做衍生指标。此外,还要注意可累加以及不可累加的度量说法,比如网站UV(独立访问用户数),这个指标就是典型的不可累加的度量:某网站1月1日UV=100个,1月2日UV=200个,但是这两天的UV不等于300个,因为1月2日的独立用户数里可能包含了1月1日的用户,所以如果要得到2天的UV,需要重新计算而不能直接相加。 维度:有些维度是独立并列的关系,比如城市维度和时间维度。但是有些维度之间有层次关系,比如省份维度和城市维度,行业维度和类目维度,年级维度和班级维度等。有层次关系的维度,则可用于“钻取”场景中,先汇总到比较粗的维度,当有需要的时候,可以层层钻取到更加明细的维度,此时,也会把这些维度叫做某维度类型的不同“粒度”——比如会有一个虚拟的维度类型曰地区维度,而把省份、城市、区叫做地区维的粒度。维度的层次根据不同的需求,可能会钻取到很细,那就是通常我们说的”明细数据”了。 案例分析:实际环境 从导航格局来看,专题预估会是一个阶梯式的流量(做任务[页A]>吃火鸡[页B]>抽大奖[页C])。事后发现并不是阶梯式流量的流失,而是瀑布式的。真正全部浏览完成的用户比例非常低,大部分用户停留在页A。这个问题非常严重,需要解决它。 按漏斗原则来看,二级页面倒流出现问题,我们需按向上验证原则。找到问题源头。(导航是不是出了问题?一级页面内容是否合适?) 带着疑问,我们尝试改变看看! 突出倒流按钮,增强引导 隐藏内容,增加神秘感 增加交互动效,让整个专题更有趣 本次关卡一/关卡二/关卡三/抽奖页面PV为1.8 : 1 : 1.7:1.3。相比较之前Tab形式切换,每个子页面的流量均摊,流量承接提升4-10个百分点。 案例分析:选个老公? 当小贝与马云见面的时候,网络上出现了一个两难的问题:到底是选谁当老公呢?其实在这里,也可以用到维度和度量的方式。 维度:人 维度成员:马云、小贝 度量:财富、颜值,以及各自心目中各种权重、衡量的综合指数。 最后你会发现,这是一个两难的选择:小贝做老公,马云做爸爸。 结语 最后作为运营设计师,数据收集和分析的能力,可以更好的帮助成长。了解运营中遇到的问题,用漏斗原则(金字塔)找到问题,用维度、度量验证数据。从而更好的从运营的角度出发去做设计。美化视觉的同时优化交互与用户体验,提升活动效果、增长关键指标。

思考:产品定位对产品构建的影响

我们都知道,每个互联网产品都有其针对的和辐射的用户人群,这个都是基于该产品的定位而确定的。我们可以来探讨一下,产品定位对产品的构建会有什么样的影响。 问题:在微信和支付宝上分别发起一次10块钱的三人AA收款,微信人均收取3.34,支付宝人均收取3.33,你认为这是为什么? 该文章是由作者的朋友在微信群里向作者询问的这样的问题引发的一系列思考。(如下图) 因为当下以为朋友在写面试题,于是未经太多思考,紧急给了我的想法。 大致的意思是:支付宝产品定位是钱包,会更严格遵循数字规则,且避免陌生人间的转账因总额超出而引起不必要的误会。微信是基于朋友关系间的收款,相对会没有这些担忧。因此产生的收款差别。 那么,既然每个产品都有自己的定位,那么,产品定位对产品的构建会有什么样的影响? 一、概述 相信很多人都看过这个产品构建的金字塔: 从一个产品的构建来看,大致需要分为: 产品设计中的:产品定位、产品功能; 交互设计中的:用户体验、用户情感。 1. 产品定位 产品定位是在产品设计之初或在产品市场推广的过程中,通过广告宣传或其他营销手段使得本产品在消费者心中确立一个具体的形象的过程,简而言之就是给消费者选择产品时制造一个决策捷径。对产品定位的计划和实施以市场定位为基础,受市场定位指导,但比市场定位更深入人心。具体地说,就是要在目标客户的心目中为产品创造一定的特色,赋予一定的形象,以适应顾客一定的需要和偏好。 产品定位最主要的还是解决以下5个问题: 满足谁的需要?—-辐射的用户群体; 他们有些什么需要?—-用户需求; 我们提供的是否满足需要?—-能否解决用户痛点; 需要与提供的独特结合点如何选择?—-怎么和互联网相结合; 这些需要如何有效实现?—-具体实现方案。 2. 产品功能 很多时候,产品经理会将产品需求和产品功能混为一谈。 因为部分产品经理实际上是把用户需求建立在”自我认知”上,而用户的真实需求可能是很简单的。用户的需求可能是左边,而在部分产品经理的眼中就变成了右边。 作为产品经理,必须挖掘功能背后更深层次的需求,在设计产品功能时,适时对产品的功能做减法。把握最核心的需求,尤其是人性的需求(以后有机会再深入的讨论这个问题)。 3. 用户体验与用户情感 用户体验与用户情感是在产品定位与功能确定后,产品的一种更加具象的表现。 它们很大程度上影响了产品界面的布局,产品的交互风格,这部分内容将在下方的案例中再详细描述。 二、案例:支付宝与微信钱包 支付宝与微信钱包两款产品的核心功能就是成为用户的钱包,用以平时生活中的线上支付。 1. 产品定位 满足谁的需要?—-有线上支付习惯的用户; 他们有些什么需要?—-帮助用户更加方便的进行线上支付; 我们提供的是否满足需要?—-可以座位第三方的支付接入银行接口或通过自身产品的余额进行支付; 需要与提供的独特结合点如何选择?—-通过扫描二维码的形式进行支付或者转账; 这些需要如何有效实现?—-不加赘述。 可以总结出这两款产品是用户在需要线上支付的情景下,替代钱包进行使用的工具类型的产品。 2. 产品功能 我们不妨代入线下情景,将钱包平时的功能一一列举出来: 我们对产品的功能进行减法运算,摒弃掉一些功能点,得到核心需求: 买东西付钱、找零钱、存放银行卡、存放会员卡、存放身份证等证件。 3. 用户体验与用户情感 我们一起来看一下支付宝与微信钱包的首页的布局: 在两个产品首页的核心功能位置上分别设置了一下功能: 支付宝:扫一扫、付钱、收钱、卡包 微信钱包:收付款、零钱、银行卡 我们之前通过筛选得到的产品功能与两个产品首页的核心功能关系如下图: 两款产品都将页面最核心的地方给予了核心功能,微信的扫一扫和会员卡都在更上一级页面就已经得到了体现。而支付宝目前也已经在逐步开放公民身份证、驾照等信息的电子录入。我想,在不久的将来,这两款产品可能真的会完全取代我们的钱包。实现他们一开始的产品定位。 在交互上。两个产品均没有采用复杂的交互动作或动态效果。都只采用最高效的方式来让用户进行操作,省去用户等待时间的时间,这是作为一个工具类型的产品应该把握的。 三、总结 产品经理应对自己所负责产品的定位和所辐射的用户群体有清晰的认知。关于产品定位的5个问题心中能够有明确的答案。 [...]

产品需求:你真的了解你所看到的需求吗?

一个产品经理和功能经理的区别,是产品经理眼里看到的是情感需求、人性需求,而功能经理看到的是只是功能。   作为产品经理,必须挖掘功能背后更深层次的需求,在设计产品功能时,适时对产品的功能做减法。把握最核心的需求,尤其是人性的需求。 我们来做一些更深入的探讨。 产品经理最基本的能力就是挖掘需求。看上去好像很简单,然而实际上,很多产品经理都做不好这一点。 案例 1 我们来看一个例子,平时生活中我们都发过红包,那么产品经理该如何满足用户需求呢?好的产品经理会用最高效的方式去满足用户的需求,专心的去打磨核心功能。 然而也会有部分产品经理,我们姑且称之为“功能经理”,他们不断给产品增加新功能,他们不断的想让功能看起来酷炫而不是简单易用,认为这样就能够满足更多的用户需求,让受众面更广: 以上是最初的微信红包和支付宝红包,你会更喜欢哪个? 为什么会有这样的差别? “功能经理” 实际上是把用户需求建立在”自我认知”上,而用户的真实需求可能是很简单。用户的需求可能是左边,而在 “功能经理” 的眼中就变成了右边。 当然这样的例子还有很多,比如应用宝: 又比如百度贴吧: 应用宝是社区资讯类型的应用,却加入了同城服务,语音聊天室等功能,虽然在消磨时间这个需求上或许有一定的共通点,但是明显这不是核心功能。 或许出于效益、KPI等原因老板要求一定要加入更多功能,但是正因为如此,我们才要更加用心去打磨核心功能,让它更加出彩,而不是被模糊了焦点而失了产品最初的定位。 作为产品经理,要明白两个重要的道理: 产品经理,是要永远和用户站在一起的。只要做对用户最有利的产品,最终一定会得到用户的回报; 用户需求不等于功能,不能把功能当做需求。 把功能当需求有一个严重的后果——就是眼里只看得到功能。但实际上, 用户的需求远远不止于功能。 案例 2 现在不少人都会购买健身卡,加入到健身的大军当中,那么购买健身卡的需求到底是什么呢? 这里就要介绍一个方法了,不停的问为什么,当你看到一个需求往连着问3-5个为什么的时候,一般就能找到核心。 那么我们来实际操作一下,看看是怎么样挖掘核心需求的: ① 为什么人们要去健身? 答:满足用户的健身需求达到塑形、增肌、减脂的目的; ——满足用户个性需求 ② 为什么人们要塑性、增肌、减脂? 答:这样可以让用户通过发朋友圈营造出积极健康的社会形象。 ——满足用户社会象征需求 ③ 为什么要营造积极健康的社会形象。 答:让用户消除对自身形象的焦虑,增强自信。 ——满足用户情感需求 作为产品经理,必须挖掘功能背后更深层次的需求,比如心理需求 (Psychosocial Demand)。你可以发现,用户购买一个健身卡,绝大部分不是为了功能利益,而是为了心理利益,而这种心理利益又包含了社会象征、个性象征以及情感利益。 (1)个性需求(Personality Demand) 健身卡可以帮助用户塑造个性自我,这种自我不仅是对外的展示,还是自我暗示:”我买健身卡,说明我就是一个健康向上,阳光开朗的人。” 比如当年的企鹅QQ秀,也是在充分满足用户的个性需求。 (2)社会象征需求(Social Status Demand): 健身卡可以帮助消费者塑造社会形(mian)象(zi)。这可以解释为什么很多人买了健身卡就不去健身了,因为他们买健身卡本来就不是为了健身,而是为了发朋友圈的。 你也可以发现很多类似的产品,比如手机,作为最具外显性的电子产品,满足远远不只是功能需求,更重要的是社会象 (Zhuang) 征 (Bi) [...]

3分钟读懂大公司的“高效沟通”套路

有人的地方就有江湖,有江湖的地方就有自己的规矩。 新人小白初入职场的一段时间内会发现,最头疼的问题不是技能上的问题,而是沟通中遇到的问题。对于新人来说,没有人脉没有资源,当真正有业务需求需要推动跨部门人一起帮忙推进时候,就变得非常困难了。概括起来,一般会遇到几种情况: (1)前期分工不明确,大家的利益共识未达成一致 一个新项目的启动就常常会因为前期分工和利益不明确而导致项目后期沟通成本的增加。这样子难免自己着急要死的事情,到对方那里只是芝麻大小的事 (2)需要对方部门协助支持,但对方不乐意帮忙 有些项目在对方眼里看来吃力不讨好或者没啥好处的事情,万一做砸了,还容易惹上一身骚;这个时候,就会能拖就拖,方案来回过个几遍,一两周时间就过去了;活动可能就会最终不了了事== (3)对方部门对你提的需求不看好,但是又无法明面上非常直白地拒绝你 比如你向产品提个活动,对方不看好项目,这个时候就会先让告诉你,你先出完方案,来回改个几遍,砍掉一些需求;然后差不多时候出个PRD,最后需求评审时候,转告开发大佬的话,这个时间节点做不来,没有开发资源;(一口血喷出来) (4)部门关系不好或者对方觉得你的态度不好,又或者碰巧心情不好  这个时候,给你穿穿小鞋,就是不那么配合你咋地~我现在要开会哦,这几天有个大项目,反正各种特别正当的借口理由~ 沟通三步论 虽然职场中会遇到各种意向不到的坑,但是万变不离其中,还是可以总结一套适用的法子。 第一步:去沟通之前先思考几个问题 你想让对方帮你做什么事情? 这对他有什么好处? 他可能会提出其他什么要求? 如果对方不同意,有没有备选方案? 如果没达成共识,双方会有什么后果? 如果没想清楚这些问题,那先别急着去找人谈 设想几种可能的场景,准备不同的应对方案,必要时候也可以和老大争取帮忙协调一些资源。总之,在目标明确的情况下,尽可能的保证最终结果能完成,任务不要砸在自己手里。 另外,换位思考(同理心)这个职场必备技能之一,也是真的能够助你更好地理解对方立场以及许多对方没说出口的“潜规则”,例如产品同意了这个活动方案,最终开发不肯做或者没有开发资源,也不是他能决定的。产品如果不是和你特别一条心,这时候只会告诉你做不了(运营自己就抱着方案蹲墙角哭吧) == 第二步:带着尊敬友好不轻易撕逼的态度去沟通 当想清楚之后,也有几种应对方案,体会下“温柔而坚定”的态度,带着尊敬友好不轻易撕逼的态度去沟通。将希望对方做什么这件事情表达清楚,不隐瞒事实破坏信任关系,这次合作不成还有下次嘛~友好互惠,争取双赢~ 反正你总是会是有求于人或者寻求合作的,同事关系一定要搞好,礼尚往来,你帮我一下,我帮你一下,同事情就这么在一来二去中产生了,必要的时候上厕所递手纸、请吃饭能刷刷好感都是可以的~ 第三步:务必要邮件确认具体事宜,存档留底 当面、口头、语音沟通的统统不算,只认邮件正文;所以,正式的事情一定要以邮件形式确认,留档存底。 发之前,可以先私下沟通下,确保双方信息理解的完全一致,再发出来CC大佬们,也让他们了解合作具体的进度,心里有数;最重要是,出了差错,还可以找找邮件确认一下问题原因 == 踩坑血泪法则 说完了跨部门的的沟通基本三步论,接下来说说我自己切身经历从一个个血泪坑中趟过的经验教训,虽然看的一定没有自己领悟过一次来的印象深刻,但是大家进了职场能避免少走的一些坑,能少踩就少踩一些吧~ 1. 该配合演出的你,千万别视而不见 在跨部门的实际沟通中,也会遇到这样子的情况——紧急处理事故填坑、避免出现更大的损失时候又或者是任务时间有限情况下,自己真的急的要死、跳脚了。但真到了沟通的时候也要保持心平气和,保持平和友好真诚微笑,假装什么事情都没有,继续沟通谈判,推进项目。 虽然很考验演技,但也出于两个原因考虑:一个是为了不让对方看出来这件事情可能非常重要,拿捏住又或者刷脸时候签了个大人情。 另一个就是你的事情为什么让我也这么急?对方可能内心也很不爽,手上自己的事情也很多的呢,每次这么急的需求~究竟靠不靠谱!在公司被贴上不靠谱的标签,就真的会是阻力更大,尤其是产品经理被贴上这个标签,开发不理你,设计不爽你,运营觉得你是个坑货 == 2. 注重非正式沟通 企业内部沟通中,经常会分为正式沟通和非正式沟通,这里着重突出的是老板在的场合和老版不在的场合。 一般正式沟通主要是用在会议沟通中,那么在开会之前,对于比较核心敏感的问题,一定要在私底下先通好气。迫不得已的事情,再搬上台面来让老板们决定,总之会议上要尽量避免互相甩锅、职责的情况; 有时候虽然是同一个老板底下干活,但是彼此之间做的事情不一样,职位是平等或者略低情况下,遇到老板让你递个话给对方做XX项目时候,同时让你跟进进度、及时汇报,一定注意此时不到万不得已情况下尽量不要接!不然信息传递有误,对方甩锅,自己就得背着个大黑锅冤死。 或者提个建议,你和老板还有对方,三个人一起面谈下或者语音会议,由老板来把任务分配下去,你就负责跟进汇总下进度就好,这样一来不得罪人,二来对方也不至于最终有坑的时候,顺手将你一起带进去了。 如果真的要接,那就尽量先和老板沟通好具体任务细节,明确自己没有理解错误之后,再和对方先私底下非正式沟通,介绍一下背景以及具体任务。 当对方表示没有问题时候。再在建个微信群或者RTX群(邮件更好了),把具体的任务以文字版的方式明确一下,这也是为了将来有问题,不是你这边传递信息有误出错的; 如果对方在私底下沟通的时候,不接受有异议,你也可以先将事情交代完,然后再就事论事,给一下自己的建议,实在不行再让对方找老板沟通下。 3. 坚持跟进 前期铺垫了那么多,好不容易事情谈妥了,对方答应了,但是你没有跟进好,对方可能是出工不出力或者做出来的结果和你预想的差别千万里,而又没有时间来补救的时候,就会让自己变得更加被动。 所以,在事后也应该保持及时沟通,主动了解进度,询问对方是否遇到了困难需要协助等,提前预防问题的发生。 在这里也有另一个小技巧——及时和上司保持沟通、反馈进度。在上司眼里,虽然这个项目其中有部分需要别的部门协助,但整体项目还是你负责的,出了问题一定先找你。 所以,如果你千辛万苦地找到别的部门答应帮你完成这部分任务,由于没有事后保持持续的沟通,最终完成的效果达不到上司的预期,整体推翻,一切又要重头来过。 这时候虽然这部分不是你做的,但是上司一定会认为是你的执行沟通不到位,其他部门的小伙伴心里也会有怨言怎么不早说,还要改!下次你找他帮忙,一定会阻力很大。 4. 保持靠谱的积极正面形象 [...]