固定路径是个挺矛盾的词儿。

如果我们说一个人在解决问题的时候总是有固定思维依赖固定路径，大约不是一个好的评价。

但是在产品设计里，固定路径又是个很重要的原则。

比如我们耳熟能详的那个故事，一个设计师设计了一个公园，但是忘记设计小路了，开放了公园之后，游人进来，哐哐哐踩出一条路，于是，设计师就在这条小路的基础上做了些修饰，结果出奇的好。

比如我们常说工程师的桌子很乱，某个人的位置很乱，堆了很多乱七八糟的东西，但是，你发现桌子的主人要找到一个东西却很快。

因为，这里有一个最基本的设计原则，就是固定路径。固定的意味着习惯，习惯带来惯性，惯性让效率更高。所以一个聪明的产品设计师在设计一个产品的时候，不会经常去动导航，也不会经常去调整高频功能的摆放位置，甚至是使用流程。

在这方面微信简直就是样板戏。微信的基础信息架构基本就没做过任何改动，顶部的搜索、右上角的+、底部4个Tab，发了这么多版本，做了这么多功能，但是这个固定路径一直不做任何调整，我常常都觉得他们的设计师是不是个禁欲系的男人。

有一次，微信做了一次功能的路径调整，把群收款从群聊界面右下角的+移动到了首页右上角+的收付款里。

我开始是很不习惯也很不理解，后来我有点明白了。微信这个禁欲系的男人对「固定路径」这个思想理解的是多么深刻，在功能扩张上是多么的克制啊。

这个改动，其实是做了2个事情。一方面是吧同类的功能做了一次归类，把所有跟交易相关的场景都放在了收付款里，（红包其实不算是交易，更多是社交手段）；一方面是在刻意培养固定路径。

好处是培养了用户的固定路径和习惯之后，后面可以在这个收付款里叠加更多场景，同时，不会因为分散个不同的路径去而影响了其他功能的使用，不会打扰用户。

细思极恐，真正的高手。

禁欲系的产品里还有一个就是快手。我大概是16年开始关注这个产品，从16年的2月到17年的1月，他们大概发布了72个版本。所有Appstore的版本更新里，永远只有2句话：1、问题修复以及性能提升；2、优化用户体验。

在各路人马想尽办法在Appstore的描述里耍花枪的时候，这简直就是APP界的一股泥石流啊！

而快手的信息架构也是足够稳固，从不做任何改造，所有的改动都是基于固定路径来优化的，实属不易。

常常有人问，设计师做设计到底是在做什么，其实，设计师做设计就是在做建房子。建房子的第一个要素就是稳固，稳固的基础上在做去创新。

支付宝的产品设计，从来就没有稳固过。如果微信的产品设计主刀者是个禁欲系的男人，那支付宝的产品设计主刀者一定是个水性杨花的女人。

每次进入支付宝都要花几秒时间思考是不是打开了一个假的支付宝，判断确实是真的支付宝之后，再花几十秒思考那个按钮在哪里…简直就是你找了个女人，他平均每个月就要去韩国一次，月月都有新惊吓啊….

微信的固定路径思维和克制思维还有一个表现也很有意思。就连支付成功页面这种地方，微信都会很克制的不去随便增加元素。始终让用户的关注点放在我付了多少钱，是否付成功了之上。

或许对于一个好的产品设计师来说，首先得让新的功能有很好的可学习性，用户用很少的时间就知道怎么用了，然后，是不断的培养这种路径，让这个固定路径带来使用习惯，提升效率。

所谓，低频功能易学习，高频功能易使用，自勉。

产品这个角色，颇有些手艺人的意味。但是，从业者常常觉得自己是那个可以创造世界的人，往往喜欢开启上帝视角。

这就会出现一个很有趣的现象，每个产品似乎都喜欢搞点标新立异的事情，至少，看上去要跟现在的东西不一样的事情出来，好像这样才符合作为创造者这么一个形象定位的角色。

这常常让我想起来一句话，不要重造轮子。

维基百科上说，因为轮子自从被发明后，在使用上没有太大的缺陷，足以应付多数需求，原则上后人只需要直接应用即可，重新再发明一次轮子不但没有意义、浪费时间、还会分散研究者的资源，使其无法投入更有意义及价值的目标。

举个例子来说，如果产品的某个模块已经有相对成熟的方案，或者有一个覆盖用户群很大的产品做了一个相对还不错的方案，那么，完全没有必要在这个模块上浪费任何的时间去思考应该怎么创新。因为这种创新除了能稍微满足一下自己变态的创造成就感之外，没有任何收益。

做一个社交产品，登录模块直接照微信来一遍；做一个o2o产品，地址和购物车模块直接照着百度外卖/饿了么来一遍；做一个sku很少的产品的官网，对着早年的小米官网来一遍就可以了。

当你在可以使用轮子的地方使用了现有的轮子，你就可以有更多的时间和精力在应该创造轮子的地方去创造轮子。

那么，接下来就有2个重要的问题了，什么样的轮子算是好的轮子？什么时候应该创造轮子？

什么样的轮子算是好的轮子呢？我想应该有3个角度去判断，一个是它现在的使用体验是否很好，一个是它现在的受众群体是否足够大，最后一个也是最重要的一个，它是否是与你要服务的用户的属性是一致的。

作为一个支付流程，支付宝在早期有很大的受众群体，但是，支付体验并不好，有复杂的密码，支付密码，2个密码还不能一样，支付的流程也不简洁。那么，它就不是一个好的轮子，所以，微信支付做了一个新的轮子。

（详细可以看这篇旧文，及格的产品vs优秀的产品）

什么时候应该创造轮子呢？

如果你的业务跟现有的各个产品都不一样，那么，你找不到轮子，你好去创造一个轮子。即使你的业务跟现有的业务差不多，但是，你的用户群不一样，或者说你要服务的用户跟现在的大家都不一样，那么，你应该创造轮子。

但是，

不得不泼一瓢冷水，大多数时候，我们并不需要发明新的轮子，大多数时候，我们只需要找到一个好的轮子，然后对它做一些修补优化就可以了。

也许在创造一个新的轮子之前，我们更应该先考虑一下用户，场景，以及在现有条件下是否有可以借用的轮子。先找到一个可以借用的轮子，修补这个轮子，然后再创造一个新的轮子。

从使用场景出发，寻找用户需求，通过满足用户需求发现用户价值，使用系统性思维对用户价值进行梳理重组，这基本上完成了一个产品的循环。

但实际上，我们经常会面临到一个更高阶的问题是，用户有很多需求，满足这些需求都可以带来用户价值，这个时候该怎么做呢？

针对一个产品自身而言，可以采用核心用户、核心场景的方式来做提炼。简单说就是，做出用户的画像，对用户进行分类，然后把每类用户的需求进行描述提炼，最后找出其中的核心部分。

这张图是我们在很多关于产品或者用研的分享里会看到，是一个卓有成效的基础工具。

当我们面对一个竞争性的市场，在更负责的用户群面前，很多时候，需求会变成需求簇，我们可以稍微抽象一点，用另一个方式来解决了。

关于产品竞争的本质，大概可以用下面这张图来做个说明

用户的需求一开始是固定的，2个产品都可以满足用户的核心需求，但实际上，并不能有一个产品可以覆盖用户的全部核心需求，永远都会存在没有被满足的需求，这是产品竞争的起源。

2个产品在满足用户核心需求的同时，会做的事情是拼命挖掘用户新的需求，试图去将用户的核心需求做延展，进而形成产品竞争的壁垒，也就是我们说的创新。

我们所见到的全部关于产品的竞争、创新，新的产品机会的出现，大概都是这么一个基本的套路。

在这个套路下，产品的竞争就被抽象成为2件事情，一方面是如何更好的满足用户的核心需求，一方面是如何建立新的创新点。

在这里，我们可以引入一个新的概念叫做价值曲线。价值曲线是一个经济学上比较基础的理论模型，前几年流行的《蓝海战略》就是一本以价值曲线为中心来展开论述的书。

通过自己对行业与业务的理解，对当前我们所做的事情的用户关键感知要素进行拆解；就这些关键要素，针对自己和竞争对手进行打分；将分值连接成曲线；找到这条曲线中，我们可以突破的点，最终形成一条独特的价值曲线。

上面这张图，是比较马后炮的观察竞争与淘宝的产品竞争策略，画出来的价值曲线图。

就电商产品而言，用户的关键感知因素包括商品是否够多（SKU）、价格、品质、网站美观度、支付易用性、客服态度、配送速度。

画出2条曲线，形成的阴影部分就是价值差异的区间，也是竞争的着力点。价值差异区间的大小，决定了竞争后可获得市场的多少。

当然，这只是很粗浅的一个例子，大家可以根据自己行业的不同，把自己的产品和竞争对手之间的价值曲线画出来，进而寻找产品竞争的着力点。

—

这一系列关于方法论的手记的第一波就这样写完了。胸中有想法，就想记下来，没奢望谁来看，也没期望搏什么东西。我随便写，你随便看，这是最好的状态，你若是从中读出点什么来，不论好坏，都跟我没什么关系，我也不承认。

至于接下来我也不知道会写什么，随缘吧。

这一篇，我们稍微分个小岔，讲一下当我们具备了初步的场景意识之后，我们如何把场景连接起来，进而找到场景中的相互关联，帮助我们理清问题，设计解决方案。

从线性思维到系统思考，是一种思维方式的转变，也是产品经理需要具备的一种思维方式。当然，很抱歉，这还是方法论，不是什么你拿起来就可以直接去执行项目的东西。

在我们与生俱来的学习环境中，我们接触到思维模式，绝大多数都是线性的。典型的就是，我们看到了这个原因，所以我们得出了那个结果。

为什么他成绩不好呢？因为他不好好学习。为什么他做不出一个好的产品呢，因为他不是一个好的产品经理。因为袁世凯要称帝，所以袁世凯是个坏蛋。因为共产党创立了新的国家，所以，只有共产党才能救中国。

我们习惯与用线性的因果链来描述与判断事物，我们也经常用静态的「快照图像」来做最终的结论。因为所以，科学道理，这是我们的线性思维模式。

但，这并不合理。线性的思维模式下，事物之间的联系是非常确定性的，直线型的。产生这种错觉的一个很大的原因在于我们忽视了细小的「反馈」。

对「反馈」的洞察与认知，是系统性思维养成的一个起点。在《第五项修炼》这本书中，作者曾经举了一个非常基础常见的例子来说明这个问题。

在线性思维模式下，「向杯子里倒水」这件事，就是向杯子里倒水，就完事儿了。

但是，在系统思维模式下，我们把「反馈」元素加入进去再看，就会出现如下图的循环。

当我们借用「反馈」的元素，试图去看清楚一件事情（系统）之中的各种关联结构，厘清各种变化的过程模式的时候，我们就不会再简单的对事情做归因和下结论了。这就是一个非常基础的系统思维的例子。

把这种思维放到产品设计中来看，这就是交互设计的最本质的思考模式。交互就是一个不断的给予反馈的过程，我们为什么做不好一个交互，大部分是因为我们没有搞清楚反馈。

我非常建议交互设计师们去厘清各种场景下的反馈，基于这些反馈再来做设计。反馈梳理的越细致，就会做出越合理的交互设计来。

我们可以再来看一个现实中的例子，在一个典型的网约车场景中，司机接了订单，但是不来服务，那么，是因为司机服务意识太差，我们应该给司机惩罚，让司机惧怕，司机就会好好服务了。

现实情况是这样吗？让我们来画一个简单的思考环路。

如果我们不找到相互之间的动态关联，就会经常做出把瘸子医成瞎子的决策，甚至，会出现饮鸩止渴的结局。

总结起来看，系统性思维是这样一种思维方式。

这是一种如此关注结构以及动态变化的思维方式，以至于，即使你不做产品，你也可以用的到，并且一定能让你获益良多。

系统性思维帮助梳理出事情之间的关联关系，结构思考力帮助归纳整理，对外表达，他们一个负责剖析求真，一个负责整理输出。

关于系统性思维，可以读《第五项修炼》；关于结构思考力，可以读《金字塔原理》或《结构思考力》。

上一篇，理清了一些概念，在这里，将分为这么几个部分来阐述。

1. 我们常说的使用场景是什么
2. 我们应该怎样利用使用场景
3. 如何进行场景的提炼与排序
4. 如何培养自己的场景感
5. 基于场景的设计模型

1. 我们常说的使用场景是什么

场景是一个编导专业入门级的词汇，指的是在特定的时间、空间内发生的行动，或者因某种关系构成的一个画面。电影需要很多场景，并且每个场景的对象可能都是不同的。

上面这张图来自我最喜欢的香港导演杜琪峰的电影。这个场景里面，3个贼王很偶然的在一个空间中汇合，各怀心事，朝着服务员发火，情绪都写在脸上。

那么，一个完善的场景应该是什么样的呢？

概括来说，就是在某个时间、某个地点下，某个用户因为某个因素的影响，产生了某种诉求，会想通过某种方式来解决。

这里的某种诉求可以通俗的理解为我们常说的用户需求。你会发现，所谓的需求，并不是无根之木，它是有一个来源的，就来源于使用场景。

比如之前举过的例子，今天上午，张三在公司使用电脑第一次登录QQ，他之前一直在家里那台电脑上登录，上面有很多他收藏的表情。他想在公司的这台电脑上也使用这些表情。

这个需求很明确与简单，能让张三在别的电脑上使用同样的收藏的QQ表情。

再比如，寒冷的冬天的早上，李四要从家出发赶一个会，附近没有地铁与公交车，时间已经很紧张了，他在易到上选择经济型车叫了一辆车。

这个需求，表面上看是李四需要一辆经济型车。但，如果没有经济型车，有一辆舒适型车离他很近，他这个时候需要吗？

我们把自己放到那个场景下去思考，这个时候，用户的需求，其实是需要一辆快速能到达的车，其次是便宜的车，再其次是条件很好的便宜的车。这就是易到用车为什么有混派这个功能出现的原因，当没有你选择的经济型车的时候，会派发一定数量的舒适型车给你，满足你最基本的需求。

当然，这是另外一个话题了，发现一个场景很简单，但是，通过对这个场景的理解，进而找到用户的诉求是非常难的。

2.我们应该怎样利用使用场景

我们可以看到，一个使用场景其实包含了几个要素：特定的人、特定的时间、特定的环境因素、特定的诉求、特定的某个想法。

你可能会问，为什么要这么多因素，搞这么复杂，咱们简单点，直接就是，某个人有某个想法不就完了吗。

某个人有某个想法，这是个结果，倒也没错。但是，使用场景的因素，是为了更好的表达这个想法的。

比如，你跟服务员说要一杯水，服务员给你一杯开水，你说太烫了，服务员给你了一杯温水，你拿起温水就洗了个手。服务员因为没有考虑到你的具体使用场景，所以，并不能以最小的成本满足你的诉求。

再比如，比基尼和军大衣，都是衣服，但是，因为使用场景不同，所以，创造的用户价值完全不一样。

拥有完整的使用场景元素，可以更好的帮助我们去梳理和表达那个时刻下，用户的真实感受，用户的真实诉求。这是产品经理利用场景的第一个好处，帮助产品经理梳理用户的诉求。之前业界有个相对学术的称呼，叫做培养同理心。

就产品经理而言，比较多的工作是在做沟通。使用场景描述的方式来做需求的沟通，是一种更高效的沟通方式，这是产品经理利用场景的第二个好处。

在传统的团队沟通中，产品经理经常会产出一份功能列表给研发团队，大家首先是基于功能的探讨，然后是基于功能细节的争吵。在这种沟通中，用户的使用场景几乎没有体现。

基于使用场景的沟通方式，产品经理在提出功能的时候，首先描述的应该是使用场景，让研发与运营同学能更贴切的体会到用户所处的环境，用户在那个环境下会产生的具体的诉求，然后才是基于这些场景，能帮助他们解决问题的想法，最后是功能点的设置，策略的安排。

比如，你直接告诉团队，用户选择经济型车的时候，如果经济型车不够，我们应该给他一些舒适型车。团队其实很难在这个问题上达成一致，因为这看上去与团队的预期不符，他们会说，没车可以让运营加车啊，或者让用户多等一段时间啊。然后就开始进入到产品与运营及研发的相互撕逼指责中了。

如果我们使用场景描述的方式，把大家还原到那个场景中去，这个问题，就相对容易理解与达成一致了。

这也是产品经理沟通的一个基本思想，先在为什么做这个功能上达成统一，然后再就怎么做这个功能展开探讨，最后再去想细节的问题。

总结来看，使用场景可以帮助我们自己更好的理解用户需求，同时，也是一种更高效的团队沟通方式。

3.如何进行场景的提炼与排序

每个使用场景都对应着一个用户需求，每个用户需求都有对应的用户价值。当你满足了某个用户的某个诉求，你就产生了相对于这个用户的用户价值。

每个用户在每个时期都有很多的需求，有的需求很强烈，我们把它叫做刚需，有的则不然；相应的，这个用户有的需求，那个用户不一定需要，我们把它叫做需求的广度；另一个方面，有的用户经常有这个需求，但是不常需要那个需求，我们把它叫做需求的频次；考虑到市场竞争的因素，有些需求竞品已经满足了，有些则没有。

综合起来看，用户价值 = 需求的刚性 * 需求的频次 * 需求的广度 * 可替代方案。

利用上面这个公式，结合我们对市场的定位，对用户群的细分，我们是可以比较清晰的对使用场景进行排序提炼的。

比如，上海到北京线是中国最繁忙的高铁线路之一，当我们着急要从上海到北京的时候，经常发现买不到票，或者只剩下很贵的一等座的票。

于是高铁管家做了一个先上车后买票的功能来解决这个场景。你可以买一张从上海到石家庄的票，到达石家庄之后，我不下车，去找列车员补票，补从石家庄到北京段的车票，这个时候你可能没坐，但是好在时间很短，你只需要站一小会儿就可以到北京。

这个功能是高铁管家的产品对用户的这个使用场景理解非常到位的体现。它并不高频，但是刚需，用户广度也一般，别的竞品一开始的时候并没有这么做，综合起来看，用户价值就很大了。

当然，上面那个公式只是单纯从用户价值出发做的计算，作为一个商业行为，我们最终还需要考虑到实现成本与收益因素，那是另外一个大的话题了。

4.如何培养自己的场景感

打球的人爱说手感，前些年做互联网的人爱说网感，这几年做产品的人都喜欢说场景感。

那么，场景感可以培养吗？我认为是可以的。培养场景感很玄妙吗？我认为不是的，只要我们认真去生活，仔细去体会，其实不难。

在易到用车的产品团队，所有的产品经理都必须定期的完成一个叫做下一线的任务。主要做3件事儿，去做司机、去坐车、去听客服录音，这是一个强制性的任务。定期去做，然后回来给大家讲体验过程，并总结出来一个要解决的点，进行跟进完成。

这是一个培养自己场景感的方法，把自己放在真实的场景里面去经历，去体会，然后再来看看应该做些什么。

当然，你可能会说，我做的这个产品我没法自己去体会啊，我该怎么办呢？

之前做快捷酒店预订，我们自己当然不能去做一个店长，那么，我们就去大堂待着，去观察店长是怎么工作的。

有赞是一个给小微商家提供电商解决方案的公司，他们的产品也不能每个人都是店长。但是，他们可以在内部采用模拟开店的方式，在内部做商品售卖，来让每个人体验产品流程。

其实，在很早之前，毛太祖就对这个问题给出了答案，就是下面这张图。

5.基于场景的设计模型

这是我之前截的一张图，这是一个典型的没有基于场景出发的横向型产品设计。而我们再看微信、uber的产品设计，是一个典型的基于场景出发的纵向型产品设计。

用连长的话说，基于场景的产品设计，就像是给用户设计了一个过道，用户经过这个过道的时候，会很智能的出现一个个抽屉，当用户需要某个抽屉的时候，这个抽屉自然打开，用户用完就走了。

你可能会说，我们无法判断来到首页的这个用户需要什么功能啊，就携程而言，我们服务的用户理论上是无限的，每个用户来到首页的需求也是无限的，所以，我只能一字排开了。

那我想，我们是否应该回到那个用户价值的公式，重新做一些计算与思考了。

最后，做一点总结：

1. 场景覆盖用户，服务用户产出使用价值，使用价值带来商业价值，场景为本
2. 基于使用场景描述需求，是一种更生动与高效的团队沟通方式
3. 对使用场景的描述，源于对业务的理解，而不是明星产品的经验
4. 基于场景的设计，产品大多是纵向的；基于功能的设计，大多是横向的

做产品这事儿，本质上就是解决问题。

不过，这个说法还是太粗糙，所以说了等于没说。因为，如何去发现问题，哪些问题是要解决的问题，多个问题之间的取舍，谁先解决谁后解决等等才是最难最重点的事情。

有很多优秀的产品人，通过不同的方式与不同的切入角度，都说过该怎么去做产品。既然是解决问题，其实并不存在统一的方法，每个人都有自己的风格，自己的方法，我们管这个叫做产品方法论。

你不必去羡慕别人的方法论，你应该建立你自己的方法论，这是我一直的观点。

因为某个机遇，我整理一些我的方法论，在这里写出来，供自己做个总结吧。

（这是一次付费分享的文字梳理版，当时有人邀请去做分享，我就说我很贵，结果人家真的付钱了，我喜欢不按套路出牌，我也怕别人不按套路出牌，于是没办法，我就重新整理了之前的一次分享，完善了整个体系，做了一个半天时间的分享，感谢这位老板。）

这个系列会分为4篇文章来写：

1. 先厘清一些基础概念
2. 从使用场景到用户价值
3. 从线性思考到系统性思维
4. 从用户价值到价值曲线

这是第一篇，简述这几篇文章的由来和先厘清一些概念，方便后面的文章展开。

— 啰嗦结束，正文开始的分割线 —

我们看一个行业发展的速度，我有一个我自己的角度，那就是看这个行业能产生多少流行的黑话。

互联网产品设计这个行业，这么几年里，产生了太多黑话概念，UCD、UED、UX、MVP、增长黑客、用户场景、用户价值、用户体验等等，不一而足。

一个行业的黑话越多，说明发展越快，还未定型，是一个值得进入的行业，这是好事儿。但是，过快的变化，让很多入门的同学也很苦闷和不知所措，往往被这么多名词搞糊涂了，或者被这么多的黑话所吸引，忘记了本质的东西。甚至忘记了基于常识的产品设计。

下面是几个比较常用的概念：

1.使用场景：在某个时间、某个地点，某个用户因为某个因素的影响，产生了某种诉求，会想通过某种方式来解决。

比如，今天上午，张三在公司使用电脑第一次登录QQ，他之前一直在家里那台电脑上登录，上面有很多他收藏的表情。他想在公司的这台电脑上也使用这些表情。

2.用户需求：在某个特定场景下，用户因为某种诉求，产生了某种需要。

比如，上例中，用户的需求是在各个设备上登录的时候，都可以使用收藏的表情。

3.产品功能：为了满足用户某个特定需求所开发的程序，或者做出的相关策略。

比如，上例中，QQ表情跟随用户ID保存在云端，可以随时同步到不同设备，这个QQ表情漫游的程序就是一个产品功能。

4.用户价值：因为帮助用户解决了某个特定的需要，所以产生了相应的对用户的价值。

比如，上例中，通过QQ表情漫游这个功能，用户可以随时随地使用收藏的表情。

5.商业价值：因为符合商业的需要，所以能产生收益。

比如，QQ表情漫游可以包装成会员权益，会员可以收费，收费可以挣钱。

6.用户体验：在满足用户需求创造用户价值的过程中，是否让用户足够愉悦，甚至给用户带来惊喜。

比如，QQ表情漫游这个功能，入口设置很难找，操作步骤很复杂，漫游的表情还经常丢，或者不同设备之间排序很混乱。

他们之间的一些关系：

1.有使用场景就会有用户价值。

使用场景来源用户的具体需要，哪怕是一个用户，也是价值的体现。只不过很多时候，因为有这个场景的用户太少，价值太小，所以会选择放弃满足这个使用场景。

2.使用场景不是硬造出来的，但是，是可以培养的。

就打车而言，巡游模式的出租车是最高效的（排除服务意识、数量管制等因素），即使有通过手机叫车的诉求，也很有限，比如接送机等。但是，通过补贴的刺激，可以培养用户更多的在新场景下使用。

3.有用户价值不等于有商业价值。

用户价值是说因为你解决了用户需求，所以你有价值；商业价值是说，在商业层面下他可以挣钱，涉及到投入、产出的模型。所以，有很多产品有海量的用户，但是商业价值并不大，甚至并不能盈利。

4.作为一个产品经理，建议多考虑用户使用场景。

从用户使用场景出发，考虑多数人的使用场景，思考基于这个场景如何产生足够大的用户价值，再思考如何从中获得商业价值。

毕竟，大家做的事情概括起来就是，替人消灾，拿人钱财。这是运行了数个世纪的最基本规律，并没有什么高级之处。

5.理论上用户价值比用户体验重要。

之所以说理论上，是因为虽然类似12306这样的真实案例是存在的。但是，你会发现，像高铁管家这样的，基于12306的数据做一些用户体验上的改造，一样可以拥有巨大的用户量。

—

好，头儿就先开到这里了，接下来慢慢展开吧，至于这一系列能不能写完，写到什么程度，我也不知道，你们也不要抱什么希望，谢谢。

这两把刀，对于学习设计的人，不管是工业设计还是互联网设计，应该都很熟悉。当然，如果你是一个无印良品的忠实消费者，你关注无印良品这个品牌和他的设计理念，你应该也很熟悉。

今天从这两把刀开始谈，主要分享我自己思考的几个方面：设计的确定与适用性；设计背后的驱动力；关于空的哲学。

设计的确定性与适用性

再回来看这两把刀，上面那把刀，是典型的德国设计风格，下面那把刀，是典型的日本设计风格。

首先从风格上看，两把刀的设计都是符合一定的「简约」风格的，没有繁杂的装饰与设计。

从设计本身来看，上面那把德国刀的设计，最重要的特征是它非常符合人机工程学。

人机工学就是用科学的方法、理性的手段、量化的指标，把产品很严谨地处理成人机交互的形式，德国就是人机工学的代表。

德国的刀往往喜欢做成全钢，即刀身和刀柄是一体式的钢，可以说这种工艺难度和精度都相当高，一把好的德国菜刀是的确可以用很长时间的。

下面那把日本的刀，最重要的特征是它具有非常广泛的应用场景。

日本的文化里面有一种刀，刀柄是直的，截面看可能是圆的，也有可能是倒角矩形的，不像德国设计的带有线条的符合人肌肉握持。

而且日本的菜刀往往刀柄和刀身并非一体，那是因为日本设计者希望刀柄可以随时更换，留给使用者足够的使用空间。

从设计的角度看，德国刀的设计是确定性的，它使用非常严谨复杂的方式，使得这把刀在某个确定的使用场景下，能最大程度的发挥价值；日本刀的设计是适用性的，它使用非常自然的方式，使得这把刀可以适用多种不同的使用场景。

我的家里有一套非常完整的双立人道具，我非常的喜欢，这套刀具有切肉的，有剁肉的，分工细致，用合适的刀，省时省力，但是，我常常会搞不清楚我此刻该用什么刀；我的家里也有一把如上图的日本刀，它确实是我平时使用最多的刀具，但是，它却并不能在某一个场景下表现的极度出色。

不论是确定性的设计，还是适用性的设计，在设计上并无高低上下之分。

如果你觉得日本的刀的设计要比德国的刀的设计更高一筹，那只能说明，你并不懂设计。因为，所有的设计，都是尤其特定的背景与条件的，所有的设计都需要放到特定的背景与条件下去考量。

设计背后的驱动力

如果你常去博物馆，不论是国外的还是国内的，你会发现，我们所使用的物品，已经变的越来越简单。

我们看中国古代的很多设计，不论是一把椅子、一张桌子、一座建筑，其实都非常之复杂。15年的春节，我去了一趟泰国，在看了很多庙宇之后，我开始思考，为什么这些庙宇在建筑上看着都如此的复杂，屋顶的雕花、墙上的壁画、甚至是道路的设计。

后来，我慢慢明白了，不论是复杂还是简单，都是设计的外在形式，驱动外在形式的则是政治、经济、文化的内在。

我们可以有明确资料记载的历史，是从集权开始。集权的一个重要特征是要具备威慑力，没有威慑力，集权便无从谈起。

在一个生产力水平并不高的时代里，复杂则是一种能力的体现，是一种能具备威慑力的外在表现形式。所以，我们看到具备集权特征的国家里，全世界的王座都一样的复杂，都会有复杂的雕花装饰。

在王权终结之后，人们发现，我们不再需要利用复杂来表现威慑力，于是，所有的设计师都开始思考，我们应该如何重新去设计。简单自然的设计，成为一种新的符合政治、经济、文化需要的设计思潮就这样出现了。

关于「空」的哲学

起源与中国的道家老子喜欢说空，或者叫虚无；传入中国的佛家也喜欢说空。日本最负盛名的设计师原研哉也喜欢说空。

关于这3个空，我有一些自己的思考，可以简单聊一下。当然，我只是感兴趣，并没有深入的探究，所表达肯定也有不当之处，也欢迎探讨。

道家说空，按照王东岳老师的说法，「空」是一种平衡，比如一个平面没有波澜，并不是任何物质都没有，这个一望无际的平衡就是「无极」。但是一旦平面上一点发生激变，这个变化就会一直传播开去，这种变化就产生了「有」。

佛家说空，空代表了一种不稳定性，或者说一种流动的变化。佛家老爱说「如筏喻者」，就是说，你不要执着，过河的时候你需要船，过完河，船就该扔了，你没必要背着。详见我之前的文章「读了两遍金刚经」。

原研哉也喜欢说空，原研哉的空的概念，大概是在2008年左右提出来的。他认为，他的设计与西方流行的简约有相同，但是，本质的出发点不同，所以，他提出了空的设计理念。

2008年9月，原研哉在google做了一次公开演讲；2011年，原研哉在北京国际设计周上再次谈到他的空的设计哲学。同时，他还写了一本叫做白的书，来阐述这个空。

原研哉的空，更多的是一种适用性，他把设计的东西想象成一种容器，而使用者不同的使用场景，都可以收纳到这个容器中。更关注使用场景，以及物体与使用者的融合。

原研哉的空，确实是比「简约」要更深化了很多的。所谓简约，是相对与「繁杂」而言的，如我们前面所说，集权时代的设计是繁杂的，集权之后的设计趋向于简约。

但是，简约的设计只是去除了不必要的装饰，仍未能更进一步的触达设计的再深一层次，原研哉试图用他的空的理念来进行更进一步的探索。

从无印良品看日本的设计哲学

在无印良品的官方网站上有一个「物的八分目」的专门页面，用来介绍无印良品的设计理念。（http://www.muji.net/lab/fitness80/zh-cn）

所谓「物的八分目」，用中国话说就是，饭要吃的八分饱，主旨是要告诉我们，适量的重要性。这个逻辑，其实是跟中国文化基因中不断流传的中庸之道非常的相似的。

按照我个人的理解，「物的八分目」就是原研哉的「空」的设计哲学的一个非常之重要的外在表现。

我们可以从原研哉的各种演讲与书中了解到日本当前的设计思潮，无印良品的设计起源。

日本是一个资源本身匮乏的国家，幕府战争之后，整个日本资源又被极大的破坏了。在这样的历史背景下，日本人开始反思是否需要浮华的设计，以及，如何利用有限的资源来进行生活。

日本近代的设计哲学，是在这样的历史背景下诞生的。而2011年的日本大地震，更使得日本坚定的认为，要让人类过渡膨胀的欲望回归到合理。

从日本的设计哲学看中国

原研哉最爱把世界地图翻转九十度，这样日本就处在最下面的位置，他说，你看，这样我们就能理解为什么日本拥有现在的文化了。因为日本承载了全世界文化的熏陶。

不得不说，日本是一个善于学习的，具有韧劲的国度。当中国是世界最强大国的时候，他们的遣唐使遍布长安；当他们被美国的黑船舰队打开国门之后，他们的学者遍布欧洲，他们把不同时代最精髓的文化、技术进行消化融合，最终拥有了现在让人为了赞叹的文化与设计理念。

我们经常会听到有人艳羡别国的设计与品位，进而感慨中国无自己的设计哲学。这种说法不无道理，但是，我们倒也不必如此悲观。

如果我们把日本的设计哲学变化跟他的政治经济发展连接起来看，一个非常简单的道理在于，设计哲学是服务于政治经济发展的。

中国近几十年，是政治经济发展最为迅速的几十年，在奔跑中的中国，不断的进化发展，不断的收到来自不同新事物的冲击。

我们今天的设计是为了到明天变成旧东西，需要不断被翻新，人们在使用中获得生活的想法，再获得新设计。但这样会消磨企业的能量，消磨设计师、消费者的能量。

一个成熟稳定的哲学思想某种意义上就是得以在设计中被复制、反复应用实践的方法论。在这样激荡奔跑的年代，面对太多的不确定性，其实，我们应该多点耐心的。

《我要的是葫芦》是人教版小学二年级语文上册的课文。文章讲述了一个人一心想要心爱的小葫芦长大，认为叶子上的蚜虫与葫芦毫无关联，毫不在乎。最终葫芦被蚜虫蛀了，他的愿望也落空了。

标题里用这个，想要说的事情是，我们要真正的理解目的，才能做出来合适的方案。用比较不人话的话来说，不要站在问题本身看问题，才能真正解决好问题。

最近，我跟小伙伴们讨论一个需求，我表达了我为什么要这么做的原因，然后给出了一个我心目中的方案。

接收到需求的小伙伴拿着我的目的和方案走了，在跟团队其他小伙伴讨论的时候发现，我的方案有瑕疵，实际无法执行，于是，他们又来找我。

这一次，我们讨论的不是「我要这么做的原因」，而是「我的方案」。于是，我们就探讨了半天，实际证明，我的方案确实是有瑕疵的，不能执行的。

搞了半天，我忽然想起来，我们为什么要花这么多时间来探讨我的方案呢？我其实只是想要那个目的啊，我其实并不是很在乎是不是用我的方案去做了。如果大家有更好的方案，那是更好的事情啊。

几个人在一起，复盘了这个事情，不由得觉得好玩。然后我们的一个小伙伴总结了一下关于这个事情的感悟，如下图：

这个事情之后，我做了一下反思，反思我在接收老板的需求的时候，和我作为老板向小伙伴们发出需求的时候，分别是怎样的遭遇。

首先，我们在发出一个需求的时候，都是会描述一个「我们想要的结果」，或者叫做「我们为什么这么做的目的」。为了让我们发出的这个需求看上去不是那么扯淡，我们常常都会附上一个「我们心目中的解决方案」，这个解决方案一方面是一种佐证，证明我们的想法是合理的，一方面也是一个指导，给出了一个大概的实现步骤。

然后，我们大概会遇到3个结果：

1、完全不能理解「我们为什么这么做」，但是，老板交待了事情，我们必须得做，就依着自己的性子，搞了一个方案出来。

不理解为什么，不参考指导方案，只盯着要的那个具象的东西，结果就是一塌糊涂。

2，能理解「我们为什么这么做」，但是，不能理解给出的指导方案的目的是什么，就完全照着指导方案去执行了。

这种是最常见的，这种是号称执行力强的做法。我理解你为什么要这么做，你也给了个方案，我要做的事情就是，二话不说，崛起屁股就干，我完全听你的。

这种强执行力的玩法，需要下发需求的人把事情想的足够明白指导方案给的足够正确，同时，实现路径也足够单一才可以。稍微复杂一点的业务，复杂点的事情，这种状态就会经常出现，我很努力，但是，我好像做的始终不是那么回事。

3，完全理解「我们为什么这么做」，明白指导方案与为什么这么做的关系。

这种是最牛逼的配合，你要的是葫芦，但是，我要帮你除草抓虫，因为，即使你知道种个葫芦很不容易，你也不会知道种个葫芦如此之不容易。

当然，就像我的小伙伴说的，不同类型的老板风格不一样。不过，我愿意善意的揣测说，其实，绝大部分老板是这样，他们想要的是葫芦，他们也知道种葫芦很不容易，他们给了你葫芦籽和种子，至于怎么种葫芦，你可以随意发挥，他们不会去干预，只要你能把葫芦搞出来。

其实，我们延展来看，这个案例，就是我们常说的「需求分析」了。如果我们把「老板」当成是一个用户，我们应该首先通过老板提的要求，去分析他真正的需求，理解了他真正的需求，再去思考怎么解决他的需求。

用户所有的需求都是这样的，我要的是葫芦，反正我要的是葫芦。

之前给新人做分享的时候，我经常会用一个例子来说明如何做需求分析及沟通：

– 客人：服务员，给我来杯水

– 服务员拿来一杯热水

– 客人：我靠，这个水怎么这么烫啊！

– 服务员：不好意思，不好意思，我给你换一杯

– 服务员去换了一杯温水来

– 客人拿起温水给自己的女朋友洗了个手

怎么做沟通，怎么做分析，这个故事你看得懂，就可以了。

— 题外话

每当看到我的团队里，有小伙伴有类似的总结与复盘感悟，我都觉得很有成就感。

我最近在思考，到底我们需要怎么样的成就感？或许在不同的阶段，对成就感的定义是不一样的，当我把我自己放在这个团队里的时候，我想，我需要的是让自己有成就感，让小伙伴有成就感，就是这样。

同时，从私心上讲，我又是很希望我的团队能学会独立思辩、勤于复盘、直接的表达，这些是我的价值观与做事方式，也是我认为一个好的产品应该具备的素质，我希望我能黑化他们。

江湖路漫漫，总希望能有志同道合或者臭味相投的人一起前行，大概就是这么个执念吧。

不知道是好是坏，管他呢！

鲁克兄写了一本关于产品经理的书，叫做《产品的视角》，送了我一本来读。

我向来是非常的佩服能写书的人的，因为我虽然长期的写博客，但是，一直都写不好。发一条朋友圈，完全不用过脑子；发一条微博，需要思考一下；写一篇博客，需要构思一下；写一本书，则需要深思熟虑，所耗费的精力与需要的功力不在一个等级。

写一本书很难，写一本产品经理的书则是难上加难。产品经理这个职业一直在不断的进化发展，他的外延也在延伸，这是一个非常难以定义与描述的职业。同时，作为一个没有门槛的职业，有着非常高的隐形门槛，直接的导致就是面向产品经理的书，用户群非常难以归拢定位，他们的需求也非常之分散。如果我们说同行相轻，那么，互联网行业最相轻的职位，非产品经理莫属。

这本书说是写给-2岁到2岁的产品经理的，我一个高龄产品经理，耐心的读完了，依然很有收获。当然，也能看出这本书的编辑与作者都很着急要让书面市啊，连iOS这种书写错误都会出现在一本产品经理的书里，实在不应该。

借着读书的机会，写一些跟这本书无关的一些感触吧。

1、产品经理需要有强大的内心

有个产品经理觉得自己很委屈来找我聊天，我就问他怎么了。他说，我简直就是公司里最千夫所指的人啊。我说啊，不会吧，你说说看，你都做什么对不起大家的事情了。

他说，你看啊，出bug了吧，第一个被喊的人是PM；用户骂用户体验不好了吧，第一个被喊的人是PM；流程出错了吧，第一个被喊的人是PM…反正，基本上，只要是出了问题，第一个要被拎出来的一定是PM。

哈哈，你老是这样被拎出来，说明你重要啊。你不重要谁没事儿搭理你啊。哥们说，那不是啊，产品做的好不好，很多时候跟产品没什么关系，要看其他角色的配合啊。我现在听到用户体验不好产品不好的词儿就慌张，就觉得怎么老是在针对产品呢？

这应该是目前很多PM的现状与内心想法，觉得自己很委屈。觉得委屈就对了，觉得委屈说明还在不断成长，说明还有价值。你的成就，都是委屈撑起来的。

没有一个强大的内心，做不了PM，这是最基本的素质要求。

有一个强大的内心，就需要你能周旋在不同的业务方中间，能忍受他们的强硬，也能接受他们的无能；有一个强大的内心，就需要你能分的清哪些抱怨是无理取闹，哪些抱怨是真实需求；有一个强大的内心，就需要你能把业务或者老板的无理要求转换成研发能听得懂的能接受的需求；有一个强大的内心，就需要在不断的被召唤中，总结出来一套方法。

2、要抓住用户的贪嗔痴，但更要管住自己的贪嗔痴

这是一个很现实的问题，一方面，产品经理都是在利用人性的弱点来打造产品，但是，同样的，产品经理也是人，也有人性的弱点。当我们把自己人性的弱点带入到自己的作品中的时候，就会出现问题。

我之前写过一些文章反思我这几年的做法，最开始的时候我是喜欢耍酷的，经常会在产品里放一些酷炫的动画也好，繁杂的交互也好；后来，高级的交互都不用了，该为比较平淡的处理；再后来，则是更多的考虑如何更自然。

说官话，说套话，说人话。形象点来说，就是这么一个蜕变的过程。

产品经理看上去，真的是一个人格分裂的职业。你要先站在上帝的视角去搭建一套东西，然后你要迅速切换到人类的视角来感受这个东西，再然后你又要切换回上帝的视角来引导大家使用。人格分裂啊….

3、常识是一个无法规避且极度重要的问题

我曾经写过一篇关于常识的文章，常识的问题是如此的重要，以至于我们在实际中都会忘记他们。

有次参加三节课的产品马拉松，大家做的产品创意都很好，但是，几乎都忽略了关于常识的思考。想象太过美好，必然导致现实极度坎坷。

我经常会重复的去看一本叫做《简约至上》的产品设计书，因为这本书讲的都是非常基本的设计原则，之所以不断看，是因为这些原则都太常识了，以至于经常被忽视与自我遗忘了。

后来，我也会翻看自己的旧博客，因为那些内容都是我在那一刻的反思与总结，也都是常识的问题错误。非常识的错误，基本都是专业性的东西，一旦你掌握了，就不会忘记，比如一个方法论，比如一个分析方法。

学会尊重常识，也是一个很基本的素养。

4、产品经理是可以培养的

我很早就认识布棉，后来他跟我说他做了一个PM的培训组织，叫做三节课。于是，我们探讨了多次，产品经理到底是否可以通过培训来培养？

后来我去听了他的三节课，去参加了他的产品马拉松，我改变了看法，产品经理是可以通过机械的长期的训练来培养的，并且培养出来的产品经理基本都可以达到及格线。

再怎么说，也是一个职业，一个职业就有一个职业的基本流程玩法，按照基本流程玩法，不至于出错，这就是能送上路了。

一直以来的产品经理培训组织，过于急功好利或者狭隘，所以，要么就是找一堆名人来刷脸带流量，但是学员没有直接的收益；要么就是讲师都是临时不断变化的，不能形成有效的系统理论。

三节课的3个人，在产品思路、产品方法、性格上都非常相似，他们一起探讨的一套关于产品的方法论，是一个很系统的理论。用户、产品、运营，一个套路打出去，只要持续练下去，不会走样，这样的培训方式才是对的。

作为评委，参与过三节课的产品马拉松，这实际是一个关于产品经理实操，领导力，应变力，抗压力的课程，是产品经理能力的另一方面训练。

听说布棉他们3个已经全职出来做三节课这个事情了，我很期待，期待他们能为中国的互联网产品行业输送更多优秀的产品经理。

5、产品的方法论没有对错，只看你怎么运用

就像我之前说的，要建立一个产品循环，可能到现在，还是有很多人不会理解什么叫产品循环，为什么要循环。

你看，这就是属于我的方法论，我一直以来就是依照这个方法论来做的，效果还不错。

你从入行开始，会听到很多很多的方法论，会遇到很多的人用很多不同的方法很好的解决了问题，这些方法论都是对的，也都是错的。

你用起来顺手的方法论，就是对的，你用起来不顺手的方法论，就是错的。关键的关键是，你需要去有意识的建立这么一套方法论。

6、要注意身体

最后的提醒，产品经理是一个高危职业，请务必注意身体。

之前跟几个做数据分析非常厉害的产品经理交流，我们谈到一个话题，为什么很多产品经理做不好数据分析？或者说是，做的那些个事情，看上去都那么的狭隘，摸不到G点上？

其实，并不是数据分析有多难，也不是数据有多难提取，而是因为最基本的问题没搞清楚，后面就全乱套了。

比如，说转化率，首先不清楚分子和分母代表什么，如何定义，后面完全不知道如何去提升了。

一般来看，

比率=分子/分母。

要让比率提升，就2个方法，要么将分母减少，要么将分子扩大。这是一个小学生都知道的基本原理。

现实状况下，因为产品在不断迭代，所以分母往往是不断变大的，那么问题就转移成如何让分子变的足够大，分子扩大的速度要高于分母扩大的倍数，这个时候，比率一样会提升。这是一个高年级小学生都知道的基本原理。

然后，再往下去拆解就是具体该如何去操作了。

一般来看，

订单量=使用人数*使用频率。

使用人数=新用户+老用户-流失用户

订单量=（新用户+老用户-流失用户）*使用频率。

所以，要提高订单量就要去改变几个元素就好了。剩下的问题就变成了，如何去拉新用户、促进老用户活跃、防止用户流失、提升用户的购买次数/使用频率。

一般来看，

表达一个问题的逻辑，概括起来看就2种，横向展开、纵向分解。

于是，你会发现，绝大多数的演讲，都是这样2个逻辑开始的。要么就是跟你说1，2，3，4；要么就是先提出一个问题，然后分析这个问题，最后提出一个自己的主张解决了这个问题。

…

这样的例子还有很多。

这些最基本的公式就是所谓的内在，无非加减乘除，根本都用不上更复杂的数学。这些内在是思考问题的起点，把基本公式弄清楚是解决问题的最基本步骤。

搞清楚内在的基本公式再分析问题就会事半功倍，搞不清楚内在的基本公式就去分析问题自然就是事倍功半。

刚才举的例子是正向拆分，一般出现在拍kpi或者制定规划的时候。其实，反过来，通过现状追查问题也一样适用。

实际情况上看，某个比率持续走低，怎么办呢？

1、把这个比率的分子与分母确认下来

2、影响分子的因素是什么，影响分母的因素又是什么

3、近期这些因素的变动情况是怎样的

4、…

你就会发现，你能通过一个基础的公式，把很多事情连接起来了，找到了相互联系，然后答案就自然的出来了。

内在都是很简单的，外延一定是很复杂的。

如果直接从外延入手去思考解决问题的办法，得到的就是一些苦劳的招儿，并不能足够高效的解决问题；如果从内在入手去解决问题，得出结论的过程可能会比较慢，但是，得到的一定是能高效解决问题的妙招。这也是我们常说的罗辑思维能力的一种体现。

使用这种从内在到外延的分析方法分析问题的时候，常常会遇到一种现象，需要单独的说一下

比如，

分析订单量的时候，发现，很多用户不来购买了，但是各个指标都没有明显的变化，于是，就陷入僵局了。

必须要说明一下，所谓的数据分析，并不是说，所有的数据都是存储在我们的服务器上的，我们就只能用这些数据去做分析。更多的时候，最笨的办法就是最有效的办法。

上面说的那个例子，最简单的解决方案是什么？打电话！

设计好你想了解的问题，然后，直接打电话过去跟用户交流，直接问。或者找到用户，做线下访谈，又或者，去观察用户是如何使用的。

依赖技术是我们这一带入最值得骄傲的地方，过渡的依赖技术是我们这一带入最可配的一种思维。

不妨我们停下来思考一下，

你现在做的事情，你搞清楚了他的内在了吗，那个最简单的公式？

这个内在往外延都有哪些呢，那些关联着的因素都是什么？

我们现在做的事情，就是在做事情，一叶障目的做事情吗？

本文转载自「给产品经理讲技术」公号，已经过原作者授权转载。

今年的双十一，想必广大千手观音们又狠狠的剁了几只手。然而，剁手换来的宝贝在漫漫快递路上也是命途多舛，轻者磕磕碰碰包装损毁，重者与快递货车一起被付之一炬。这些“不可抗力”造成的问题屡见不鲜，碰到了也只能自认倒霉。不过，有的网友看着苹果6代的订单，却啃着寄过来的6袋苹果，个中滋味大家就自行脑补吧…。其实，在安卓应用分发领域，这种“苹果6代”变“6袋苹果”的情况也屡见不鲜：

为什么会出现这种情况呢？其实一次网络下载的过程，就像一次“网购”，当我们点击下载按钮时，就跟下载服务器下了一份“订单”，“订购”了一个文件（当然大部分是免费的），服务器确认“订单”后，就会将文件在网络中“快递”（传输）到用户的终端（手机、PC等）。下载劫持一般出现在“下订单”的过程中。

举个栗子，假设我们通过微信官网的链接http://dldir1.qq.com/weixin/android/weixin637android660.apk下载微信安卓版本的客户端，整个流程大概是这个样子：

当点击了下载按钮后，客户端会通过url中的“域名”“dldir1.qq.com”来向DNS服务器获取确认“订单（下载）服务器”的IP地址，IP地址在互联网中相当于日常生活中“电话号码”，有了它，就可以连接到这台“订单（下载）服务器”，而DNS服务器就像一个存贮着大量“姓名”（域名）和“电话号码”（IP地址）的黄页。

当客户端获得了“订单（下载）服务器”的“电话号码”（ip地址）后，就会连接“订单（下载）服务器”，并告知“订单（下载）服务器”客户端需要获取服务器上的“微信安卓版”apk文件，一般情况下，服务器在这个阶段确认了“订单”后，就会向客户端“快递”（传输）对应的apk文件，当客户端将文件下载完毕后，这次“网购”也就完成了。

下面，我们引入运营商（电信、联通等）网关的概念。运营商网关可以类比成日常生活中的“总机”，接入运营商的互联网设备想要能够“上网”，都需要经过“总机”（运营商网关）的转接。也就是说，在上图中的第二步，我们并不能直接通过“订单（下载）服务器”的“电话号码”（IP地址）联系到“订单（下载）服务器”，而是需要先连接到“总机”（网关），并且告诉它，我们要向某某某服务器下“订单”，经过“总机”的转接，我们才能真正连接到“订单（下载）服务器”。整个过程如下图：

可以发现，DNS服务器和网关的决策，确定了客户端“订单”（下载请求）的走向。而“下载劫持”也就发生在这两个关键节点上。

假设客户端获取下载服务器“电话号码”的DNS服务器被篡改，那么客户端可能会通过“dldir1.qq.com”查询到一个“骗子服务器”的“电话号码”（IP地址），当我们联系到这个“骗子服务器”时，我们的“订单”（下载请求）可能会换来一些奇奇怪怪的“商品”。

当我们遇到这种情况时，可以手动修改DNS服务器IP（具体方法请问度娘）来解决。然而当运营商的“总机”（网关）“出了问题”（这些“问题”一般是运营商主动造成的）时，就没那么容易解决了。

假设当客户端拿着“订单（下载）服务器”的电话号码要求“总机”（网关）转接到我们指定的“订单（下载）服务器”时，“总机”（网关）对客户端说“哎呀，不要去A家下载微信了，你去我给你介绍的B家下载“XX助手”吧，比微信好用”（这个过程在技术上是被一个叫做302跳转的机制完成的，如果你不知道什么是302，出门左转，查询我们星期一的文章）。客户端是个实在人，就这样被“引诱”到B家的服务器上下载了。

“总机”（网关）和服务器B就这样沆瀣一气，来骗客户端的下载量。

刚刚给大家从技术层面简单介绍了下“下载劫持”的“饭醉手段”，至于为什么有人要做“下载劫持”，想必产品同学们应该比我更能知晓其中的奥妙，我就不班门弄斧了。就写到这里吧，我去洗水果了，双十一寄来的六袋苹果，再不吃就烂了….

（文中“XX助手”和服务器IP地址均属臆造，如有雷同，我也不知道是咋回事儿）

原文链接：点击查看。

本文转载自「给产品经理讲技术」公号，已经过原作者授权转载。

相信大家对推送这项技术并不陌生。如果没听说过，那么作为一个充满好奇心的孩子，你一定想过这个问题：睡觉前我明明关闭了淘宝、网易新闻等app，为什么第二天他们又自动出现在我手机的通知栏上呢？这其实就是推送系统干的好事：在你睡觉的时候，服务器悄悄的向你的手机推送了一个消息，然后唤醒了你已经关闭的app。事实上，无论你愿意与否，现在大多数‘有节操’的app，都已经内置了推送系统，并时刻准备着登上你的通知栏的‘头条’。

传统的app架构里，通常是app主动向服务器请求数据，服务器被动的提供数据。以新闻客户端app为例：app被用户打开的时候，会通过网络(无论3g、4g还是wifi)连接到服务器上，向服务器请求最新的新闻。服务器收到请求，从自己的数据库里查询最新的新闻，返回给app。app收到服务器返回的数据，经过一系列的解析处理操作，最终把最新的新闻呈现给用户。一次通信就完成了。然而如果此时服务器上又有了新的新闻，无论多么重要，在用户没有主动刷新的情况下，是没有办法让用户看到的。推送就是为了解决这样的困境的，它给了服务器一个展示自我的机会，主动连接上所有的app，告诉他们我有新的新闻了，你们再来请求一次吧，于是收到推送的app（即时此时已经被用户关闭了）又去服务器请求最新的新闻，这样用户就能看到最新的新闻了。

从技术上来讲，实现一个推送系统需要服务器端和终端的配合。一种方法是轮询，也就是不停的向服务器发起请求。这其实很好理解，作为app，我既然不知道什么时候会发生新的新闻，那我一遍一遍的问好了，而且我知道这样一定会成功的。显而易见，这种方法app端费时费力不说，电量流量也扛不住啊，服务器要处理如此量大的请求，必然也是非常头疼的。另一种方法是服务器和app建立一个长时间连接的通道，通过这个通道，不仅app可以向服务器请求数据，服务器也可以向app发送数据，看起来非常完美，但是如果app被用户关闭的话，通道就断掉了。好在android系统给app提供了一个这样的环境，app可以启动一个后台服务来维持这个通道，即使app被关掉了，服务依然可以运行，通道依然还在工作（ios后面会讲）。回到前面的例子，你在睡觉前关掉了淘宝，但是并没有关闭淘宝的后台服务，淘宝依然可以接收服务器推送来的指令，把自己的唤醒。

那么如何维持这样的一条长时间连接的通道呢？就好比两个人打电话，一开始聊的热情有来有往，后来慢慢沉默下来了，几分钟之后，电话的另一头没有任何动静，如何知道那边的人还在呢？很简单，只需要另一头的人每隔几分钟说一个字就行。同样的道理，app会每隔一段时间向服务器报告自己还活着，就像心跳一样，服务器收到后，就知道这个通道是可以继续使用的了。然而天下没有免费的午餐，发送心跳是有代价的，一般手机锁屏之后，为了省电CPU是出于休眠状态的，然而发送心跳就会唤醒CPU，必然会增加电量的消耗。这还只是一个长连接通道的情况，如果手机里装了2、30个带有推送的app呢？先别急着抱怨，聪明的android工程师和ios工程师早就想到了这一点，他们分别设计了GCM和apns来解决多个app有多个长连接通道的问题。以apns为例，ios开通了一条系统级别的长连接通道，通道的一端是手机的所有app，另一端是苹果的服务器。app的服务器如果有新的消息需要推送的话，先把消息发送到苹果的服务器上，再利用苹果的服务器通过长连接通道发送到用户手机，然后通知具体的app。这样就做到了即使手机安装了100个app，也只需要向一条通道里发送心跳。

回到Android，系统提供的GCM只能在Android2.2以上才能使用，3.0以下必须要安装Googleplay并登陆了Google账号才能支持。而国内发行的手机大多是阉割掉了google 服务的。因此，对于Android系统来说，各家app只能各显神通，开发自己的专用长连接通道了。然而这时候他们遇到了app的天敌：管家和卫士们。前文说了，app想要及时收到服务器推送的消息，关键在于自己与服务器的长连接通道不被关闭，也就是自己的后台服务可以一直在后台运行，而管家和卫士们的一键清理功能就是专治这种“毒瘤”的。道高一尺魔高一丈，app在与管家和斗士们的长期斗争中，总结了一系列躲避被清理掉的方法，什么定时自启能力、什么相互唤醒、什么前台进程等等，当然这就是另一个话题了,我们后面会讲到。

总结起来，app和后台的连接方式有两种。一种叫pull，也叫轮询，就是定期的不断向后台请求，缺点是耗电，费流量，不环保。对于一名有追求的程序员，他应该会比较恶心这种方式的，你千万不要对他说，我不管你怎么实现，我就要这种效果这种傻逼话了，凡事应该找到最优路径。另一种叫push，app和后台一直维持了一条通信通道，两端不定期的就会偷摸的约会，告诉对方“I‘m Here”，也能顺带把信息互相携带了。缺点是要维持一条长连接通道，这条通道容易被其他程序杀死，要多想复活办法。

原文链接，点击查看。

本文转载自「给产品经理讲技术」公号，已经过原作者授权转载。

目前，除了一些特别简单非联网类应用（比如计算器、闹钟等），几乎所有的应用均是联网应用（比如新闻客户端，微信等等），这些app客户端基本都只是负责用户的交互与数据收集与展示，真正的数据和服务均存储在云端。

那移动端究竟如何和后台来交换数据并展示呢？我们打个比喻，其实整个过程跟去烧烤店儿撸串一样一样的。

拿任意一个新闻客户端举例，当用户刷新的那一刻（你萌生了吃烧烤的想法），客户端开始组织数据请求（你开始穿衣洗脸打扮，并思考该去哪一家吃呢），当用户界面开始展示loading的时候（这个时候你正走在“马大姐烧烤店”的路上），经过几百毫秒的时间，这个时候请求数据已经到了服务器（你已经坐在了马大姐烧烤店的桌子上），服务器开始查看客户端想要请求哪方面的数据，是请求财经频道的，还是请求汽车频道的数据（服务员递来了菜单，问你想吃啥），服务器看懂了客户端的想法开始准备数据（你点了20个肉串，10个大腰子），服务器看到你请求的是汽车频道和财经频道的数据（光着膀子的烤串师傅开始烤这20个串和10个大腰子），并给回到服务员，服务员一路小跑，将你要的串和腰子递到你的面前，这个时候相当于数据已经传回到了客户端，客户端loading消失，你看到了最新的两个频道的数据。

那客户端和服务器之间传输数据的格式是怎么样的呢？

现在流行的做法通常有两种，一种是类似于PB（Protocol Buffer，Google定义的一个数据传输协议，以简洁，省流，易用出名）的二进制数据（二进制数据的意思就是你打开这个文件你只能看到0和1组成的数字串，是没办法和你生活中任何认识的字母联系在一起的）传输，这种格式的好处是包小，重复的字段会被节省。另一种是JSON（JavaScriptObject Notation），这也是一种轻量级的数据传输格式，就是用一堆中括号把数据组织起来，不像二进制，这种格式是人可读的，并且比较轻巧，所以也有大量的应用场景。下面这段数据就是JSON格式，简单解读一下，就是people对应了三个人，三个人分别是中括号间的三个花括号中的人。

总结起来，十分简单，移动端提出需求，服务器按要求组织好数据发给你，针对不同的格式，移动端自己解析，展示，完活儿。其实，不止移动端，前端网页和后台，后台和后台之间也是这个道理。至于在传输的过程中都经历了什么，我们找机会再细聊。

原文链接：点击查看。

本文转载自「给产品经理讲技术」公号，已经过原作者授权转载。

想想平时用的App，你非常确信在浏览一个网页，然而需要登录时，它却唤起了你手机里的QQ或是微信，你不再需要输入帐号和密码就可以让你浏览的网页获取你的登录信息，这一切只发生在你指尖的两次点击。而在手机上，网页越来越炫酷，你都很难区分你在点击的是一个原生界面（指Native应用程序，说人话就是android app或ios应用）或仅仅是一个H5页面。你的操作一直穿梭在网页与原生界面之间，比如一个网页中的电话号码，点击就可以拨打电话，这种网页和app交互这一切是如何实现的呢？

这项能力在安卓中叫做Js2Java（ios上也提供类似的技术），很好理解，从Js到Java，从网页到app，他们是双向通信，可互相调用的，市面上大量的App程序，都在利用这项技术，微信更是本质上利用这项技术打造了公众帐号整个体系，使得创业者用一个简简单单的网页就打通了帐号、身份、支付、客服、售后等一系列操作，虽然简单，但是真的将移动互联网的Web生态囊括了更广阔的内容，也是移动互联网较PC互联网更优越、更猛烈的点之一。

以Android系统为例，Android手机上的App是使用Java语言编写的，而网页中则运行着一些Html、Javascript编写的代码，虽然Java和Javascript名字看起来像亲哥俩，但它们其实没有一毛钱关系，一个是编译型语言，一个是解释性语言，不多扩展，说不上哪天我就会写写编译型和解释性语言的区别。Android的App是通过WebView（请亲理解成一个组件，想象WebView就是一个没有任何操作按钮的浏览器，你输入baidu.com他就打开了百度的页面）来展示一个网页的，同时WebView为网页和原生App建立一个桥梁，让网页和原生App能够看到彼此暴露的一些方法，从而达到互相操作的目的。

当然，这些操作是需要前端页面和终端程序互相协商的。虽然很多App遵守了一些相同的原则，使网页在不同的APP中都能具备相同的能力，但是如果你看到同一个网页在一个App中能够调用一些安卓系统的能力，而在另一个APP中却没有对应的能力也不要觉得奇怪（找对应App的开发勾兑一下就好了）。

一个原生应用为网页开放的能力越多，网页对原生系统的操作能力就越强，就越能做出逼近原生应用的体验。但是，这却是一把双刃剑，因为原生App开放的能力有可能会被恶意的页面利用，对用户造成伤害，如何控制能力的开放，也是需要产品和开发一起思考的问题。例如微信是一个终端能力的宿主，拥有支付，登录，分享，获取App信息等能力，并以Js接口的形式提供给前端页面使用，前端开发则需要在微信申请对应的Js接口使用权限，才能够在微信中正常使用对应的能力。

最后总结一下，网页塑造界面的优势在于灵活，随时可以更新，而原生APP塑造的界面则能够提供更流畅的用户体验，但是却无法热更新，只能依靠发布版本来提供新功能。通过上面说的这种技术，就可以利用各自的优势，规避各自的劣势来提供更好用户体验，例如在微信中购物的展示是网页形式的，方便运营快速更新，通过Js接口调用起原生的支付界面，给用户更流畅的支付体验，提高支付成功率。

原文链接：点击查看。

一直以来，关于产品经理是否需要懂技术的话题就没有间断过。

产品经理不懂技术，需求异想天开，技术会认为产品经理瞎指挥不靠谱；

产品经理懂技术，需求太现实，实现上甚至都直接打技术的脸，技术会认为产品经理约越过了自己的边界里来…

实际上，产品经理不需要懂技术实现的细节，但是，应该懂一些技术原理的。

所以我就特别的想在我的公众号里能有一些关于产品经理需要知晓的浅显的技术原理的文章。

偶然间看到了「给产品经理讲技术」这个微信公号，关于技术的部分写的浅显易懂，言简意赅，确实很赞。

于是，跟公号作者商量，经过授权，可以将他的全部文章转载到我的公号上来。

他只要继续更新，我都会在读完之后挑选我认为很不错的文章选出来给大家看。

每篇文章的末尾，原文链接我都会尝试放原作者的公众号链接，大家可以在那里关注他的全部内容。

当然，除了懂技术，产品经理还需要懂点运营、懂点营销、懂点情趣。如果你正在用心的写，我也同样可以利用我的公众号，帮助你做宣传，只要你的内容足够的好。

绵薄之力，愿产品经理们能获得更多对自己有用的内容。