上篇文章简单的说了下自己对看了那么多书仍然做不好产品的理解，随后打算梳理下自己目前掌握的一些零碎的知识点，目的是为了初步形成自己的知识体系，文章按照一个功能从需求到上线的全流程来组织的。

上篇文章主要写了需求分析和竞品分析这两部分，这篇文章主要是方案设计》评价体系，感兴趣的可以去看一下上篇文章。

为什么看那么多书，依然做不好产品（一）

方案设计

方案设计应该是我们日常工作中做的比较多的事情了，不太清楚大家的工作流是怎样的，我自己的流程一般是流程图》思维导图》原型图》PRD。

通常情况下，我们工作中会出现的流程图可能会有3种，分别是业务流程图、任务流程图和页面流程图。业务流程图主要是为了梳理整体的业务，任务流程图是将为了对单个的任务进行更细致的说明，很多时候面对的受众是开发人员。

之前单独写过一篇流程图相关的文章，感兴趣的可以去看下：

产品设计之流程图

页面流程图其实我基本没有画过，因为之前用的是Axure的链接跳转来替代，但是最近方案评审的时候遇到了一些问题，UED总监和产品总监说不能直观的了解整个方案的上下游流程，不便于方案评审和走查，我在考虑要不要尝试着把页面流程画一下，先交代整体的背景。

在《锦绣蓝图 怎样规划令人流连忘返的网站》这本书里将页面类型分为了3种，分别是导航型、消费型和交互型，这3种类型的划分应用到App里，依然是成立的。

如果要绘制页面流程图的话，就要把这3种类型区别出来。导航型的页面主要是告诉用户在哪，为用户提供可访问路径，消费型的页面顾名思义就是需要用户沉浸到内容中去体验的页面，交互型页面主要涉及到表单填写、信息处理等。

很久以前，我在产品结构、功能结构、信息架构这三个词之间纠结了很久，当时也看了很多网上的文章，初步算是把这些所谓的名词弄清楚了，后来又给忘了，因为对实际工作基本没啥用（仅适用于本人）。

当时在一篇文章里看到说信息架构就是关于所有字段信息的，是为了帮助开发人员建表结构，当时觉得挺有道理的，就天真的那么以为了。今年上半年的时候看完了《信息架构：超越Web设计》这本书之后，我是再也不敢随随便便提信息架构这个词了…

信息架构至少包含信息的结构设计、组织、展现等部分，更详细的说会包括叙词表、受控词表和元数据、组织系统、标签系统、搜索系统、导航系统等…区区一个表示字段信息的脑图就敢自称为信息架构？

之所以会引申出这3个名词，是因为确实有很多没有入门的人成天在想办法把这几个词弄清楚，后来你会发现纠结于弄清楚这些定义概念对你的工作可能并没有什么实质性的作用。

首先，概念是人定义的，不同人定义的标准是不同的，目前也没有统一的标准，其次，我们是实战派，不是理论派，更重要的是可以落地，最后，文档是需要给其他团队成员的，你认可的东西就默认为他们也认可么？

我只说一下现在我的理解和我的处理办法，我现在的理解是产品结构和功能结构可以看作一个东西，只不过颗粒度大小不同而已，信息架构如上文所说，是一个复杂的系统工程。

我现在的处理形式是会用3种不同的思路来绘制脑图：

• 一种是纯粹的信息，基本上都是名词，用来组织页面元素；

• 一种是动词短语，按照用户的使用流程来组织，类似于用例图和流程图；

• 一种是按照产品的功能模块，类似于产品设计者的组织形式。

个人觉得这3种东西还是不要杂糅到一起好，2、3倒还好，只是颗粒度大小不同，1、2本身就是不同维度的东西。我这样划分的目的如下：

• 第一种是为了方便信息的分类，更好的组织内容布局和确定信息的优先级；

• 第二种方式是为了模拟用户的使用场景，避免功能的遗漏，多用于具体功能的细化；

• 第三种方式是为了思考功能模块之间的层级关系和相互关联。

以前我在设计一个功能的时候，只单纯的思考这个功能，现在慢慢的发现自己思考的东西多了。对于一个新功能，不光要考虑功能本身，还需要考虑同向关联性、前向兼容性和后向延展性。

同向关联性指的是这个功能可不可以结合现有的哪个功能产生点新的可能性，对现有的哪个功能有没有正向或者负向的影响。前向兼容性包括功能、版本、数据等，后向延展性一方面是后期的功能扩展，另一方面是万一功能下线的话，那挖的坑会有多大…

这个可能就是我们这群线框仔面对的比较多的东西了，应该会占到整体工作时间的10%左右，有的人可能会问，产品经理画原型，那交互设计师呢？

大多情况下纯交互设计师是不存在的，我们公司虽然有交互设计师，但资源根本不够，最多在最后需求评审的时候发表一下意见。而很多中小型的公司，很有可能根本没有交互设计师这个角色，所以自己画吧。

以前我画原型一般都是用的Axure，也用过墨刀，大概可能也许是我用Axure用的久一些的缘故吧，墨刀用起来总感觉不顺手。最近在转Sketch…并不是我想转，而是我们的老大们看惯了其他产品的中／高保真的原型，我这种低保真的线框图总显得格格不入。

我个人的观点是原型只是一个中间的过渡产物，是为了快速验证想法的，整个周期越短越好。只要能够将方案清晰直接的传递给团队成员即可，至于是什么形式，其实并没有那么重要。然而，也是需要结合团队文化的…

这部分的主要受众就是我们的开发同事了，虽然大概率事件是开发根本不会看你的文档，或者草草的看几眼…

文档写了，开发没做，到时候你还有机会找他们理论，要是文档里压根就没写，那到时候再去找开发，那就呵呵了。当然有些开发同事是巨靠谱也是巨给力的，这样的队友，口述需求说明都问题不大，具体如何还是要结合团队情况的。

之前专门写过一篇PRD相关的文章，感兴趣的话可以去看下。

产品从0到1之如何撰写PRD

整体来说PRD包含两大部分，分别是功能性需求和非功能性需求，前者主要是该需求相关的功能部分，是为了说清楚这个功能的具体实现细节，后者主要指的是数据需求、埋点需求、兼容性需求等等…

功能性需求我一般是直接标注在原型上，主要可以分为流程说明和交互说明这两部分。

流程说明可以按照用例的形式来考虑，比如主线流程是什么，有没有分支流程，异常流程怎么处理，有没有前置条件，有没有后置条件。其中比较坑的会是异常流程，特别是对于新人，大概率下可能会遗忘，被开发challenge到就会比较尴尬。

记住一个要点，凡是有正常的肯定就有异常，这两者是成对出现的，比如有成功，那肯定就有失败，有网络正常的情况，那肯定就有网络异常的情况，有数据那肯定就会对应着没有数据的情况…

交互说明主要会包含限制、状态、操作、反馈，此外还有权限获取，数据的来源、加载、显示规则等。不再一一赘述，之前写过的PRD文章里面有详细说明。

最后，重点说一下，不要忘记埋点，不要忘记埋点，不要忘记埋点。

设计一个新功能的时候，一定要记得埋点，不然等功能上线之后才发现没有埋点的话，就会很尴尬，一方面是新功能上线之后这段时间的统计数据会没有，另一方面埋点也是一个周期比较长，又容易出错的环节。

一言蔽之，埋点会是一个坑，尽量避免掉进去（然而我已经掉进去了）。

评价体系

不少小伙伴对这个东西可能会有些陌生，方案都出完了，不该方案评审、设计沟通、开发沟通等等等吗，这个评价体系又是个什么东西。说实话，以前我也没有过多关注这部分东西，只隐约知道一句话叫做“上线前有预期，上线后有对比”…

这里说的预期，其实就是评价体系。因为我们上线一个功能是基于某个假设的，而我们并不清楚假设是正确还是错误，也不清楚功能上线之后有没有成功，或者说何为成功？

这个评价体系就是为了验证我们上线之前的猜想而存在的，没有上线前后这两部分的对比，我们就不知道自己做对了还是做错了，没有反馈，就很难有提高。

可以简单的把功能分为新增功能、优化功能和删除功能这3类，不同的类型需要关注的数据指标肯定是不同的，核心的思想就是多维度对比，主要方法就是对比上线前后的数据表现。

新功能主要是对比使用新功能和未使用新功能的用户行为数据表现，优化功能和删除功能则需要结合不同版本的数据来进行对比。

下面我就简单的把自己思考的一些想法和大家分享一下，不一定正确，也不一定全面，先抛出来，后续再迭代。主要是从用户和场景、功能使用、功能留存和功能关联性这几个维度来考虑的。

之前的文章里也提到过这样一种想法，那就是用户、场景和问题构成了一个功能的起点。那对应着的第一个问题就是这个功能是给哪个类型的用户用的？

是新用户还是老用户，或者对应着另外一种分类方法，是给新手用户、中间用户还是专家用户使用的。此外还有性别、年龄等其他的维度。

这是预期的用户类型，那么实际上线之后的用户使用的类型又是怎样的，和我们预期的有没有出入，如果有的话那后期如何迭代呢？

关于场景我考虑到的是一个用户行为路径，以电商类的产品为例，用户下单的来源分布都是什么，搜索、商品浏览、购物车、收藏夹这些功能的成交占比都有多少？

如果这个时候新上线了一个为你推荐功能，那预期这个功能可以带来多少的UV、PV，最后促成的订单量在成交来源占比中能够占到多少？

首先是一个功能使用的基础数据，比如使用人数、使用次数、使用率、使用频次、DAU占比等，结合不同的产品性质可能会细化出其他的数据，比如使用时长、完成率、完成时间等。

其次就是功能的使用方式，以内容型产品的分享为例，我们并不清楚我们的目标用户会分享哪些内容到哪些渠道，那这个时候就需要追踪用户分享内容的类别占比和渠道分布了。

然后就是用户使用功能的分布情况，比如使用功能XX次以下的有多少人，XX-XX次的有多少人，这是针对基础数据的进一步细分。如果我们仅有用户的整体使用情况，会导致很多用户的行为被平均掉，最终导致我们很难发现真正的问题。

以用户的等级体系为例，我们理想的等级数量分布肯定是符合正态曲线规律的，功能上线之后，就可以对比实际的用户分布来看是否满足该规律，如果不满足的话可能等级门槛设置的较低或者较高了，更有甚者可能是这个等级体系对用户根本没有吸引力…

功能留存主要是用来衡量功能黏性的，产品有着黏性，功能同样也是有的。

以音频类的产品为例，在网络不佳或者移动网络下，用户可能会遇到一些问题，假定我们认为这是当下需要迫切解决的一个问题，于是就上线了离线缓存的功能。

如果我们判断正确的话，那这个功能使用的留存率会比较高。如果上线之后发现数据惨淡，那说明我们的判断有错误，或者功能本身做的有问题，导致留不住用户。

一般情况下，产品类型、产品性质确定了的话，留存基本上都会有一个上限值的，想突破这个上限，基本没可能。

如果说新增、优化或者删除一个功能是处在某一个流程里面的，那这个时候就需要考虑这个功能的变化对上下游环节的影响，对各步骤的转化率会有什么影响，对整体的转化率会有什么影响，反应在数据上大概会有什么变化。

此外还有一种情况就是这个功能和其他功能会有联动效应的，比如使用了A功能的用户，在大概率上也会使用B功能，或者说使用了A功能之后，用户的留存和使用时长都会增加，那这个时候就需要结合其他关联的东西来看了。

比如之前看到的一个案例里面，在某款资讯类的产品中，新用户的留存率相对较低，而关注了更多优质主题的用户的留存和使用时长都相对较高。

他们的产品经理猜测新用户流失是因为还没有来得及发现更多优质的内容，于是他们就上线了一个针对新用户的关注引导模块，那这个功能就需要结合着其他的一些数据指标来进行验证了。

以上就是对功能评价指标设计的一些考虑，最核心的思想在于上线前有预期，上线后有对比。做了XX功能，预期会取得什么反馈，哪些数据指标会变化，如何变化，最后结合实际的数据再来反推开始时的决策是否正确。

最后

本来是打算这篇文章把剩下的内容写完的，写着写着发现越写越多了…还有一些内容就放到下一篇文章写好了，文章太长你们也很难有耐性看完，所以我一般会将文字控制在3K-4K字的样子，这篇文章已经超了不少了。

本文主要是关于方案设计和评价体系这两部分的，最后还有的部分是关于运营和复盘方面的。

正文完，欢迎斧正、指点、拍砖…