产品运营的思路

一直做产品,从未做运营,但这并不妨碍我谈谈对运营的理解。因为在互联网领域,产品和运营都是相通的,产品是要给用户提供价值,运营是让用户认识这种价值,它们相互依存,战略目标是一致的。任何运营都围绕“用户”展开,包括“吸引用户”和“留住用户”,说白了就是:让用户过来,并留下继续阅读

Balsamiq Mockups完全手册

什么是Balsamiq Mockups

Balsamiq Mockups出自加利福尼亚州的Balsamiq工作室,创始人Peldi在2008年6月推出了这款手绘风格的产品原型设计工具,并广受好评。2年多来,Balsamiq工作作为一个微型独立软件开发商,专注于Mockups的开发设计,仅3周便实现了盈利,18个月内销售额达到200万美元,用户端数量超过10万个,这与Balsamiq Mockups的市场用户细分的成功以及产品特性是分不开的。

 

继续阅读

关于互联网产品管理与产品设计

关于互联网产品管理和产品设计,曾一度有些迷茫。虽然一直沉淫于产品设计和用户体验,但确实也做了很多产品管理的相关工作,并且这部分“沟通”的时间所占自己工作的比重也在逐步加大。而除了互联网产品设计外,产品管理更是涉及到了软件/互联网企业经营的方方面面:

继续阅读

百度老年搜索推出手写输入功能

今天是重阳节,也是老人节。百度选择今天正式推出了新产品“百度老年搜索手写输入”。

老年搜索手写输入功能

记得09年4月百度推出老年搜索时谩骂声一片,如今百度与在中文手写领域造诣颇深的汉王达成战略合作伙伴,借重阳节的东风,推出方便老年人的手写功能,意在拓展用户,巩固中文搜索霸主的地位。

手写输入的意义在于,很多老年人不会使用键盘打字。60岁以上能够使用拼音或者五笔输入法打字的老年人准确数字无从查起,但我认识的除了大学的教授外,身边的几乎凤毛麟角。乐观的估计,10%的老年人能够正常使用电脑键盘打字。而目前,我国的老年人数量是1.7亿。面对如此庞大的市场,也难怪百度如此上心了。

当然,有了产品是一回事,好不好用是另一回事,那些老人到底有没有兴趣使用就是更关键的问题了。而这一点恰恰是需要我们年轻人去鼓励和推荐的。但面对层出不穷的网络诈骗、虚假广告、垃圾信息,在如此混乱的中国互联网环境下,你有勇气向你的爷爷奶奶推荐使用互联网么?

网络虚假广告

其二,老年人上网面临的问题还很多,对电脑和网络的恐惧和排斥是需要慢慢解决的,对如何开机如何上网这些很简单的操作也是需要不断熟悉的。这并非一个手写能解决的问题,不过手写功能至少降低了老年人上网的门槛,循序渐进没错;

最后,这里的“手写”实际上是使用鼠标在显示器上写。对于不太会使用鼠标或者手一直在抖的老年人来说,依旧不是很方便。如果使用类似Iphone那样的触屏或许会方便很多,当然笔记本自带的触摸板也不错,但是这是硬件问题了。手写解决的根本问题是将信息的录入生活化,把人机交互从“语言-代码转换-语言”变成“语言-(后台转换)-语言”的过程,你不需要知道怎么去转换,生活化的去表达即可。说话、写字、闻味、品尝、感觉……实际上可以做的太多了,这也是信息技术的一个发展方向。

实际测试,百度老年搜索的手写功能识别率很高,这得益于百度与汉王的合作。但搜索框偏小,最关键的问题是,用鼠标写字太TMD不爽了…….

老年搜索手写测试

我是做互联网产品的

毕业工作后,亲朋好友碰头后必备的问题就是:“你是做什么工作的?”无论是QQ闲谈时或者聚会饭桌上,所有人都对这个问题乐此不疲,而每当我被问到时,总是不知如何开口表达。前些日子看到杏子的一篇“做产品的”,忽然觉得我也应该写写自己是做什么的。

半年多前还在销售部门时,还能说“我在电子商务公司做销售”,或者“我是客户经理”,这都很好理解;而今在产品部门,说“我是做互联网产品的”,对方都是一头雾水,瞳孔涣散,于是乎不得不花费大量口水去解释什么是互联网产品,回答的多了,人也懒了,便说“我是做IT的”,世界才清净下来。

关于“什么是产品”之前早已做过论述,而像Google搜索、Q-zone空间、网易邮箱、百度贴吧等等都可以说是我们非常熟悉的互联网产品。网络是这些产品的载体,而这些网络产品给我们的直观印象就是网站;网站是又是产品与我们之间的桥梁。这些网站为我们提供服务、信息、平台;而我们登录并使用这些网站,来满足自己的某种需求。不过,作为用户,我们接触到的网站只是网站整体的一部分,也就是视觉呈现以及信息呈现的前台部分,而后台部分通常是我们无法接触的。大多数商业网站由互联网公司运营,那么,这些公司是如何创造并管理一个网站的呢?这里引用千鸟的一副互联网设计参考图

互联网设计参考图

其中,网站设计开发流程如同流水线,是网站的实质建设过程,而我主要负责概念阶段以及设计阶段。回到图最下方的交付物,即工作成果时,我又出产过几乎所有的可交付物:从用户建模到设计文档(如PRD)再到产品原型,这近一年的时间基本走了一遍,负责过两个项目,却并未涉及到技术相关的编码阶段,其实这些职能也是绝大多数互联网产品从业者非常熟悉的。至此,回过头看我扮演的角色,发现产品经理、产品设计师、产品工程师,都占了一部分,却又都未深入到前端,所以,我目前是“做互联网产品的”。

至此,我是干什么的相信你已经了解的七七八八了,可实际上,我做的事情还很多,每天通过RSS订阅来获取互联网资讯以及业内信息是必备功课》点击查看我分享的文章《,或者胡思乱想用户体验之类的东西,其他时间不是做项目就是做网站运营支持,如信息的自动采集和签发,分词系统词表维护……不过,研究用户,发现需求并研究和设计是我工作中不变的主题。

作为一名在互联网产品行业的从业者,我经常被朋友们误会成“做网站的”,或者“网站设计”,于是常有人找我帮忙做个网站…实际上我还远远达不到手写代码的程度,对div+CSS更是一知半解,最多就是利用开源的wordpress做个博客,这不得不说是个遗憾。不过,是能否做好本职工作,并专精与产品领域,与是否能做网站前端没有直接关系。毕竟我是学物流,学采购与供应链出身,与目前工作的交集实在有限;所以也经常有朋友问我“为什么做这个?”或者“你这个工作跟专业有什么关系?”我可以说:

1、专业涉及电子商务,我们就是电子商务公司
2、专业方向为采购,招标是采购形式之一,我们公司主要做招标信息
3、研究供应链,熟悉ERP,ERP是节流,CRM是开源,我就是因为公司要上CRM,我本身又有销售经验,所以我就来做产品了;思域的这幅互联网产品经理职业规划图很好的说明了这个问题:

互联网产品经理职业规划

记得之前在产品经理联盟看过一个专题,研究“产品经理应该从何而来”,结合上图看,我貌似从营销到运营到产品实现都占了…只是不知道什么时候才能做上经理罢了。不过在互联网行业产品领域摸爬滚打这一年,我也深刻体会到了其中的不易;该学的还有很多,时间总是满满的,但每天都有一点进步,或许真的比什么都开心吧。不过只闷头干活是一个好员工,但远达不到优秀,所以借此文简单梳理了自己的部分工作,也回答了“我是做什么工作的?”这个棘手的问题。即便如此,我相信我还是没法跟父母解释清楚什么是互联网产品,初级用户距离互联网还是太遥远了。

我是做互联网产品的,我们这种人,天天泡在电脑前,或许是对自己身体的摧残;但我们相信,自己的付出终究能改变人们的生活方式,赢得你的微笑。

Axure 汉化下载

AxureAxure 是在 Web 产品经理中使用率最高的软件之一,主要作用是帮助网站需求设计者,快捷而简便的创建基于网站构架图的带注释页面示意图、操作流程图、以及交互设计,并可自动生成用于演示的网页文件和规格文件,以提供演示与开发。Axure 唯一的缺点就是对中文支持不够友好,除了输入汉字时会出现无法录入的问题外,最重要的就是它要求设计师们对英文有一定的了解。Axure 一直没有推出中文版,但今天我在 Just 平生一笑的博客发现一个不错的Axure 汉化包,便与需要的朋友分享。

需要注意的是,这个汉化包仅对 Axure RP 5.1.0.1699版本有效,其他版本可能会引起 Axure 无法启动的问题。(Axure最新汉化版请参考文章结尾提示,会不断更新。)

Axure 5.1.0.1699汉化包下载页面(点击直接打开,下同)

Axure 5.1.0.1699软件英文原版下载页面

Axure 5.1.0.1699注册码:
Name:3ddown
Serial:FiCGEezgdGoYILo8U/2MFyCWj0jZoJc/sziRRj2/ENvtEq+7w1RH97k5MWctqVHA

汉化包使用方法:解压缩后的 Client.dll 文件放入 Axure 文件夹,覆盖同名文件即可。

此版本的Axure汉化质量不错,经过多人测试均能正常使用,重点是交互部分的汉化,对英文不好的朋友会有很大帮助!链接经测试均可下载,如果无法打开下载链接,请及时通知我。

注意:Axure最新的汉化版本为AxureRP 5.5.0.1945(点击进入),由于5.1版不兼容5.5,请及时更新到最新版本确保正常使用。

PRD中写用例的注意事项

产品需求文档(Product Requirement Document,PRD)在 WEB/软件项目中的作用不言而喻,一份好的 PRD  能够使整个项目事半功倍,因此花在 PRD 上的时间成本通常也是非常可观的。我见过几个内部需求项目,PRD 的 word 文档竟然也有几十M之巨,产品需求人员在其中所耗费得精力可见一斑。

chinapm 中汤圆将 PRD 的核心概括为

该文档中,侧重的是对产品产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。

而 PRD 中这个“详细”和“量化”究竟到什么程度,是产品管理者经常遇到的问题。一方面,如果 PRD 中的需求描述或用例说明没有具体到具体细节操作,一旦开发人员理解有误或不完整,则会对出现不断的变更或返工(通常,开发人员喜欢闷头开发);另一方面,如果将 PRD 内容描述得过分细致,则又会出现很高的成本,何况百密一疏的情况也是非常多见的。如何解决这个问题呢?

编写有效用例》一书中提到了描述事件流程的基本方法,不论具体的用例是由需求人员做,还是技术人员做,都是需要了解的。对于用例中的 include 部分一定要细致入微,而 refine 部分则可以分清优先级考虑。

include,表示你要在一个用例当中包含另一个用例,并且被包含的用例是必须的,如果缺少被包含用例,则主用例就不能完成。比方,在用户管理场景中,要删除一个用户,你必须先查询到该用户,然后再点击删除。那么查询用户用例就是删除用户用例的一个include用例。
refine,是指对一个用例更精细化的描述。精化过程不会改变原来用例要包含的内容,只是更加细致。比方,取钱是一个用例,在描述用例场景时,你会用核对帐号,效验密码等活动来描述取钱的场景。在概念分析时,你可以把核对帐号,效验密码等定义为用例来描述取钱的过程,这时核对帐号,效验密码这些用例就是取钱的一个精化。它们实际上描述的仍然是取钱这个过程,但是取钱在概念阶段被精化成了核对帐号,效验密码等粒度更小的用例,这此用例仍然需要描述用例场景,例如核对帐号的过程、效验密码的过程等。
这些精化出来的用例向上要能够满足取钱用例场景的需要,向下则要更进一步能接近系统分析所需要的粒度。
同样的道理,如果需要,核对帐号,效验密码等用例在系统分析阶段还可以再次精化。但是它们虽然改变了名字,所描述的内容也从业务描述精化到了系统交互,但描述的仍然是取钱这一个业务。

当然,最重要得依旧是团队合作。在项目运行中,可能发生任何事情,但只要大家做好沟通,没有什么问题是不能被解决的。coffeewoo 中有篇关于这方面的解答非常经典,我就不班门弄斧了。临近春节,快递都放假了,不然也想尽快拜读一下他的大作《大象–Thinking in UML》。