标签归档:产品经理

当谈论大学生就业时,我们在谈论什么

040ce4174ae2b83eef7da52a46bf50c9_b

  这期非你10月4日播出后收到了很多朋友的疑问,纷纷发来了证实信息,可见面对大学生就业,特别是现在的大学生毕业时的薪水超过当年的自己,有多少人是愤愤不平的,写下这些,也算是对他的激励和鞭策。

一、关于能力

  产品岗说简单不简单,说难也不难,但对综合素质和个人的思维逻辑能力以及沟通能力都是要求较高的岗位,一个大学还没毕业的学生,在学校能够自己独立担当一个项目的leader并且能够有思路、有想法、有执行的将一件事情进行下去但从这一点就值得鼓励,那个思维导图其实我并没有细看,因为我们不能从一个有工作经验、有多年工作经验的人的角度去审视他,能将自己的想法逻辑清晰的展现出来这一点已经及格,至于思维导图内容是否正确,并不重要。 继续阅读

产品经理应该先写需求文档还是先画原型?

模型:对产品形态结构的梳理,包括功能模块,逻辑关系,信息架构,业务流程等,可以用脑图,use case图,业务流程图来表示,根据不同产品,产出物的侧重点不同。但模型很必要,是可以帮助产品经理将一个想法,或是脑子中的模型梳理清楚,在做这些工作的同时,可以及时发现自己没有想清楚的细节,这些是指导后面产品设计师(或产品经理)进行原型设计的。同时,描述模型的产出物可以做为传递,帮助别人理解你的产品形态。
软件:MindManager,Visio

原型:即画出产品layout,即不包括界面设计和视觉元素在内的产品细节形态的线框图,包括导航逻辑体现对应的信息架构,交互流程,页面布局,功能任务点,页面(流程)跳转逻辑和较为明确的文案设计等。一个高保真的产品原型,不仅是所有的完整的“线框图”,还同时要有对应的注释内容,很多产品设计师(产品经理)不注意这一点,没有注释内容一样不利于传递,因为原型除了在做用户测试外,还是要给界面设计师和工程师看的。
软件:AxureRP

PRD:即我们说的产品需求文档,这个东西在快速发展迭代,产品导向的互联网公司中的主要作用是存档,备案和忽悠大老板。他主要是由上面两个部分组成,要说再重要的就是加上一些前期调研的内容,比如用户调研结果,竞品分析等。如果你的模型和原型做的足够明确,你会发现,工程师或是界面设计师跟本不会去看PRD。产品评审的时候,你打开一个30页的word文档,第一页是目录,第二页是行业背景……你不觉得这是耽误大家的宝贵时间吗?
当然,不能否认,写出一份规范高质量的PRD也是产品经理的基本素质之一。
软件:Word

产品狗的挖坑与填坑

  看到一篇关于产品从业人员入门级指南,不完全认可,但觉得写的还不错,以下内容为转载,原文地址:猛戳
  最近公司产品业务调整相对比较多,人员变化也有些大,或多或少都会有一些残留问题,在处理过程中就会发现别人挖的坑,埋的雷,于是就要排雷,填坑。当然了,自己有时候也会挖坑,埋雷。其实我们不想挖坑,我们只是互联网的搬运工。

  当你经历过坎坷成长为一名成熟的『产品经理』的时候,回头看看走过的道路,原来有那么多被你亲手挖出来后又填起来的『坑』。我这里所指的『坑』不是一个贬义词,因为经历过这些『坑』的磨练之后,你会积累更多宝贵的经验。注意,我这里要说But了,在你没有填补好这个『坑』并且走过去的时候,你会因为『深陷其中』而异常的痛苦,甚至想要放弃,相信我,这些感受我也都曾有过,所以,我们今天来一起看看这些『坑』都是什么,如何避免,又如何后知后觉。
继续阅读

Axure Pro 6.5 for Mac安装包和汉化包教程

  最近工作繁忙很久没更新了,新的iMac安装各种必备软件,当然少不了Axure这个吃饭的软件,但发现网络上大多数都为英文版而且中文汉化包基本没有内容,有几个百度前面的都是要收费的,MD费了好大劲找到汉化包写这篇日志主要用来备份一下。

Axure Pro6.5 for Mac :点击下载
Axure Pro6.5 汉化包(win/mac):点击下载
Axure Pro7.0 汉化包(win/mac):点击下载
★ 汉化方法:

首先退出正在运行中的 Axure (如果您正在使用).
将 lang.rar 文件解压, 得到 default 文件.

★ Windows版
null

① 复制 default 文件;
②进入Axure 安装目录, 类似” C:\Program Files\Axure\Axure RP Pro 6.5″ 的目录;
③新建 lang 子目录并将 default 文件粘贴到该目录下即可
④启动 Axure 即可看到简体中文界面, 说明已成功汉化
注:如果仍为英文则一定是指定的汉化文件 default 位置不正确.

★ Mac版
null

① 复制 default 文件;
② 在 应用程序 文件夹里找到Axure RP Pro 6.app程序,然后右键选择“显示包内容”,然后依次打开Contents/Resources文件夹;
③ 新建 lang 子目录并将 default 文件粘贴到该目录下即可;
④ 启动 Axure 即可看到简体中文界面, 说明已成功汉化
注:如果仍为英文则一定是指定的汉化文件 default 位置不正确.

产品经理需求文档的那点事

  前几天有朋友问我需求文档应该如何写作?需要注意点什么?其实需求文档在每个公司和每个人的产出的都可能是不一样的,基本上没有固定的格式,如果简明扼要的概括就是需求文档把你这个需求描述清楚你想要什么就可以了。

需求文档注定是给所有人看的,它就是产品的定义。

  • 文档围观的人包括:你的老板(如果产品够大,还会需要老板的老板),设计师,工程师,测试工程师。有时还应该包括产品前端:如运营,销售,甚至市场部同事。
  • 在通过各方的评审和签字后,一般来说,这个文档就是一锤定音的事。若有更改,就是需求变更了。
  • 所以,在需求文档撰写前和撰写中,对产品方向和用户的把握要足够强,从产品目的,到每个链接的含义,都需要准确地定义。基本上,当你开始写文档时,应该万事俱备。一边想一边写,那说明你还没有想明白这个产品是怎么回事。
  • 在有些公司,需求文档会包括产品的最终设计界面。即在文档提交给大家围观前,产品界面已经确定完毕。

需求文档写作的一些建议

  • 格式无所谓。用WORD的多,HTML,在线文档都成,我还见过PPT写的!
  • 产品定义部分一定要详细描述。按功能模块写,跨功能的定义用流程和关系来描述。多站在用户的角度上,去定义用户任务,用户流程,页面逻辑关系等。
  • 使用准确的用语,注意边界情况。比如,一个文本框最多输入多少个字符?是阿拉伯数字还是皆可?超过字数会怎么样?
  • 多画图。把原型包括进去,或者把产品界面包括进去,不然就画出来。否则除了你,没多少看得懂。

比如现比较推崇的Agile敏捷开发,会更强短平快,削弱文档的沟通而加强团队的直接交流,简化流程,快速反馈,快速迭代等等。这种情况下,需求文档会极大简化,咱就不在这探讨了。

比较正规的文档目录

  1. 文档信息,版本记录,责任人等
  2. 项目背景,产品目的
  3. 文档约定(采用的标准,通用名词等)
  4. 可行性分析
    • 前期调研
    • 产品预期
    • 对其他产品的影响
  5. 产品定义功能详述(文档主体部分)
    • 功能模块
    • 用例
    • 用户流程
    • 数据需求
    • 业务规则流程
  6. 产品非功能需求
    • 对性能的需求
    • 安全性需求等
  7. 产品风险或潜在问题

这种文档现在更多的出现在软件行业和严谨开发行业,对于互联网而言已经慢慢简化了需求文档的冗余程度,只要这个文档能很清晰的把这个产品描述清楚就好。

如:微博上有好友推荐关系,需求文档中可以描述为

向用户A 推荐 用户B 为他有共同爱好的人,那么他们需要有>10个共同关注的人;
向用户A 推荐 用户C 为他可能感兴趣的人,那么他们需要有共通过的粉丝>10人;

  这两句话描述了微博用户推荐机制产品经理需要给开发产出的需求描述,也经常遇到会有开发问“他们之间怎么关联在一起”“这两个表不在一个数据库“等问题,如果产品经理是开发转型能提供解决方案并且时间很充裕可以协助一下,但大多数产品经理也许不会开发,所以这些问题开发要自己想办法解决,不要凡事遇到问题就找产品经理。产品经理也是人,不是神;

产品经理和工程师,如何与设计师一起工作

null

本文译自Facebook产品设计总监Julie Zhuo 发表于Medium的《How to Work with Designers》。以下为译文;本文转自公众微信:互联网er的早读课(zaoduke)

  多年前,我曾当过产品经理,然后是工程师,而过去七年我从事的是设计工作。每天我都跟担任这些角色的人一起工作,每一天,我对产品开发背后的责任、挑战和艺术都有新的体会。对于想要搞经楚设计这个奇怪、锐利、helvetica-typed 世界的工程师和产品经理们,这篇文章正是为你们而写。

若想使用设计师语言,请停止说那些指标的事,改聊使用者。

  其实大多数的情况下,「指标」跟「使用者」意思不会相去太远。举例来说,你或许是希望设定一个目标,让注册页面的转换率提高X%;另一种说法其则是:你想要扫除那些阻止使用者注册、使用产品的障碍。但是你看,「说法」在这里就变得很重要——让使用者更容易注册vs. 优化注册流程的转换率。前者谈的是对使用者的价值,后者则是公司为了成功所产生的需求。设计师做事的心态一般来说是比较偏向使用者这边。
继续阅读

电子商务网站帮助中心的设计思路

  近几日在设计帮助中心参加评审过程中遇到的一些问题,帮助中心到底是干什么用的?帮助中心应该帮助用户什么?帮助中心流量大了是否要充分利用起来?帮助中心是否应该增加UGC模块?这篇博文记录一下我对帮助中心的思考和设计过程,希望能对大家有所帮助,如果有不同意见欢迎指出和探讨。

#帮助中心到底是干什么用的?

  就目前各大网站帮助中心的设计帮助中心属于网站中重要的组成部分,但是在UE和UI设计的过程中全部都是弱化设计无一例外,帮助中心到底是干什么用的呢?我个人认为,帮助中心是在用户遇到问题解决具体问题而设计,并不需要像产品使用说明书一样大而全唯恐网站哪个功能讲解的不全面,目前帮助中心分为两大内容:1、功能类导航;2、使用介绍

#帮助中心应该帮助怎么帮助用户?

  就目前使用习惯来看,帮助中心大多数适用于互联网初级用户对特别是电子商务网站对网上购物不是很了解或者该网站的整个购买流程很特殊需要单独说明,就我个人目前的使用习惯各大网站帮助中心我从来没主动进去过,那么对于互联网初级用户我们怎么能更好的帮助他们呢?

1、功能类导航

null

  用户在使用过程中想对整个购物流程中的某一个环节进行操作但又不知道这个功能在哪里,帮助中心首页起到一个很好的导航作用,如上图京东帮助中心首页,京东作为比较有代表性的B2C网站帮助中心的功能类导航就按照售前、售中、售后电商的三个基本模块来划分的,京东根据用户最关心的内容将这三个模块重新排序:第一列售后、第二列售中、第三列售前;

2、使用说明

  使用说明又分为两种,①操作流程类、②文字说明类。

①操作流程类
null
null

  主要讲解网站整个流程购买流程从注册到最终购买结束退换货等,如上图所示,京东帮助中心首页按照售前、售中、售后这三个顺序对网站操作类说明进行排序,对各个模块功能进行介绍,点击进去的介绍京东很直观用操作示意图直接展示没有冗余的文字介绍清晰直观,对需要使用帮助中心的初级用户很容易理解。

②文字说明类
null
null

如上图所示首先设计思路是支付宝这个功能需要具体说明又无法用一言两语概括,但又很重要必须要让用户知道这个功能或者这个模块是干什么用的,如上图所示支付宝余额宝的收益介绍,京东的211限时达

#帮助中心流量大了是否要充分利用起来?

  就我目前的观点帮助中心如果流量在网站有占比例就是这个网站产品经理的失败,就目前的产品设计主导思想如果一个产品不能马上让用户拿到手就可以轻松上手还要去翻帮助中心和说明书我觉得这个产品就是一个失败的设计,举例说明爱卡汽车,用户在使用时注册完全可以使用更智能化的方式,这种让用户亲自动手发送短信注册完全是多此一举增加注册难度这个功能比没有还可怕,并且用大量文字说明。(图片来自@寻少华的朋友圈)
null

#帮助中心是否应该增加UGC模块?

  有很多同学认为帮助中心有流量就要充分利用起来这部分流量,在帮助中心加入问答模块让用户创造内容将问答模块的内容丰富起来既可以减少工作人员录入内容的工作量又可以被搜索引擎收录增加流量,我的观点根据上面一个观点流量大就是错误的,在电子商务网站要让用户创造内容更是可笑,我们关注的UGC内容应该是如何引导用户在【购买后】进行产品评论,并不是在遇到问题时不是尽快帮助他解决问题而是让他用非即时的方式来提问,往往这个问题解决了用户也没有购买的冲动了,再则也许是保险类电子商务和其他产品不一样。

  最后,对于电子商务我也一直在摸索中,之前做社交类网站我知道用户创造内容对于一个网站需要付出多大的成本和精力,但电子商务特别是保险类电子商务我觉得一切不以促成订单为目的、提高转化为目的的产品设计都是耍流氓,以上个人一点小小的观点很久没发这种文章了,欢迎拍砖和探讨。

一个门外汉的产品设计漫谈

  本文纯属门外汉YY的结晶,如有低级问题,敬请行家里手批评指正;如果文中煞有介事得出的结论与设计学科的经典理论不谋而合,则不胜荣幸。本文目的是闲侃软件产品尤其是互联网产品的设计,多处以传统产品甚至不登大雅之堂的东东来举例,这顺带也在证明设计无处不在,以及软件设计与传统设计在理念和方法上融会贯通。

  设计无处不在,设计决定一切

  设计无处不在,人类世界是被设计出来的。如果你细心观察,可以在生活的时时处处发现优秀的设计及其蕴含的智慧。现在低头看看你键盘上F、J两个键上面的小疙瘩;笔记本电脑电源按钮(不是凸出的,而是凹或者至少是平的);鼠标的滚轮(没有设计成一个向上翻页和向下翻页的按钮);苹果笔记本触摸板的多点触控;衣服和包包上的拉链(容易拉开和闭合,密封性很好);还有天朝独有的防插队机(一举解决了从出口插队、在窗口簇拥的两大问题,简单可依赖)。

一个门外汉的产品设计漫谈

  防插队机

  然而,令人遗憾的是,糟糕的设计也随处可见。比如,初期的无线键鼠的信号接收器都是几厘米长,如果是配合笔记本电脑使用时,你必须经常插拔,因为它太长,当把笔记本放入包中时容易折到所以必须拔下来。更加不爽的是,鼠标上往往还没有收纳仓可以把接收器放起来,所以经常会把接收器弄丢。

一个门外汉的产品设计漫谈

  现在,短小精悍的接收器已经成了标配。

一个门外汉的产品设计漫谈

  天朝的很多办事流程也是糟糕的设计。比如,中国特色的“开证明”:假设你办理某证件,需要自己跑到到社保部门开具社保缴纳证明、去税务部门开具完税证明、去XX部门开YY证明……我不禁纳闷,你们在系统里面查一下不就知道我们是否缴纳社保、是否纳税了吗,为什么非要老百姓东奔西跑、非要把数据从系统调出并打印到纸上、盖上红戳方肯罢休?

  设计决定一切。先谈产品的初期设计,即产品的创意。就像广告创意对于广告营销活动的重要性一样,对于产品而言,产品创意也是具有决定性的。产品创意不好,基本上就不可能成功。而这个最初的核心创意,都是非常简单的、具有高区隔度的、一句话可以说清楚的。例如,简单地说twitter就是140字的博客、百度贴吧就是关键字社区、唱吧就是手机KTV。对用户需求的一个敏锐的洞察,就能产生好的产品创意,加上足够的研发和推广运营,就能够成功——这里说的是创新性的产品,而那些抄袭、跟风的产品要成功,最需要的往往是强大的运营、渠道和推广能力。

  大方向定好之后,就看产品的设计了。产品设计的优劣,很大程度上决定了这个产品能否成功,很少能有一个烂产品能够凭借出色的技术实现和市场运营手段获得长期成功的。何况,大部分产品并不是必须要有业界顶尖的技术才能开发出来。与产品对比,技术是可以被量化的,技术指标是有明确的技术框架和软硬件手段来改善的。比如,页面加载速度是1S,这个太慢了,我们可以很明确地把它优化到100ms。而产品设计是一个软性的能力,你很难说这个产品设计的合理程度是另外一个产品的几倍,或者这个版本的体验比上一个版本优化了几倍,因为设计带来的影响往往有滞后期以及其他因素的干扰。

  设计很重要,所以就需要找到合适的人,然而要觅得一个真正的产品设计师却很难。 继续阅读

产品评审上的些许事——需求评审

  作为产品经理其实工作中并不是画画图、想想点子这么简单,有些时候要去协调各个部门资源,有些时候还要用到社会工程学,有些时候还要用到公关技巧,有些时候还要用到人脉关系,在产品经理的主要工作中沟通能力和协调人际关系这些能力我觉得要占得比重不亚于产品设计,大多数公司工作职责并没有区分的那么详细,有时候甚至产品经理、交互设计、UI视觉都由一个人来完成也是很常见的(如我之前的公司)。
null
  选择做产品经理就要准备好每次产品设计完像大姨妈一样的需求评审,在评审过程中会有这样那样的问题,保持一个乐观积极向上的心态是比较重要的,在产品需求确定后进行需求评审,一般如果部门对你足够放权那么找开发、设计、运营、也许还会有运维、营销,的代表性人物参加即可,如果不够放权那么还需要一个能拍板的人,面对同样一个需求每个人的看法是不同的,做不同工作的都会从他们的角度给你这样那样的“建议”,但是由于每个人的沟通方式又不同,也许有人温婉、有人犀利,记得之前有人跟我说腾讯的女PM经常在需求评审(批斗会)上被说哭了。

  其实大家往往对你的产品指指点点,说东说西大家的目标只有一个就是把这个产品做好,并不是对你这个产品的否定,面对这样的评审会要保持一个积极向上的心态,当然激烈辩论和大声咆哮都是不可避免的,但是大家只要做到对事不对人即可,如果你不能调整好自己的心态(比如你是刚毕业的骚年)那么你就在评审之前想想党,想想我们的祖国,啊~顿时就会心胸开阔。 继续阅读