IT牛人博客聚合

常常会收到一些邮件，问题类似，就是说自己做互联网有段时间了想转行做产品问是否可以，如果要是转行做产品经理的话需要注意哪些东西，根据当前从事的工作还需要有哪些提高。给我写邮件的朋友描述各自当前的情况各有不同，但是归根结底的问题都类似，所以，我给归类拿出来回复一下。倒不是我懒，也不是其他的，只是觉得存在共性，为了减少重复沟通成本所以总结一下。当然，也欢迎继续深入交流

对于这些问题，我一般分成2个部分来回复

第一个问题是咨询转产品是否可以的问题。我的回答通常都很简单直接，可以，没什么不可以的！如果你想转那就立刻转，没有人天生就会什么，也很少有人能在职业开始的前3年就能准确的找到自己喜欢的且擅长做的事情。所以，喜欢就去尝试，尝试之后就可

查看全文: http://www.udpwork.com/item/7060.html

我有个习惯，每天晚上睡前会搜罗一遍最新的App用用。最开始的时候ios的App还相对比较朴实，强调功能的实用性，后来不知何故吹起一阵ios的App必须足够精美的怪风。于是乎，各类App纷纷上演换装游戏，一个比一个做的精美，即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……

比如，为了高雅和精美某个支付网站的首页上弄个美娇娘抱着个Mac电脑羞答答的盯着屏幕，可是实际上，这他吗的支付网站根本就不支持在Mac下支付……比如，某个旅游App最近升级之后也学人家增加了一个在页面加载的时候模态提示的效果，不过，一般人家都在这个间隙提示如何操作，有什么功能，这个App则在这个时候吹嘘

查看全文: http://www.udpwork.com/item/7059.html

大约1年多前我写了一篇《基于axure的PRD写作思考》，其主旨思想是将文档版本的PRD与线框图及流程图结合起来，统一由axure来输出，降低PM与研发之间的沟通成本及交付物的传递成本。

当时这个文档是基于我做Web端产品设计的经验为蓝本完成的，这1年多来我从Web端完全转到Mobile端，还在继续的使用着这套方法。在不断的实践过程中略有心得，遂更新一篇，详细的讲述一下这套思路。

当然，肯定会有很多人说axure是个很笨重的工具，从来不用；也肯定会有很多人说我们团队有严格的文档规范，你的这套东西不适用…..是的，你们都是对的。这套方法的最大好处就是快速、直接，适用于扁平化的团队。如果你是产品与研发异地的团队，那么，建

查看全文: http://www.udpwork.com/item/6828.html

知乎上有个问题，“微信有哪些功能亮点，为什么？”。热门的产品，总有值得学习的地方，开放式的问题，答的不好也不会被骂，所以我就回答一嘴。

当然，我并不是从一开始就使用微信的，所以，在回答这个问题之前我特意去查了一下微信的发家史（见本文最后）。然后，我惊奇的发现，微信其实是个定位“摇摆不定”的产品。1.0版本，微信定位于手机端文字通讯工具；1.1版本开始加入插件，基本冲着通讯中心去的；2.0版本开始往着多媒体通讯工具发展；2.5版本开始是陌生人交友；3.0版本后被官方重新定义为一个生活方式…..

然而，一路走来，不断的迭代不断的发展，这个产品的受众范围越来越庞大，价值也随之增加。过年的时候惊奇的发现一个年近50的叔叔使用

查看全文: http://www.udpwork.com/item/6750.html

写在前面：刚开始接触移动产品设计的时候对着设计指南懵懵懂懂的感知了一下，但是还是不甚寥寥。最近读《触动人心》，发现作者对ios的导航模式的总结实在太棒了，于是写下这篇读书笔记。

导航始终是产品设计的重头戏，往往产品设计中90%的事情就是在做导航。在iphone中预置了3种可以直接使用的导航模式，平铺列表、标签页、树状结构，每种模式都配有不同的工具栏和控件。三种导航模式可以独立使用也可以混搭，让你的用户可以优雅的穿行与你的应用之中。

（图片来源：Tapworthy）

平铺列表

这种方式主要用于只有一个主屏的简单应用。这种方式很适合浏览并发现类的应用，因为他的信息架构简单到极致，没有信息层级也没有组织结构，就像一叠卡片一样。主要

查看全文: http://www.udpwork.com/item/6113.html

按照我的理解，场景、任务、用户可以称之为设计的三要素，每一个设计实际上都是试图去帮助用户在某个场景下完成某个任务的。同样的设计遇到不一样的场景就会有不一样的方式，从Web设计到移动产品设计亦然。

曾经有个朋友问我，从Web设计到移动产品设计你感觉最大的差异点是什么？我觉得，最大的差异点在于用户使用场景的变化，场景的变化引发了交互方式巨大的变化，从而也使得信息呈现方式有所不同，再加上硬件设备的差异，最终使得2者千差万别了。所以，移动产品设计之设计应该首先从用户的使用场景出发，同时考虑用户的硬件设备差异，综合以上2点去帮助用户完成某个任务。

当然，从生态系统的角度而言，移动生态系统也是迥异与互联网生态圈的。移动生态系统可想象成拥有许

查看全文: http://www.udpwork.com/item/6027.html

在产品设计的路上一路走来，经历了几个阶段：初入行时奉很多东西为圭臬，因为然，所以然；之后慢慢深入开始想为什么是这样而不是那样，对已经这样了的产品也少了很多指责，更多的是探究其之所以如此的原因，知其然，知其所以然；再后来是，知其所以然之后不禁叹息，如果努力是否可以做的更好，是否能够解决障碍呢？知其然，使其可以然。

1年前我曾经写了一篇《我理解的产品经理》，当其时深洋洋洒洒数千言以充满理想主义的呐喊居多，也没有什么体系，只是想到哪里就说到哪里，虽说法都无甚错误但是总觉得落不了地….1年之中结结实实的锻炼了许多次，经历一个产品从无到有、从上线后遇到瓶颈然后推翻从来找到一个新的方向。在这个过程中，有团队之间的磨合，也让自己学习

查看全文: http://www.udpwork.com/item/5598.html

基本上，熟悉我的人都知道，我是个低俗的人。然后我最擅长的事情是用黄段子举例子讲道理，这点看过我的文章的人都知道。倒不是我拿低俗说事儿以为低俗有多牛逼，而是我的经验证明，妈的，黄段子比较能让人记忆深刻。前2天我正在微博上严肃的用一个段子很正经的在讲述文案的重要性，然后坏人把这个段子复制到了UCDChina的群里，之后这帮人就开始了黄段子与用户体验的讨论…..我总结一下，列到博客里，虽然白鸦在微博上已经发了一部分

关于文案的重要性

某日尿急，遂窜进一家酒店豪华卫生间。走进小便斗一看，上贴几个大字“不要用坏了！”，我心中轻笑，我等素质人士，受过高等教育，天安门前拍过照，五星饭店睡过觉，什么场面没见过？事毕，自动感应，自动喷

查看全文: http://www.udpwork.com/item/5154.html

只是说一个在手机端小的交互细节而已。

在Web端做表单设计设计师考虑更多的事情是表单的布局方式、表单的提示语言、表单的长度、甚至表单的判定状态。这些东西有无数的人写了无数的文章。但是在手机端，对于表单的设计似乎没见太多的讨论。即使有讨论，设计师们也把目光集中在了如何精简表单上，但是对用户输入的关注却很少。

在移动端产品设计上，一个应用是否足够友好不仅仅取决与其自身的功能对用户是否足够友好，而也应该考虑这个应用对其他应用是否友好，当用户在调用这个应用去完成其他应用的时候他们是否会发生冲突。

得益与android生态的足够“开放”，android上存在着很多输入法应用；受利与android系统的足够“包容”，android上的输入

查看全文: http://www.udpwork.com/item/4951.html

在最早的时候产品设计大多采用瀑布模型方式做迭代，上一个流程完毕之后才进入到下一个流程。这种模式有一个最大的好处就是下一个流程的准备相对充分，但是缺陷也显而易见，那就是迭代成本太大且显得笨重。随着互联网行业的发展，“快”成了这个行业最重要的一个口诀，于是类似“唯快不破”成为大受追捧的产品设计哲学。于此同时，很多项目的设计周期被缩短。

在这个快字的指导下我们省去了对详细MRD的撰写，采用了列出功能点的方式向研发团队讲述整个产品的逻辑与核心需求点；因为要快速，所以我们采用初略原型的方式直接像工程师展示我们需要的产品架构和页面逻辑；因为要快所以产品人员在描述的时候很激昂的描述了我们要做的高优先级系统，并且说这些系统是我们最至关重要的地方，

查看全文: http://www.udpwork.com/item/4934.html

以下，是我在知乎回复的一些问题的备份，记录于此，无他。不过，需要申明的是，这些都是我自己的理解和某些理想状态下的答案，肯定是有错误的地方的，想挑刺的就别看下去了，想探讨的欢迎留言。

问：产品经理的核心技能是什么？

答：我认为一个真正的产品经理应该是这样的：发现用户的需求并定义客户价值，同时准确传递这个需求与价值给团队成员，并推动团队去很好的满足这个需求最终将价值传递出去。所以，核心能力显而易见了

 

问：产品和运营的关系是什么？

答：我从一个产品设计师的角度来理解一下这个问题吧。

产品设计与产品运营之间的关系应该是，如果这个产品没有产品运营，依靠自身的产品设计用户一样可以玩的起来，在设计的时候就需要考虑去搭

查看全文: http://www.udpwork.com/item/4612.html

一直以来产品经理与交互设计师之间的话题不断，有人认为交互设计师可以算上是半个产品经理，也有人认为交互设计师的生存空间太过狭小，基本成了一个破画图的，等等说法不一而全。之前，我写过2篇文章大致来表述对于两者之间关系的我的一些观点，在“我理解的产品经理”中我认为产品经理需要同时关注产品设计、工程技术、产品运营3个方面；在“基于axure的PRD写作思考”中我简述了在没有交互设计师辅助的情况下产品经理如何做一个更像样的“破画图”的。今天，结合最近的一些项目经验，总结一下产品经理如何更好的跟交互设计师合作。

首先，我理解的交互包括2个层面的交互，单页面的交互和系统层面的交互。单页面的交互是最常见的对交互设计师的定位，比如把一个注册和登录页

查看全文: http://www.udpwork.com/item/4147.html

首先，写这篇文章的一个重要性的冲动诱因在于我这个刚入行的移动互联网产品设计新手在查找资料的时候被太多的前辈恐吓了很久，我最终决定站出来反击一下。

我们看到无数的移动互联网前辈们说，移动互联网产品设计相对于Web设计而言实在太多限制了，太难搞了。你看，屏幕就那么点大小，当Web端主流分辨率停留在1024*768的时候手机上主流的分辨率确还是240*320（注意我是说主流，别说iphone4的640*960）；我们可以在Web上使用鼠标+键盘来顺畅的浏览而在手机上只有键盘（触屏目前还是灰主流吧）;当Web设计已经花哨到泛滥的时候手机上还是个梦想…..好吧，够了，够了，实在是够了

可是事实是这样吗？我不认为！我认为在手机上

查看全文: http://www.udpwork.com/item/3608.html

写在最前面：任何工具都容易造成沉迷，Axure也一样；沉迷工具有害健康，过渡钻研Axure不利于职业发展！

1、什么是变量

变量的全称应该是“中间变量”，变量用于在HTML原型中进行点击时的页面之间的传递和存储数据，这样变量能在页面之间保持下去。Axure文件中可最多使用25个变量。变量可以在交互设计和逻辑条件中使用。

简单说就是，在2个页面之间添加一个桥梁，用以延续交互动作。这个东西最直观的理解就是我们在做几何题目的时候通常需要在2个条件之间再取一个中间的条件，最后达到证明这2个条件是一致的，如：a=b，b=c，所以，a=c。

在Axure中可以通过“线框图”（Wireframe）——“管理变量”（Manage Varia

查看全文: http://www.udpwork.com/item/3041.html

作为工具，首要的条件就是高效率。高效率的解决问题，高效率的传达，高效率的记录，等等。Axure之所以被称作“快速原型设计”就在于他能高效率的完成原型设计并高效率的传达。而这一切得益与axure的“复用”思想。在Axure中的复用包括2个部分：组件的复用、模块的复用。

先温习一下在axure中什么是组件什么是模块，高手请直接跳过：

组件（控件）是用于设计线框图的用户界面元素。在组件（控件）面板中包含有常用的控件库，如按钮、图片、文本框等。从组件面板中拖动一个控件到线框图区域中，就可以添加一个组件。组件可以从一个线框图中被拷贝(Ctrl+C)，然后粘贴(Ctrl+V)到另外一个线框图中。组件面板工具栏中可以加载已有组件库、创建新组件

查看全文: http://www.udpwork.com/item/2681.html

前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了……

首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。

1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。

2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。

第一种流派是目前几个大公司的产品

查看全文: http://www.udpwork.com/item/2349.html