IT瘾产品设计推荐

华为流程体系：IPD流程框架

Fri, 16 Jun 2023 14:39:25 CST

本篇文章作者介绍 IPD 体系主体框架所涉及的一些相关内容，并详细介绍了其三个核心思想：市场管理、流程重组、产品重组。IPD是灵活发展的，熟悉掌握IPD这一思维框架，能对我们日常生活有很多帮助。

今天主要来谈谈 IPD 体系的主体框架所涉及的一些相关内容。

其实关于 IPD 体系，我在之前的文章中都有过不同程度的讲解。

但是，由于这个体系所涉及的面是非常广泛的，这个时候就必须通过一系列的延伸内容从不同的维度来分析和讲解。

只有通过这种方式，才能够让大家最终在工作或者生活中去应用、去思考。即便是你在日常生活中想到了 IPD 这个结构化的思维框架，这也是很有价值的一件事情。

IPD 的全称是指集成产品开发。IPD 的核心思想最早是来源于美国 PRTM 公司的 PACE 理论。

如果大家对 PACE 感兴趣的话，可以看一下《培思的力量》这本书。这套理论详细描述了业界最佳的产品开发模式所包含的各个方面。

后来经过 IBM，以及华为这些企业的实践。IPD 已经成为一套包含企业产品开发的思想、模式、工具的系统性工程。

如果从客户需求到客户满意这个维度出发，也就是从“以客户为中心”的角度出发。

可以将企业的业务划分为三个主要的业务流程。也就是下面这张图所展示的：

第一个是集成产品开发：IPD 流程。这个流程解决的是如何满足需求的问题。
第二个是从线索到回款：LTC 流程。这个流程解决的是如何回款的问题，也就是如何实现企业的商业变现的问题。
第三个是从问题到解决：ITR 流程。这个流程解决的是客服服务的问题。

尤其是对于这个高度行业内卷的时代，你比别人的服务多做一点，客户就可能更愿意选择你。

其中，IPD 流程中融合了大量的优秀的业界实践，主要就涉及：

并行工程。
瀑布式开发流程。
跨职能团队。
产品及周期优化法 PACE。
门径管理流程等。

大家可以看下面这张图。

讲 IPD 体系，就一定绕不开 IPD 的核心思想。

IPD 的流程本身会随着时代、新方法的创新，在动态变化着。

这个时候，核心思想便是 IPD 体系的“根”，起到指导和稳定剂的作用。

IPD 的核心思想包括三个板块，分别是：

市场管理。
流程重组。
产品重组。

大家可以看下面这张图：

下面简单拆分一下。

第一个核心思想：研发是投资行为。

业务经营有两条主线：

一个是实现公司的商业目标；
另一个是满足客户需求。

第一个是为了企业的可持续发展，第二个是企业存在的基础。两者缺一不可。

因此，要把所有研发项目作为投资对象进行组合管理。包括产品开发、平台和技术开发，以及研究类项目。

从一开始就要考虑产品、服务、解决方案和技术的投资回报率。

第二个核心思想是基于市场，也就是需求的开发。

满足客户需求是企业生存的基础。

无论公司战略、市场规划、产品技术规划、各功能部门的规划，还是产品和技术的研发。

甚至是公司其他运营活动，都必须围绕客户需求进行展开。

第三个核心思想是跨部门的协作。

创新和研发是全公司的行为，接力棒式的产品开发流程是很难保证产品质量的。

在 IPD 体系中，无论是需求管理、产品和技术规划、项目任务书开发、产品和技术研发、产品上市，还是上市后的生命周期管理。

都会广泛采用跨部门团队，这样就可以汇集各个领域的专业智慧。

然后形成合力，共同满足客户需求，为产品的商业成功负责。

第四个核心思想是平台化的开发。

为了提高产品、服务、解决方案的开发效率，就需要通过需求管理、产品和技术规划提前识别公共技术和关键技术。

然后单独立项开发，这样才能在产品开发过程中调取这些资源。从而在快速响应客户需求、提高质量、降低成本上同时取得领先优势。

第五个核心思想是结构化的流程。

IPD 体系中的各种流程被划分为若干个阶段。

而且在每个阶段都设置了评审点，按角色归集流程中的活动，便于与组织结构相互匹配。

第六个核心思想是持续改进：灵活发展，与时俱进。

IPD 是灵活发展的，必须在不断吸取业界最佳实践和解决业务问题的过程中与时俱进。

持续变革和优化，以便适应 VUCA 时代的 IPD 体系。

专栏作家

卫朋，公众号：产品人卫朋，人人都是产品经理专栏作家。关注智能硬件领域，擅长市场分析、产品设计开发、生产管理等，喜欢阅读和爬山。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

如何写一篇挑不出毛病的需求文档？

Mon, 13 Mar 2023 18:16:17 CST

作为产品经理，撰写需求文档是一门必须掌握的基本功，那么除了知道需求文档应当包含哪些内容，你知道需求文档究竟应该怎么“写”吗？怎样才能写出一份可以让每个项目成员都能清晰明了得到所需信息的PRD文档呢？一起来看看作者的经验分享。

前言

需求文档是产品经理的基本功，也是产品能力的体现，产品能力行不行看文档就能看出来。

我从实际工作+日常总结，整理了一些自己写PRD的方法，分享给各位，希望能对各位有用~

一、原则与前提

在文章开始前，我们简单看下在什么时候用、谁去用，来明确需求文档的书写原则：

产品需求评审的时候看；
研发技术方案设计、敲代码的时候看；
UI进行界面设计的时候看；
测试写测试用例、执行用例的时候看。

PRD 文档的目的就是让每个项目成员知道需求为什么做、要做什么、怎么做。

所以可以得到PRD的书写原则有：

有理有据：从项目成员知道为什么做；
全面、清晰、准确：让大家知道做什么、怎么做；
易读性：让大家方便快捷的理解文档内容。

明确了原则，还有 2个前提：「需求类型、需求大小」

需求类型有：功能需求、接口需求、性能需求、策略需求、埋点需求、统计需求等等。
需求大小：可以是从0-1的大项目，包含上边的所有需求类型，还有就是日常迭代版本的小需求。

我们接下来文章内容都是基于以上原则与前提，接下来正文开始~

二、需求文档用啥写

我们以终为始，先看需求文档的呈现方式。目前主要有以下2类：

1. Axure一体化需求文档

使用Axure将全部需求文档，最终通过Axure打包提供出去。好处是方便查看，看原型的基础上又能看文档说明。但有一种不是很“严肃”的感觉。

2. Word版

通过Word进行需求描述，并统一提供。容易留存，也比较正规，在阅读上以文字为主。

具体选择那种方式，可以先看公司要求。

像我之前有公司要求，必须用word，就算是有大量原型的，也只能把页面原型画好，然后再复制到word里，在word写需求内容。

如果没有要求，具体采用的方式可以看不同的需求类型：

如果只涉及到画原型的，可以使用Axure。

如果只有偏后端需求的，逻辑相关的需求，比如说是接口需求、算法需求，并不涉及到前端需求的，我们可以直接使用word写。

如果是做的大项目，同时有功能需求，又有接口需求、算法需求的，我建议都放在一起，比如说都用Axure写需求。

我之前做新项目的时候，同时提供了功能需求的axure文档+word版的接口需求，后来用例评审的时候，测试说不知道word版接口需求，之后我就统一写在axure里了。

三、需求文档包含哪些内容

需求有大有小，同样的需求文档也有大有小，小到直接一句话描述，大到上百个原型页面，好几万个字。

一句话的需求我们在这就不说了，我们说下正常的需求文档。

不论是使用Axure还是word，也不论需求大小是什么， PRD文档中一般需要包含以下内容：

1. 文档修改记录

需求文档在需求评审、研发、测试过程中一定会改的。

比如说加个限制，补充个遗漏的逻辑等等，不过我们一定要记录下修改内容，并及时更新需求文档、及时同步项目成员。

一般通过表格展示出以下内容：

修改内容：说清楚修改的哪个模块，哪个页面、哪个功能点。当然也可以分成修改模块、修改页面多个列。
修改原因：就是为啥要修改，比如说逻辑缺失需要补充等等。
修改人：谁改的。
修改日期：修改时间。

在使用Axure时，我们可以在文档修改记录中加上文本链接跳转，项目成员点击文字可直接进入到对应页面查看。

对于word，也是同样的，加个文档修改记录。

对于文档修改记录，不仅在PRD文档中可以用到，在写其它文档时都可以加上，比如操作手册。

2. 项目背景 or 需求背景

背景同样也是有大有小，对于新项目，则需要介绍下整个项目的大背景。对于每个需求，我们同样也可以简单说下需求背景。

参考格式如下：

当前的现状是什么，有哪些问题/痛点，这些问题导致了什么结果，为了解决这个问题，我们需要采取什么动作，达到什么目的，能够获取哪些收益，产生什么价值。

3. 名词解释

如果有专业名词，一定要写上。

在不同行业、不同公司、不同团队中都有专门的名词，项目成员是不明白一些名词的，这个时候一定要说明。

比如说抗菌药物DDD值，绝对的专业名词，不说一般没人知道。

另外在说名词解释的时候，尽量加上示例说明方便大家快速理解。

4. 流程图

当涉及跨角色、跨系统、跨模块、多判断逻辑时，我们一定要画出来，让各方更快地了解产品流程。

流程图同样有大有小：

包括整体产品业务流程图、单个模块的流程图、单个功能的流程图。

1）整体流程图

为了将这个产品的功能业务串起来，可以不用画的太详细，画出大的概览图，从大而全的角度将这个项目表达出来。

一般是在0-1的新项目中画，日常迭代的需求中不需要。

2）单个模块功能的流程图

当一个功能模块功能很多时，为了将模块内的功能串起来，说清楚单独模块的流程，这个就要画的细致一点。

当涉及到新的模块时一定要画。

3）单个功能的流程图

对于复杂的单个功能，涉及到的处理逻辑比较多时，我们也需要画出单独的流程图进行说明。

流程图的类型有很多种，像业务流程图、页面流程图、泳道图、uml里的时序图、用例图等等。

我们可以基于不同流程图的特性去选择不同的类型，比如有多角色时，我们可以使用泳道图。

对于UML，像用例图、序列图，在画的时候有一定的门槛，同样的一定会有团队成员看不懂。我是从来没画过，所以大家可以自行选择学习与绘制。

对于页面流程图，是表达出页面之间的跳转逻辑，像移动端的页面，我们可以直接平铺出每个页面，展示出页面间的跳转逻辑。

对于PC端产品，页面尺寸较大，我们可以通过页面名称展示出页面流程。

流程图的能够达到业务清楚，表明重点，项目成员能够快速理解的目的就行。

5. 需求说明

对需求的详细说明，这一点肯定是必须的，我们下边单独说。

以上内容是我认为在写需求文档时，需要包含的内容，下边的内容我们则可以自行选择~

1）产品架构图

在0-1产品搭建的时候进行展示，将整个产品抽象化，通过数据层、服务层、应用层、展现层等抽象层面表现出产品的整体架构。

来自Processon

产品架构图是非常大的层面，当你没有独立负责一条业务线的时候，很难有这种大的架构概念。

当你需要规划一条产品线的时候，可以画出来产品架构图，让之后的产品方向再这个大的框架下去走。

我也是在最近这2年，独立负责产品线的时候才开始绘制的，主要是和领导们汇报使用的。

具体怎么画，大家可以在平台上搜一下，有很多。

2）功能架构图 or 信息架构图

对于功能架构图，就是写清楚产品功能的层级架构，简单说就是一级菜单、二级菜单是什么，每个菜单里有哪些功能，展示出功能的层级关系。

我一次都没有画过。

对于功能架构的展示，我一般在画原型的时候规划出来，然后直接画原型。

当然也可以通过思维导图的方式画出来，但是吧，画出来也没人看。

还有一个信息架构图，这个我也没画过。

我有很长的一段时候都没整明白功能架构图与信息架构图有啥区别~

现在我的理解是：

功能架构图是展示出功能层级关系，体现出菜单-功能的层级逻辑。
信息架构图是展示出每个功能页面内的展示字段内容，主要用于研发设计表结构与表字段。

对于功能架构图和信息架构图，一般是在产品0-1的时候画，而且涉及到的内容比较多，多的内容一定没人去看。

到底要不要画是一方面，大家一定要知道功能结构图和信息架构图是个什么东西，具体画不画大家自行选择。

四、画原型写文档

需求类型里有一个功能需求，这个就是每个产品避免不了的，所以我们单独说下画原型+写文档~

1. 首先根据要做的需求范围进行分类

当有多个需求类型时，按类型进行分类，使用Axure时可以通过建立文件夹。

使用word则可以加个一级标题。

目的是将需求有层级的依次展示出来。

然后在不同的文件夹下，在进行分级。

比如「功能需求说明」文件夹下有多个功能模块，则按照模块/菜单名称建立子文件夹，然后再在每个模块下建立对应页面；

当同一个页面内有多个tab页/子页面时：

对于PC端，我一般是分页面说明；APP的页面尺寸小，我们可以在一个Axure页面内统一说明。

然后再对每个页面单独画原型，写文档。

2. 需求文档的表现方式

当采用Axure写需求文档的时候，常见的布局是：左图右文。

左边展示原型图，右边展示需求说明。

对于word版，常为：原型页面展示，单独写文档说明。

3. 提取公共逻辑，放入全局说明

在画原型、写文档的时候，一定会有相同的功能逻辑、相同的需求逻辑。

例如说后台系统，会有一堆的列表，列表就涉及到分页数量、默认排序等。

我们可以直接统一使用全局说明。

将相同的功能逻辑、需求内容当在一个单独的全局说明里，在全局说明里进行单独说明。

当在某个页面中需要说明的功能点已经在「全局说明」里存在时，可以加个说明：请见全局说明。

同时对文字添加文字跳转链接，阅读者点击可直接跳转到对应的全局说明页面。

3. 功能点序号标注

先画出原型图，在原型中标注「序号」，然后在右侧按照相同的序号进行功能需求描述。

标注顺序：一般按照从左到右，从上到下的顺序。
标注哪些点：需要进行功能说明的功能点， 但是并不意味着每一个点都要进行标注。

我一般按照 从大到小，按照模块化的方式。

以下方的表单页面为例：

当原型画出后，在页面上标个序号[1]，对页面进行下简介，一般说明页面是什么，使用角色是谁。

然后继续标注「返回」，对「返回」进行说明。

因为点击返回时，没有添加其它判断逻辑（如是否二次确认），所以直接描述交互逻辑即可。

然后接着对下方的「患者信息」进行标注。

我们可以看到「患者信息」里有很多字段，我不建议对每个字段进行说明。

我们直接对「患者信息」整个模块进行标注，然后对每个字段进行说明。

由于只是表单输入，我们需要说明是否必填、采用什么组件、是能输入文字、还是数字输入框，数字范围限制、数字小数点限制（如最多2位小数）、输入小数点超过如何处理（是直接限制输入，还是能四舍五入）、字符长度限制、当字符输入超长如何处理。

如果是采用选择框，选择框里的值是写死的，还是从哪里取值。

……

这就是对需求的描述，我们需要尽可能的写全，就是尽可能的把考虑到的限制加上，你写的越全，在评审的时候，才会少挨怼。之后的需求变更才会少。

（现在看其实上边的需求描述还是不全，比如漏了小数点位数说明，文本输入框内能不能输入表情emoji符号等等）

当页面内出现弹窗时，我们需要对弹窗里的内容进行说明，单独对弹窗里功能点进行标注，然后再下方继续对需求进行说明。

对于弹窗里的内容，我一般从「1」开始重新编号。不把序号顺序和其他页面夹杂在一起。当调整一个功能点后，需要重新编号，增加了多余的工作量。

4. 需求详细书写

对需求的详细描述，是最核心的内容，我们可以按照下方的格式来写：

标题：功能点名称。
角色权限：如当前登录用户角色为管理员时，则显示此按钮。
规则逻辑：主要有 校验逻辑、前置条件、触发时机等，当涉及到的校验逻辑太多时，可以采用 分行分段、添加序号、使用表格等方式，将每个逻辑有条理的全部说明清楚。

比如：确定按钮。

当角色为「管理员」时，展示出确认按钮；

当XX未填写时，按钮显示为禁用状态，点击时出现toast提示：请填写XXX。
当XXX、XXX全部填写后，按钮置为可点击状态，点击后跳转至XXX页面。

极值说明：如输入框输入字符的长度，数字输入的范围值。

交互说明：如点击调整至XXX页面。

在写需求时，根据不同的需求内容，尽可能的将全部内容写清楚。

这个时候一定会有一个问题：写不全。

我们可以明确一点，没有产品经理把所有情况都考虑到，乔布斯、张小龙也考虑不了那么全。

我们需要做的是尽可能的考虑全，尽可能是个很虚的词，受行业经验、项目经验等影响，不同级别的产品经理的需求文档写的水平很显而易见，当然你考虑的越全面，产品能力可以说就越强。

我们可以在需求评审前，先和研发提前碰下，避免有大的遗漏。

也可以借助「需求自查表」来辅助，自查出遗漏的说明。

5. 其它

1）文字描述言简意赅， 避免口语化，别使用模棱两可的文字。需求文档里的内容必须明确，别写「尽量」「尽快」。

2）添加示例：被误解是表达者的宿命，文字说明都会有一定的片面理解，对于比较复杂的内容，我们可以添加示例说明：

同时在原型上，尽量使用贴合实际场景的内容。比如说时间别写出：13:88:99。

3）为了便于阅读，可以 采用多分段，多分行，加序号的方式。

4）使用标点符号，将内容说清楚，如：点击「确认」按钮，跳转至【XXX页面】。

关于标点符号，大家可以看这个文章：https://zhuanlan.zhihu.com/p/359255980

5）结合axure的特性，添加文字链接，便于阅读者快速跳转查看，不用自己找。

添加「返回」按钮，比如阅读者跳转到【全局说明页面】，看完后，想在回到来源页继续看需求，我们可以在【全局说明页面】中添加个「返回来源页」按钮，加个返回上一页的交互，直接能返回。

6）对于变量值，使用特殊符号标记下

对于会变化的值，我一般使用用两个百分号，如下方的‘科室名称’，会根据不同的选择展示不同的名称，所以我就通过‘%科室名称%’进行表示，然后单独说明，并举例说明。

7）重要内容进行标记

可以通过加粗、换个颜色等方式进行提醒，当内容较多的时候，大家很容易忽略掉，所以很有必要进行加粗加大标色提醒。

8）涉及到逻辑时，可以使用公式进行说明

如：当A+B≥100时，则XXXX。

9）写完后自己再过一遍

就像上学做题后，自己zai再验算一遍，在写文档的时候，自己肯定会有抽风的时候，不知道哪个地方就给写错了。

10、对外提供时，对于Axure，可以打包出html提供。

如果是word版本，可以提供出pdf版。

以上是对功能需求的说明，对于接口需求、性能需求、埋点需求等非功能性需求，当涉及到的时候，一定要写上，不然就是需求遗漏了。

我之前一直以为产品经理只需要写功能需求就够了。

有一次让我写接口需求，我就很郁闷，这明明是技术的活，干嘛产品写。后来，我明白了一件事，产品经理不往前站，之后就会是一堆坑。

除了接口需求，还是像研发数据库建表时，这些我也建议产品经理去介入，因为表里有哪些字段，字段最大长度是多少，需要建哪些字段等等，都是和业务有关系的。

举个示例，药品的「规格」这个字段，研发把最大长度设置成250个字符，但是在实际业务上，「规格」会有2000个字的情况。

研发绝对是不理解的，所以最清楚这个情况的是产品，就需要提醒研发关注下。避免上线后，字数超长导致保存错误。

对于性能需求怎么写，大家可以看这篇：《5000字详解性能需求》。

对于接口需求、埋点需求等大家可以在平台上搜一下，接口需求可以看：https://www.woshipm.com/pmd/2297401.html

总结

写出好的需求文档受很多方面的影响，从前期的需求分析，当确定业务流程，然后再到画原型，最终把PRD写出来，这里边涉及到的内容非常非常多。

这篇文章是给大家提供的概述，大家可以在日常中总结积累，多和项目成员沟通，每一次需求评审就是一次淬炼，挨个一次怼后就总结，下次别再犯。

另外，当你把一篇完美的需求文档交付后，一定会有研发、测试不看的，只会问，就不看文档。我一般是“微笑服务”，把文档内容截个图发过去。

本文由 @王大鹿原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务

常被混淆的账号体系与账户体系

Sat, 09 Jan 2021 18:59:17 CST

导语：账户体系是任意一款互联网产品都必有的基础体系，而账户体系的产品设计文章却寥寥无几。本文小编将从互联保险产品的账户体系入手，来聊一聊如何基于复杂业务场景构建一套完整账户体系。

账户体系、账号体系、用户体系的区别与联系

在分享如何构建账户体系之前，先聊一聊小编对 「账户」「账号」「用户」三者之间关联和区别的理解。

账户可以定义是一个具有特定信息含义的内容集。比如一张身份证，一本银行存折，一份个人信用资料等。
账号则是一组特定符号组成的序列，且与账户有一一映射关系。比如身份证号，银行卡号，个人征信代码等。
用户则是通过这组特定字符序列与内容集产生关联的个体，同时也是账户内容所描述的特定个体。

在互联网产品中， 用户体系往往是面向用户，更偏重于用户运营与增长。而 账户体系则是面向业务，更偏重于产品结构与业务支撑。 账号体系则是桥接在用户体系与账户体系之间，为用户体系提供价值体现的同时，又可为账户体系提供服务的支持。换言之，在偏重用户体验的产品中，账户体系的价值常常被忽略。而在偏重于业务效率与供需交易的产品中，账户体系的价值举足轻重。

案例：信用卡

这里小编通过「信用卡」这个大家生活中都会接触的产品来讲讲上述三者的区别和关联。

对于一张信用卡来讲，我们站在普通人的角度看，它的用户自然是使用它的人。它的账号自然是登录或支付的账号和密码。而它的账户可能就是它的消费记录，可用金额等。读到这里大家可能觉得这个例子非常的简单。

那么我们换一个思考的角度，站在产品经理的立场看，对于一个信用卡产品来讲，它的用户体系，账号体系，账户体系又分别是什么呢？

在小编看：

信用卡的 用户体系就是它的用户成长体系，可能是用户积分体系，会员等级体系等这些可以提升用户粘性，促进用户刷卡消费，提升业务量的产品运营模块。而这部分模块往往是直接面向用户的，我们可以在各种信用卡产品中轻易找到。
信用卡的 账号体系就是信用卡的使用通道或者说产品触达用户的渠道。可以是线下直接刷卡消费，这时使用的账号就是卡号和支付密码。也可以线上产品端扫码消费，或者第三方支付通道调起，这时必然要通过产品端的登录账号和密码以及付款账号和密码等。这些不同的用途的账号和密码共同组建了一个复杂的账号体系。
账户体系就更加复杂了，包括普通用户可以看到的个人基本信息，个人认证信息，信贷账户，分期账户，分期账户，余额账户，借贷账户，消费记录，贷款记录，还款记录等。以及普通用户看不到的银行信用评级记录，逾期记录，卡片升级记录，异常消费记录等等。由此也可以看出账户体系更多是面向业务的，根据业务不同，账户体系的设计偏重也不同。

那么下面小编将通过互联网保险产品的账户体系 搭建方法论来聊一聊如何设计一个可以应对复杂业务场景的账户体系。

搭建账户体系的第一步：用户是谁，具有什么样的特点？

在互联网保险行业中，由于其业务场景的多元化，可以分为持牌保险企业，保险经纪公司，理赔服务供应商，代理人展业供应商等多种产品形态。小编将通过复杂度适中的互保经纪公司的产品为例来进行分析。

用户关系定位：

首先将保险产品的需求侧用户分为以下四类：

个人用户：进行投保和被保险的个人。
个人客户：存在的被保险的个人。
企业用户：进行投保和被保险的企业。
企业客户：进行被保险的企业。

这里的用户和客户的区别在于： 用户是与产品产生直接行为的个体，而客户是与产品产生间接行为的个体。间接行为就是该个体并未与本产品中产生直接交互行为，而是通过第三方代为完成的。比如企业为员工提供的补充医疗险，就是企业为员工集体购买的险种。当产品本身为被保险人提供保全或理赔服务时，则需要为该被保险人进行账户的创建和维护。客户与用户的具体关联逻辑将在第二步中进行讲解。

案例：个人账户体系

当确定了用户是谁后，在搭建账户体系时就要为用户添加标签，创建账户规则及字段，以及不同类型的账户的下的属性字段有哪些。企业用户因涉及到供给侧，需求侧以及第三方服务角色，相对较为复杂，在此就不展开讨论了。此处小编以个人用户为例简单说明一下。

个人用户的账户信息大概可以分为以上七个信息模块。其中基本信息和身份认证信息这两个模块的用途是确定用户的真实性和唯一性。保险行业相对于其他行业，在进行投保核保时是需要进行个人身份的认证。因而保险产品更容易获取用户的真实信息，用于保险风控及用户运营。

这里可能有读者朋友会问： 为什么将基本信息和身份认证信息归并在个人账户体系中，而不是放在用户体系或者账号体系中。

这里小编解释一下自己的考虑。首先没有归并到用户体系的原因很简单，用户体系的作用是为了促进用户与产品的粘性，进而促进业务增长。而个人基本信息和身份认证信息的归并并不能起到这方面的作用。而在较为复杂或繁琐的产品中，可能会存在多账号的情况，此时如果将基本信息和认证信息放入账号体系中，可能会带来数据不同步或数据冗余的问题。

保险信息和所属企业的用途是确定个人是用户还是客户以及该个人与保单之间的关联关系。因为一个人可以关联多张保单。

如该个人在某一保单中是连带被保险人，那么该人对于该保单/该保险产品而言就是客户，因为Ta无法与产品发生直接交互行为，而是需要主保险人代为进行保全或理赔的行为交互。
如该个人在某一保单中是主被保险人，但该保单的理赔收单方式是以企业为单位收单理赔。那么该个人对于该保单/该保险产品而言仍是客户，因为TA没有与产品发生直接交互行为。
如该个人在某一保单中是主被保险人，且他可以直接在产品中提起保全或理赔的申请，那么该个人对于该保单/该保险产品是用户。

支付信息的用途是在用户与产品产生理赔行为时所需要处理的业务信息模块。这其中较为重要的是额度账户模块，将在第二步重点说明。而登录账号模块作为各种产品的基础支撑模块，将在第三步中重点讨论一下。运营信息模块属于用户体系部分，本文不做扩展。

搭建账户体系的第二步：业务是什么，具有什么样的区别？

如果第一步是确定账户的标准化属性，那么这一步则是确定账户的业务化属性。因为小编讨论的是保险产品的账户体系，那么该账户体系主要围绕的就是险种责任和险种额度。即交易业务的规则和金额。

投保方案中的每条险种责任对应的险种额度都是不同的，被保险人的理赔诉求与险种责任是一一对应的。

在互联网保险中，业务主要可以分为两个思考方向：

提供什么服务？比如投保，保全，理赔。
支持什么险种？比如健康险，财险，车险，寿险等。

这里我们就通过支持 补充医疗险的保全和理赔的团体保单业务为例子来简单分析一下。

补充医疗保险是相对于基本医疗保险而言的，包括企业补充医疗保险、商业医疗保险、社会互助和社区医疗保险等多种形式，是基本医疗保险的有力补充，也是多层次医疗保障体系的重要组成部分。

从业务种类来进行保险账户体系的分析与构建：

保险的业务种类可以直接理解为保险的险种区分及具体理赔或保全规则。因为讨论的是补充医疗保险的保全和理赔业务，所以第一个属性就是账户业务类型，基本医疗保险或补充医疗保险。第二个重要的属性则是保险项目性质，这类企业的补充医疗保险项目会分为风险型和基金型。

所谓风险型保险项目是以一个特定时间段为标准（大多是一年一期），到期续保后重置保险额度，不进行保额累加的操作。而基金型保险项目则可以在到期续保后进行险种额度的累加。因而需要在账户中区分保单性质是基金型还是风险型。

还有一类重要的维度就是保险期间，也就是险种额度有效期。例如去年的理赔申请仅能使用去年的险种额度而不能使用今年的险种额度。当然还有很多其他的规则，比如共享额度，即多个险种共用一个额度。企业公共额度，即在某些特殊病中对个人补充医疗账户的额外的额度补充。

根据上述描述，我可以将额度账户切分为四层结构，即项目层，保单层，责任层，额度层。额度有效期则是从保单层到责任层再到额度层皆有关联。

从业务流程来进行保险账户体系的分析与构建：

保险的业务流程在这里可以理解为理赔流程和保全流程，当被保险人申请理赔服务后，在完成的收单，录单，理算及复核后，会相应的扣除被保险人的对应的险种额度。这其中就会涉及到账户额度的变动。

根据业务流程不同，会延伸出额度加费流程，额度冻结流程，账务清结算流程等。因此在额度层就需要记录该账户的总额度，可用额度，冻结额度，剩余可用额度，初始额度，累计使用额度，累计加费额度。因而就能得到如下图所示的额度账户的结构样例。

搭建账户体系的第三步：账号有哪些，会遇到什么问题？

读到这里，可能会有读者有疑惑，开篇时小编不是将账号体系和账户体系分开来了吗， 为什么账户体系中要考虑账号呢？因为账户体系是一个内容集，我们需要一把钥匙去打开这个内容集，而账号就是触达账户体系的钥匙。但是这把钥匙如何设计也是需要考量的。

有些读者可能在设计账户体系或者初期构建一个C端产品时，会优先搭建账号体系，再根据业务发展逐步的完善账户体系和用户体系。

这种产品设计思路在某些流量为王，偏重用户体验的C端产品中是一种还不错的产品设计思路。但是在一些具有复杂业务场景的行业或产品中可能并不是一个好的设计思路，比如互联网金融，互联网保险或者偏重供需交易业务的互联网+传统行业。为什么这样讲呢？且看小编一一为你解答。

1. 互联网产品的账号类型和适应场景

首先我们先来看看产品账号共有哪些类型，每一种类型的前世今生是怎么样的。

（1）自定义账号类型：

自定义账号起源于PC时代，用户可以根据喜好设定一组字符为账号，没有特定的组合格式。其缺点除了显而易见的因无特定生成规则而不容易记忆外，还无法关联到某一可以认证号主身份的识别信息，丢失后不易直接找回。

（2）邮箱账号类型：

与自定义账号一样起源于PC时代，在自定义账号兴起之后，为了解决其易忘，难维护，难找回的问题。同时使用邮箱也逐步进入中国网民生活中。各大厂开始纷纷使用邮箱作为PC端最常见的登录账号形态。其优点较自定义账号除了降低了维护成本，提高了用户找回账号的便捷性外。也为对流失用户的召回和激活，账号安全性，产品业务推广的提升都起到的至关重要的作用。

（3）手机号码账号类型：

当移动时代的到来后，由于中国大多数网民的手机号普及度远高于邮箱普及度，且国内网民的并未养成如国外网民一样的邮件使用习惯。手机号码作为账号载体受到了绝大多数移动产品的认可。其较邮箱有更高效便民的登录方式，仅需通过验证码即可登录，不需在消耗脑力成本记录密码。尤其当三大运营商对全网手机号实现身份认证后，其对账号安全性的提高是邮箱账号所无法比拟的。现在更有本机手机号一键登录的功能，更极大提高用户体验。

（4）三方授权账号类型：

随着几大国民现象级的APP产品出现，其为抢占各垂直赛道和树立用户心智，衍生出第三方授权登录的概念。仅需要移动产品开启第三方登录接口，用户注册/登录时授权第三方，即可通过第三方账号登录产品。其优点使用户可以跳过较为繁琐的手机号注册登录流程，一键式完成注册/登录，并可将基本信息直接带入产品中。其缺点也十分明显，用户是方便了，但是作为产品本身，无法获得用户真实有效的身份信息。无法对用户进行安全验证，用户召回激活，用户常规运营等行为。

（5）特定账号类型：

最后这一种可能在普通产品中并不常见，但是在某些B端产品或与个人敏感信息相关的产品中颇为常见，比如银行类产品的账号为身份证号，银行卡号。或者社保产品，某些教学平台，OA系统等办公软件。该类账号大多并非主动注册创建的，而是通过被动邀请或主动激活已存在的账号产生。其场景皆是对产品及账号信息的保密性和安全性要求较高。

2. 同一产品的账号合并与账户打通

当我们了解了几种账号类型后，可能遇到过在一个复杂业务产品的账号体系可能包含以上多个甚至全部的类型。这种情况的出现可能是产品的历史遗留问题造成的或者其本身业务形态决定的。而作为产品经理此时要思考的问题是：是否应该合并这些账号数据？这就涉及到了一个非常关键的字段： 用户唯一标识。

用户唯一标识（UID）：用户在产品中完成账号注册后，自动生成一组特定规则字符组，作为用户账号在产品中的唯一识别标识，不可修改，不可重复，不对用户开放。

合并账号数据其实就是在同一个业务体系或系统下，将同一个用户的不同账号进行数据合并。而账号的合并的本质区别就在于： 是否将同一用户的不同账号的UID进行合并，保持用户在系统中的唯一性。

这里需要产品人衡量与思考的点在于： 不合并或合并，对于业务价值的影响是什么？对于用户价值的影响是什么？

（1）多账号合并：

场景：用户A在同一产品的同一业务系统中有两个相互独立的登录账号，类型相同。

分析思路：这种场景较为常见，比如一个人拥有多个微信号码，QQ号，微博号等。大多数社交类产品是不处理这种一人多账号的情况。那么什么业务场景中会对这类同一用户多账号进行处理合并呢，小编在保险产品中就遇到过这类情况。其处理原因是因为互保产品中，用户作为被保险人会进行实名认证，当被实名认证后，如存在多账号的情况，将较难对其进行保全及理赔的服务维护。多账号的情况会造成保单信息不同步或保险数据冗余。换言之， 当在同一产品的同一业务中，同一用户存在多个账号的情况时，如对该业务数据造成较大影响时，需要对账号数据进行合并处理。此时多账号的合并处理又分为两种：

当需要被合并的账号类型相同，如类型都是手机号码时，其常见的处理手段为选择其中一个手机号码为账号名，其他手机号码注销，并将其对应的账户数据合并同步。
当需要被合并的账号类型不同，如类型一个是手机号码，一个是邮箱号码时，其常见的处理手段为选择其中一个类型为账号主体，其他类型保存，可作为展现数据，也可作为副账号。并将其对应的账户数据合并同步。

在工作中，除了同一产品中同一用户的多账号是否合并的问题，我们还可能遇见同一产品同一账号的多账户是否打通的问题。

（2）多账户打通：

场景：用户A在同一产品的不同业务系统中共用一个登录账号，但业务的账户数据是相互独立，不关联同步。

分析思路：

这种场景也较为常见，比如同一个微信可以在王者荣耀的iOS端和Android端各创建一个账户，登录账号通用，但对应的账户数据相互独立。

那么什么业务场景中会对这类同一用户同一账号在多业务系统的账户数据进行打通处理呢？

这种情况在具有供需交易类业务场景的产品中是较为场景的，比如保险产品，或者二手交易类产品，交易代理人产品。普通C端用户即可是需求方也可以是供给方，俗称小B用户。此时是否要将同一用户在买方业务系统的数据与卖方业务系统的数据打通，在于其相互是否有业务交集或连带的价值体现。

所谓 打通账户数据就是将同一个用户同一账号的在不同业务系统的账户数据进行部分关联和同步。在具有复杂业务场景的产品中，我们想清以上可能会遇的问题及对应解决方案后再进行账号体系的设计会更加的清晰和高效。

总结

每一个行业，每一个产品都有自己的产品特点与业务偏重。产品方法论并不能以点概面，以偏概全。小编在本文分享的账户体系搭建的三步方法论仅针对 偏重业务效率或供需交易的多业务场景的产品设计思路。希望通过本篇分享能为有需要的读者朋友在产品设计之路上有所帮助和借鉴。

#专栏作家#

杨三季，微信公众号：杨三季，人人都是产品经理专栏作家。7年互联网经验的高级产品官，深耕内容电商，互联网保险领域，擅长产品增长、数据分析、中台架构等内容。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自pexels，基于CC0协议

盘点Facebook 、YouTube等主流产品的10大创新设计

Wed, 23 Dec 2020 18:47:25 CST

编辑导读：每个设计师都会有创意灵感缺失、大脑一片空白的状态，这个时候去看看最新的一些设计趋势会是一个寻找灵感的好方法。本文作者梳理盘点了国外主流产品的10大创新设计，希望能帮助解决你设计时遇到的灵感枯竭。

国内的产品设计同质化严重，将众多同类产品放在一起，去除图标和主题色的话，很难区分是哪个App。

设计师的视野如果长期只关注国内，那么设计创新能力很容易被束缚，导致创新能力下降。

应对突发需求，国内没有相对应的竞品，就无法做出可落地的方案。

本篇文章盘点下国外主流产品的10大创新设计，通过本篇文章，希望可以打开视野，提升创新能力。

01 左滑进入聊天界面

Instagram在首页界面，用户左滑进入消息聊天页。这是一种全新的交互形式。

国内的产品，左右滑是切换首页的二级导航。

我第一次使用时不习惯，很容易误操作。当习惯之后，就觉得超级方便。它可以快速地切换到聊天消息页。

为什么Instagram要做这个交互？猜测原因有以下2点：

Instagram发力即时通讯，鼓励用户相互发消息。底部已经有了5个tab，没办法继续增tab。这时候只能想办法找其他流量大的入口。
流量最大的入口毫无疑问是首页。所以Instagram在首页新增手势操作，当用户左滑，就能快速地到达消息聊天页。此方案可以完美的满足业务需求。

02 视频小窗口播放

在YouTube视频详情页，没有视频关闭功能。用户不想看视频时，只能点击播放器左上方的收起箭头。

当用户点击之后，会变成卡片小窗口，进行小窗口播放。如下图所示：

这样设计的好处：

可以让用户边找视频，边观看。尽可能地利用用户时间。
使用户消费更多视频，提升用户的观看效率。

03 推荐视频

YouTube在播放过程中，底部会出现四个视频，用户上滑时全部出现。

用户可以在播放过程中，点击推荐视频观看。

这种设计更加强化推荐视频功能。用户可以在播放过程中，选择更感兴趣的视频。

国内视频产品，在全屏的情况下，无法推荐视频，只能在视频结束后推荐视频。国内这样的好处是可以更聚焦当前视频。

04 筛选订阅视频观看

在订阅内容Tab，用户可以根据标签，进行筛选视频，这种操作可以极大的提升用户查找视频的效率。

像继续观看、未观看内容，这些标签，可以高效，不遗漏地观看订阅up主的视频。

05 提升push打开率

当订阅up主后，push推送没有打开时，会出现消息未打开的图标，用户点击，进入设置页面，进行打开通知设置。

这种设计的好处是：推送设置入口固定展示，用户打开push的概率大大增加。

而push打开率的提升，对提升产品的日活帮助巨大。

06 导航和设置展示在一起

Google Chrome 首页，将用户最常访问的网站和功能项放在一起，如下图所示：

一般来说，国内产品很少将两个不同属性的模块放在一起，这样的话容易被误解为一种类型。

但是为了让用户使用更加方便。Google Chrome将其放在一起，都采用宫格导航的形式，通过图标和背板的不同做了一定程度的区分，用户的体验更加友好。

07 下拉操作

Google Chrome下拉时，展示三个选项，左右滑动选择对应的操作。

这种交互方式，即做到了界面简洁，也做到高效方便使用。

08 为其他app引流

Facebook作为一个超级App，所涉及到的业务庞杂，公司内部各个部门利益复杂。为了业务利益，不同部门组织在不断地博弈。

如下图所示，为了尽可能的给其他业务引流，Facebook底部有6个tab，这在主流产品中是不可思议的存在。

为了给messenger引流，首页右上角增加了一个闪电消息图标，会和messenger App联动，当有新消息时，会出现消息提示。点击跳转到messenger。早期facebook 是将底部一个tab给messenger引流，点击tab，直接跳转到messengerApp。

Facebook的这种导流设计，粗暴高效，短期内使得messenger也成为一个超级app。

09 删除中倒计时

Telegram在删除联系人时，底部会出现倒计时提示，在这个期间，用户可以撤回删除操作。

这种交互设计，使得用户在删除过程中更加有安全感，可以回撤毁灭性操作。

10 一次发多条动态

Twitter在发布动态的时候，可以一次性发送多条，这种设计，可以一次性批量的发送，提升用户效率。

以上就是我发现外国主流产品的创新设计。而这些设计，国内基本没人采用，所以分享出来给大家。

如果大家有其他的发现，欢迎在评论区留言。

#专栏作家#

UX，人人都是产品经理专栏作家。前美团点评高级交互设计师。微信公众号：Echo的设计笔记，欢迎关注

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

用户画像规划流程和方法

Thu, 08 Oct 2020 18:11:43 CST

编辑导语：如今在这个大数据时代，“用户画像”这个词经常出现，它跟精准营销挂钩，可以根据一个人的兴趣、地理位置等进行精确的推送，达到良好的营销效果；本文作者分享了关于用户画像规划的流程和方法，我们一起来看一下。

互联网行业飞速的发展，带动行业业务量激增，同时伴随数据量的增加，互联网各行各业慢慢形成头部企业，2/8原则下长尾企业也越来越多；因此，在大数据量和激烈竞争下，如何更好的对产品进行营销，如何制定价格策略，越来越重要。

那么，如何制定准确的营销和价格，就需要我们针对不同人群，不同个体的特点进行精细化推荐，所要本章介绍了如何进行用户画像。

文章结构：

一、什么是用户画像

用户画像就是对用户按照一定的规则进行统计，划分，从而能够指导用户推荐，客户分层运营，达到营销效果。

昨天：手机APP大爆发是随着手机硬件的发展而发展起来的，发展前期大量APP为抢占市场纷纷上线；用户画像只是为了指导产品设计，主要用于产品设计前夕的用户访谈、用户调研的前期工作，而且一般覆盖的人群比较狭隘，精准度差，产品经理设计产品全靠感觉。

今天：行业竞争越来越大，行业产生的数据量也越来越大，各大公司开始建造自己的数据仓库；那么如何应用数据仓库中的数据，如何进行精细化运营，用户画像越来越受到重视。

明天：随着大数据技术的成熟应用，用户画像标签将越来越多，目前互联网行业中比较成功的标签系统是淘宝的千人千面，技术创新必将推动用户画像的精准度。

二、用户画像常用场景

用户画像概况可应用于一下三个场景：

产品设计：开发前期的产品定位设计；
产品营销：指导运营对特定用户进行推送活动信息，推广信息，个性化推荐等。
产品决策：分析用户画像统计对产品的发展现状和发展趋势进行预测，及时调整产品发展路线。

按照用户标签的生产方式可分为：

统计标签：现有的可以直接从数据中提取出来的标签；包括用户自然属性，用户行为统计等信息。

规则标签：自定义规则进行标签建模；根据业务流程提取需要统计的标签。

算法模型标签：根据机器学习等算法进行用户行为预测分类；具有不确定性、开发周期长、成本高，因此系统中此类标签数量较少。

三、用户画像系统搭建流程

1. 数据采集

对用户数据进行采集，数据预处理，数据挖掘和过滤等手段得出期望的数据集。

用户数据一般分为埋点数据和业务数据：

埋点数据：根据用户的行为特征进行埋点，将得到的数据进行处理存储；
业务数据：用户的姓名、年龄、地理位置等自然属性，同时包括用户购买、用户评价、用户评论等隐形数据。

具体采集方法可以使用如下算法模型：

文本挖掘模型（TF-IDF）：处理文本类型，提取数据信息。

TF是词频，IDF是逆向文件频率，TF-IDF是词频和逆向文件频率的乘积。

Nij就是词i在j文章中出现的次数，分母就是文章的总词数。

D就是语料库中文件总数，下面分母就是词i出现的文档数，然后取对数。

该算法可以直接调用python库Sklearn进行实现，但是该算法比较单一，不考虑词条在文章中的位置，不能准确描述词的重要程度，一般需要结合其他其他算法或者增加权重改进。

聚类算法：聚类算法较多，如ANN神经网络和贝叶斯等，聚类主要是针对冷启动用户、用户分群营销等目的；具体算法相对复杂，目前算法应用多使用python的各种库如Sklearn，包括一些框架tensorflow、caffe等。

相似度模型：一般使用相似度模型进行辅助用户分群，常用的有逻辑回归、线性回归、余弦相似度、皮尔森相似度等。

具体说下余弦相似度：

实例：

用户1和用户2通过公式计算相似度为0.945406，是不是可以解释为两个用户可以划分为同一类人，进行用户分群（计算过程只是用于解释算法，无其他意义）。

若已有数据仓库，数据采集相对比较轻松，可参考文章“ 每日优鲜如何搭建数据仓库？”。

2. 用户维度分析

用户分析具有多维度，随时间更新的特点，包括用户年纪、学历、兴趣、消费水平等都容易变化。

因此维度信息应该随着用户偏好发生变化，因此，在标签系统中需要有新增标签功能。

3. 维度标签化

用户画像最终的实现应该是对维度进行标签化，常用MECE法则进行标签化，防止标签界限不清晰。

标签需要根据需要进行逐级拆分，例如：

4. 标签映射，接口封装

用户画像数据导入服务器中，为后续推荐系统，营销活动服务；封装成API可以作为数据服务的内容，对其他系统提供数据支持。

5. 用户画像评估

对画像进行评估：

用户覆盖率：用户画像具体能够覆盖到多少用户，有些用户画像可能覆盖总用户的50%或者80%；所以覆盖率是用户画像应用的一个评价，覆盖率越高，对后续精准营销的策略选择越准确。

准确率：模型的准确性，如上所述，使用算法模型导致的用户分群错误或者对用户的购买意向预测错误，将直接影响购买率，影响GMV。

可拓展：用户画像在维度刻画应该是可扩展的。

及时性：如果用户画像服务到实时推荐系统中还需要用户画像的及时。

四、总结

用户画像结合大数据技术使用户刻画更加细致、及时，对日趋竞争激烈的互联网浪潮起到越来越重要应用。

本文由@汪仔2296 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议

方法+实例！新人也能快速掌握的黄金分割构图法

Tue, 24 Dec 2019 18:58:34 CST

自从做设计以来经常会看到一些很高大上的理论，例如：格式塔法则、网格系统、黄金分割法等等，这些词语给人第一印象就是很高大上，很难学会，也有很多设计师看到这些理论就被吓到，认为自己学不会，也不想学，因为理论知识确实是学起来很枯燥。对于初学者的设计师来说，这些理论可以在短时间不用学太多，但是对已经工作几年的设计师来说，这些设计理论知识也是必不可少的。

只有掌握设计中必要的设计知识，才能让自己的设计眼界、技能得到提升。就我个人而言，我在设计初期也是很反感这些所谓的理论知识，对于我来说简单通俗的教学才是最容易让人接受的，理论太深奥，我真的无法从中体会到真正的奥秘。但是，越到后面，我越喜欢研究那些设计理论知识，因为我越来越懂得那些理论的重要性，对我的设计也有很大的帮助。所以今天我采用通俗易懂的方法，教大家去理解和掌握这些高大上的设计理论知识。

今天主要分享我们经常听到的黄金分割构图法。

黄金分割构图法：是一种由古希腊人发明的几何学公式，遵循这一规则的构图形式被认为是「和谐」的，在欣赏一件形象作品时这一规则的意义在于提供了一条被合理分割的几何线段。

黄金分割构图法的基本理论来自于黄金比例 ── 1 : 1.618。

黄金分割构图法运用到海报设计、画册设计、网页设计、绘画、服装设计、logo 设计、电视电影、建筑等等领域。在摄影中也经常会引入黄金分割比例，可以让照片感觉更自然、舒适，更能吸引观赏者，给人一种赏心悦目的视觉感受。

优秀案例分析

我们先赏析一些运用黄金分割法的优秀案例，通过赏析能让我们体会到它的美和重要性。

1. 在海报中的应用

从上面的 2 张人物海报案例中，可以看出都利用了黄金分割螺旋法的技巧，当整张图作为背景时，我们不知道图片主题位置的掌控时，就可以采用黄金分割法的原则。对于人物，可以根据想要突出的人物某一部位，直接采用这种分割方法快速找到版面位置

下面2张海报是通过图形和文字的结合，主题文字排版的位置也都刚刚好是黄金分割的编排，带给人一种美的、舒适的画面感，图片和文字在版面的比例刚好是 1 : 0.618。

2. 在网页中的应用

上面 2 个网页都采用了黄金分割的原则，大体将版面分为图片区+文案区，比例为 1 : 0.618。上面同时采用了网格重叠的形式，而下面的就是最基本的黄金分割比例。版面的编排整体给人一种呼吸感、有序的、层次分明的视觉感受，并且浏览的顺序也是井井有条，如下图阅读顺序指引：

3. 在绘画上的应用

像我们看熟悉的名画「蒙娜丽莎」、「维纳斯的诞生」等也符合黄金分割的比例。黄金分割比例也在这些作品上经过了历史认证，利用黄金分割布局，让画面更耐看、更精致。

4. 在摄影上的应用

在摄影中也经常会引入黄金分割比例，可以让照片感觉更自然、舒适，更能吸引观赏者，给人一种赏心悦目的视觉感受。使用黄金分割的摄影可以制造出一种空旷、寂静的视觉效果，也可以制造出一种特写镜头的效果。不知道怎么拍照好看，学会这一招你的摄影立马高大上。

5. 在建筑上的应用

在建筑设计中的运用也有很多案例，例如上面的金字塔和泰姬陵的多处布局都能看出黄金分割，第三张中国古建筑也都运用了黄金分割构图。自古以来很多文化建筑都采用了这个构图，让建筑看起来更加美观、耐看、精致。

怎么画螺旋黄金分割图

了解了螺旋黄金分割法的用途和好处，我们最主要的是需要知道怎么来画这个螺旋黄金图。

1. 新建画布

2. 画正方形

这里画正方形是最关键的一步，我们只要知道螺旋黄金图的比例就可以很快的画出来。

螺旋黄金图比例为：13 : 8 : 5 : 3 : 2 : 1

只要知道螺旋黄金图的比例我们就可以开始画正方形了，简单的正方形不用我多说吧。我们按 10 倍的比例来画图，简单的意思就是前面的螺旋黄金图比例都乘 10，变为 130 : 80 : 50 : 30 : 20 : 10，再根据这个数字画出 6 个正方形。

正方形画好后按照这个转圈的顺序排好即可。

3. 画圆弧线

正方形画好后，画圆弧线，可以通过画正圆得到。

圆弧线为正圆的四分之一，圆的半径为每个不同正方形的边长，通过不同大小的正方形画出不同大小的圆弧即可。

开始画圆弧：以大正方形的右下角为圆心画正圆，注意相切位置，画好后删除多余的锚点。

△ 圆心位置

△ 相切位置

△ 删除多余锚点

△ 圆弧画完后

到了这一步基本也就出现我们想要的螺旋黄金图，最后只需要将我们的正方形改成描边的模式即可。

△ 最终图形

这里展示一下第二种方法：

螺旋黄金比1 : 1.618在画面中怎么看？

利用黄金分割法的案例实操

说了这么多，没有实际的操作案例你们是不是也很头痛，到底拿到这个技巧怎么去使用呢？在我这里例举一个横版和一个竖版的案例。

1. 横版

找素材

这里找来几张图片，因为是做分析案例，所以我就选择我自己喜欢的图，我选择的是图1。

图片调整

图片确定后，我们就需要把图放到我们的画布中。

但是问题来了，一般我们的设计尺寸基本是不会和找到的素材是一样大的，我们到底要怎样放大图片呢？图片中哪些元素可以忽略，哪些需要重视？螺旋黄金分割法就可以用上了。

利用我们的螺旋黄金分割图，放在我们的版面中。接下来就放大我们的素材图片，分析图片结构。图片上方都是天空，左边是海和天空，只有右下比较复杂，有人和零碎的石头，所以我们这里图片就以人为画面中的焦点，那么我们的螺旋图就需要改变一下位置。

调整图片大小和位置，将图片中的人物放在螺旋图的焦点位置，这样我们的版面就快速地确定了视觉焦点。

文字排版

将文字排版在画布中，再根据文字竖排的样式，和人阅读的习惯，调整图的方向和文字位置，使人看向主题文字，给人一种指引的方向。

总结：主要利用螺旋黄金分割法调整图片的位置焦点，使画面中心达到舒适耐看和精致的视觉效果。

标记分析图：

这个案例我就不做太多的讲解，因为很简单，直接利用螺旋黄金分割构图的方法，将版面按1 : 0.618的比例划分，然后在这个比例画布中排版文案和图片。

2. 竖版案例

图片位置排版

素材选择上面的图2，这里就做一张竖版的海报。

将素材图放在画布中，准备好我们的螺旋黄金分割图，也放在画布中。根据图片本身的特点，人物只有上半身，所以将图片放在底部最为合适。至于人物应该靠中间还是靠边，我们同可以根据图片人物本身的姿势判断，根据人物是微抬头向上看，角度约 30 度，所以选择将人物靠边。

再就是人物具体位置的掌控，我们同样和上面的案例一样直接利用螺旋黄金分割图做参考位置选择，所以就很快找到合适的位置，如上面右图。

填充背景和文案

我们将背景颜色填充为天空统一的色彩，建立网格，将文案排版在画布中，上面主要是海报中的主要文案及主题文案，文案和图片的总体比例为1 : 0.618，遵循我们的黄金法则。

根据图片的气质，图片中的色彩和人物都属于文艺气质，清新、寂静、雅致的感觉，所以我们这里可以选衬线体宋体，结合韩文来体现整体的气质。

效果展示

最后看看海报效果吧，主要讲解螺旋黄金分割图的使用，所以排版方面讲解的比较简单，以及主题文字都采用最简单粗暴的字体，没有过多的修饰。

总结

文章分享了螺旋黄金分割构图的用途，很广泛，包含海报设计、画册设计、网页设计、绘画、服装设计、logo设计、电视电影、建筑、摄影等等领域，以及分享了黄金分割图形的画法，3 个简单的案例实操，利用黄金分割构图来帮助我们构图和排版，最有利于我们对图片焦点位置的选择和排版分布的掌控。

欢迎关注作者的微信公众号：「设计小余」

如何设计一套完整的会员体系？我的5点思考

Wed, 18 Dec 2019 18:01:44 CST

本文作者从自己的工作经验出发，结合案例分享了自己关于会员体系设计的几点思考，与大家分享。

商场购物、生病买药、加油、甚至楼下买早餐……消费几乎就会被问起是否会员的时代，大多时候我们仅仅看到了会员的表层，而它的里层是一整套会员体系。

会员作为用户运营的终端，实现用户价值变现，其中涉及到商业模式、产品、运营、服务等多方协调合作。有过B2B平台的会员产品、零售门店及电商平台的会员设计或运营经验，分享记录一些思考。

一、会员的价值

提升粘性，增加复购：通过权益、激励、关怀等设置让用户持续使用自己的产品，把用户留在自己的生态圈，刺激重复消费。
分层运营：通过会员将用户分层，实现精细化管理，在用户不同生命周期可通过不同权益体系及激励体系激活用户，从而促进用户成长，延缓流失。
异业合作，流量互换：品牌联动，开放异业合作，形成相互导流。如：京东会员与携程会员打造联名会员卡；购买天猫会员拥有爱康国宾体检卡。
场景营销：通过独特消费场景的构建来绑定用户，抢占用户心智，使用户形成使用习惯，从而增加营销触点。例如：买3C数码产品会首先想到京东，买衣服化妆品会首先想到唯品会。
实现二次增长：如今互联网已成为一个存量市场，如何在存量中找增量是企业的第二突破口。一方面，会员可作为企业从传统产品盈利模式到会员收入为主要盈利模式的转变，依托会员费实现营收，如costco；另一方面，会员作为产品的忠实用户，可通过分润激励促使二次传播等。
增加现金流：企业通过收取会员费增加现金流，促进资金周转。

二、会员权益体系的设置

设计会员的权益需思考一个问题：会员设计的商业逻辑。

明确会员设计的商业逻辑首先要确定使用产品的用户画像，其次要确定以用户为中心的服务场景规划，围绕这个场景和人群去设计权益，促活成本和整体设计的核心。当然，会员的商业价值也是在营销中才能体现。

会员权益的分类主要有：

1）身份权益：会员最直观的特权是身份的不同，对应在产品上会有区分于普通用户的身份标识，不同等级或同一企业不同产品的会员又有不同的标识。如QQ会员会有钻石标志，钻石又分绿钻、黄钻等。

2）价格权益：零售三角中的优惠，即与钱相关，要促使用户在你这里消费，价格是其中一个关键因素。价格权益也不是随随便便设置的，需要考虑到成本和营收，企业的最终目的是为了赚钱，前期可以亏钱，但需要有一个回收点，要算清盈亏平衡点，明确投资回报期，真正实现盈利。当然也有的会员单纯是为了丰富产品内容，增加用户粘性，这里不做讨论。

关于价格的权益有很多种，最直接的从产品上体现的价格优惠：会员价、会员折扣、品类折扣等等，间接的有免运费、优惠券、代金券等等，具体的玩法可结合你的会员产品的商业逻辑以及最终要实现的目标来制定。

3）服务权益：提升用户体验设置的权益，如成为携程会员有机场专车接送、候机有豪华候机室、登机有快速通道等。需根据产品特性来设置，如果是个电商平台，可以考虑从物流、售后等设置；功能型产品可设置功能权益，如迅雷会员下载速度更快；内容型产品有针对内容的权益，如爱奇艺会员可以跳过广告，看更多视频的权益等等，根据具体产品来设置。

4）其他权益：和其他产品进行合作，丰富会员权益的同时实现相互导流的功能。如：京东PLUS赠送爱奇艺会员。

三、会员权益体系的实施

1. 产品端

主要从产品底层逻辑、相关系统、展示页面、交互、操作后台等产品的角度进行设计。

产品底层逻辑是重点，基于运营想要实现的功能和达到的目的，产品经理要设计一整套产品底层扭转逻辑，会牵扯到各个系统，例如：

直接售卖的会员产品和销售系统、收银台、订单管理系统等相关；
实现价格权益可能会涉及到优惠券系统等；
服务权益中的专属客服可能涉及到后台会员与客服的绑定、任务派发工作台；
展示页面和交互设计与用户行为路径、习惯、体验、产品的美观度等等相关；
操作后台又涉及到工作人员的配置、数据监控口径等等。

所以看似是一个会员产品，其实背后涉及了很多产品的运转逻辑，产品与产品之间某个系统的打通至关重要。

能用产品解决的事情就尽量系统化、智能化去解决。

2. 运营端

这里的运营指的是宏观层面的运营，包含除产品能实现的功能以外的产品运转的所有阶段。

产品上线前，运营要负责方案的策划（如果是运营发起的项目由运营输出方案），权益的封装，系统人工跑通（和产品的系统跑通不一样，这里主要是各部门的人员协调等工作），组织各条线的产品经理开各种会，规划产品入口、找广告位，营销方案，异业合作导流，产品配置等等。

产品上线后需要监控数据形成日报，根据数据调整运营策略，销售端的激励机制，售后，用户分层运营等等。

四、会员成长体系

简单的会员体系只有权益体系，也是用户最在意的，成为会员可以享受什么好处，如亚马逊和costco，简单粗暴，优势明显。

会员运营也是用户运营，所以针对会员也有会员的分层，在会员的各个生命周期设置不同等级来体现会员的不同价值，延长生命，形成成长体系。

成长值+特殊权益。成长值作为会员等级的划分，可根据用户的行为价值进行赋值。

例如电商平台可以根据提交订单、贡献gmv、购买频率等等行为数据的大小来分层；内容平台可根据打开次数、点击次数、浏览时间等等行为数据来分层；每个动作赋予相应的成长值，有成长值的增加对应也会有成长值的减少（如违返平台规则、删除操作等），根据成长值的不同来规范会员行为，区分会员等级，不同等级的会员又享有不同权益，激励会员不断成长。

五、会员激励体系

如果成长值根据会员行为赋值，那么积分、勋章、大V标识等可作为成长值的展示方式，突出等级制，用产品的形式体现，给用户荣誉感，满足爽点。

有了不同等级，配合激励方式，比如有3000个粉丝就能开通抖音直播，销量、商品数等满足要求能开通淘宝直播。用等级权益去刺激用户不断使用产品，不断获取更多权益，不断成长，形成良性循环。

作者：可乐；微信：zy810331681，微信公众号：可乐的时光旅，欢迎交流~~

本文由 @可乐原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

复盘：一次曲折的会员成长体系设计

Fri, 27 Sep 2019 14:54:18 CST

存量运营开始逐渐流行，各大公司也开始启动自己的用户运营计划了。笔者最近负责了一个会员成长体系的建设，个中曲折，与大家分享。

互联网进入到新的时期，存量意识越来越被人群所重视。这种意识不仅在互联网行业甚嚣尘上，甚至最近一家传统行业的公司找到我，要做一套会员激励体系来激活自己的客户！

这是一家成立16年的文化传播公司，在公益赛事演出传播等领域具有一定的知名度/美誉度，在目标群体中渗透率超过60%，但是近年来竞争对手越来越多，市场环境恶劣，目前正意欲扩展新业务方向。即使这样地位的一家公司目前也面临增长困难的处境，看来19年不是大家的好运年。

公司负责人给了我之前公司内部设计的但并未通过执行的会员体系，隐去关键信息呈现会员福利部分如下：

复古风的完美展现，官僚风扑面而来：

像不像居委会大妈站你面前叫你填表。

这个会员体系最终没通过，也是可以理解的。这份设计只有团队福利与理事福利两个主要模块，内容官方，并不完善。缺乏消费者等级成长带来的身份荣誉感，会员参与感为零，特权感知仅仅停留在价格和少量礼品上。用户与品牌之间的距离感强烈，不吸引人。

开始我的分析，分析方法不是唯一的，本次是一次基于互联网方法论的传统行业实践。

用户会员体系的三个属性： 目标—激励目标行为—激励方法。

一、首先确定目标

结合生命周期理论来做判断，看目前这家公司所在阶段。

企业处在不同的生命周期阶段，结合当时的天时地利人和，才能制定运营策略。

用户生命周期状态见下图：

各个阶段详情：

引入期（启动阶段）：产品刚上线，默默无闻，拓展种子用户。
成长期（成长阶段）：用户增长模式至少找到一条途径，用户量开始稳步增长。
成熟稳定期（成熟阶段）：用户量积累到一定程度，或者触达行业天花板，用户增长缓慢，开始思考变现并进行尝试。
流失期（衰落阶段）：用户增长停止，开始衰减。

不同时期的核心业务指标：

引入期（启动阶段）：种子用户数量，产品功能迭代提升
成长期（成长阶段）：用户数量，用户规模，留存
成熟稳定期（成熟阶段）：变现尝试，提升付费用户数和客单价
流失期（衰落阶段）：减缓用户流失的出现，存量运营

用户运营的关键群体和激励方向：

引入期（启动阶段）：尝鲜者，激励用户体验目标流程，提出建议，指导产品迭代（案例：乌托邦）
成长期（成长阶段）：跨界者，突出产品自身优势特点，强化优势和特点（案例：画世界/彩视）
成熟稳定期（成熟阶段）：上瘾者，复购老客户，刺激持续使用关键功能，促进消费复购（案例：抖音/知乎/快手）
流失期（衰落阶段）：情怀客户，召回，延缓流失，稳定运营（案例：宝宝树）

结合公司实际情况，该公司处于 成熟稳定期，会员体系的目的是提升产品与用户的强关系，继续刺激上瘾，加强品牌认知归属，提升用户留存率以及复购率。

二、确定要激励的目标行为

梳理用户行为的方法：

1. 梳理用户交互可能，尽量细致

从下载注册登陆修改昵称等开始梳理。一般产品经理处会有交互汇总资料。

2. 研究实际的关键路径以及产品设计的预期路径，进行比较

产品经理与数据分析都需要加入这个过程，基于你自己平台用户的特征去分析。比如根据我以往的产品经历，注册以后当天更改头像设定昵称上传个人资料的用户留存更好，互动更多。

根据这些交互特征，可以尝试去激励引导其他用户以提高留存和互动。如果创作内容是我们的关键路径，那么那些热衷内容创作的用户的行为需要重点关注，并将细节添加到会员成长体系中去。

3. 根据产品阶段和实际情况判断激励行为的优先级

我们做过一个七天登录转运的抽奖活动。注册登陆后七天内未登录的，第七天会有推送提示登录浮窗抽奖。奖品当中有商城优惠券，积分等礼品。将提升留存和增加商城漏出两个目标结合进行。

话说回来，手头这家企业需要激励的目标行为是：复购和口播，品牌深化。（传统行业基本都是如此）

三、确定激励方法

1. 用户画像决定行为方式

不同的用户群体对同一刺激的反应完全不同，确定激励方法首先确定目标群体，定性与定量分析相结合。

基于当下业务情况，以及企业能提供的消费数据，结合网络数据，做一个简单的目标用户画像分析。

现有企业用户画像分析：40岁-75岁，高净值中老年人群。女性占比70%，男性占比30%。具体省份分布以企业提供的消费数据为准。东部沿海省份明显消费能力强。

案例：

简而言之，会员用户是：中高端“大妈”和中高端“大叔”。

2. 我们设计的内容一定要满足人性8大核心驱动力

人性是我们一辈子都要去考虑去琢磨的领域。八大核心驱动力可以作为指南针，帮你在无头绪的情况下迅速定位，制定策略。在此简单介绍下，如有兴趣，这些领域需要深入进去仔细理解。

（1）使命——史诗意义和使命感

指人类认为自己正在做的事情，其意义比事情本身更重要，他必须身体力行竭尽全力去完成目标以宽慰他内心的世界。

（2）成就——成长和成就感

指我们通过使用产品取得进展、学习技能、掌握精通和克服困难的驱动力，挑战尤为重要，没有挑战性而获得的奖杯和勋章毫无意义可言。

（3）授权——创意和及时反馈

能驱使玩家全身心投入到创造性的过程，不断找出新事物，并尝试不同的组合。通过不断体验创造的过程，同时注重创造的结果，并获得及时的反馈。

（4）拥有——所有权和拥有感

能驱使玩家拥有或控制某样东西，因此而受到激励。当一个人对某一样物品有拥有感时，自然会产生想要提升该物品的各项性能，这一驱动力是人类积累财富的主要欲望来源，也是玩家积累虚拟货币的主要驱动力。

（5）社交——社交影响和关联性

是人们所有社交因素的集合体，包括师徒关系、社会认同、社交反馈、伙伴关系、竞争关系。对应马斯洛需求层次理论中的受到尊敬、自我实现。

（6）稀缺——稀缺性和渴望

人们想要某样东西原因仅仅是它太罕见，或者无法立刻获得。包括任务机制、游戏时间限制，玩家无法立刻获得奖励，会激励他们一有机会就回到这款产品。即便王者荣耀限制了小孩子玩游戏的时长，可能这反倒会刺激更加痴迷。

（7）未知——未知性与好奇

人们一直受到吸引，是因为不知道接下来会发生什么，这就是未知性与好奇心驱动力。当某样东西超出你日常的模式识别系统，你的大脑便会立即进入高速运转模式，来关注这突如其来的事物。

（8）亏损——亏损与逃避心

我们都不希望坏的事情发生，就是不希望之前的努力白费，不想承认自己做了无用功，正在消失的机会也是对这一核心驱动力的有效应用。比如：特别优惠、限时抢购。（引自《八角形为分析法》）

外在动机是我们最常用的刺激点，外在动机用得太过会损害内在动机。正向刺激好于负向刺激。

结合产品情况和用户画像，确定要使用的动机。我确定使用的动机是：拥有，稀缺，社交，使命。这里带有一定的主观性，不同的运营团队会有不同的选择。

3. 对用户行为进行量化

分等级以及制作积分表。等级是可进不可退的，积分是可进可退的。

一般的用户成长体系两条线并行，等级代表了资历荣耀以及离开成本。

积分代表了用户在平台的货币，在一些时候实行代币作用，兑换权益等，设计者需要注意设计通货膨胀的抑制措施。因本次会员体系设计内容所限，本段内容不进行扩充。

4. 设计

与对方几次深度沟通后，头秃的得出以下结论：传统行业要求简单粗暴，要求一看就懂，不玩概念。以线下进行承接，因为对用户预期不确定，暂时不考虑线上的承接。

本来预计线上公众号做会员承接，福利权益推送平台，同时可为对方新建立公众号进行引流和客户锁定，但是甲方爸爸无情否定了这个提议。

其实不论线上还是线下会员体系，几个基本点还是上面的内容中所阐述的，区别在于线下会员动作刺激会更简单直接，因为线下的目标简单直接，就是复购和消费。

（1）参考京东，知乎，百果园等品牌的会员体系资料，尝试提炼如下方案：

明确的会员等级
会员权益（拥有)（稀缺）
会员活动（稀缺）（社交）
公益基金池（使命）

中高端大妈和中高端大叔，即便是中高端人群，也带有那个时期走过来的人的共性，

（2）会员体系目前有两种：一是免费版。按照消费或者行为升等级，不同等级对应不同权益。

一是付费版。比如最近大火的costco，权益刺激直接显性的产品适合付费会员。

本次设计为免费会员体系，只要之前在该公司消费过，自动成为公司会员，按照消费次数匹配等级。因为考虑到品牌的公益性，不采取金额形式评定级别，金额作为一个展示来具体呈现。

（3）会员权益：体现专属和稀缺的感受，要体现不同等级之间的区别。综合参考costco的会员体系结合个人思考，设计归类如下：

产品类：新产品新功能优先体验，免费试用，孤品预定，限量抢购
服务类：售后退款优先处理，退货免运费，额外修理服务，上门配送
活动类：会员日，会员价，会员生日福利，节日福利
金额类：折扣券，优惠券，满减券，积分换礼，邀请返现
异业合作：同一用户画像用户的其它需求

（4）在设计的过程中同时考虑到活动体验官和积分兑换两个补充内容。

活动体验官可与该公司新开发的中高端旅游项目的推广相结合，为高端客户提供仪式感参与感，对提升客户的品牌黏度是一种有效途径，方便激活核心客户。

积分兑换绑定客户给客户带来额外惊喜的作用有目共睹，线上产品根据用户行为生成积分再进行反馈，形成正向反馈，基于RFM模型来看，积分策略对于中段用户有很好的提升刺激做用。

积分体系上线后，我们以往产品中的关键指标大幅提升，同时用户会得到相应福利，反馈是双向正面的。

但最终结合这家企业的情况，这两种方式并不适合他们。这家公司更倾向于采用邮寄手册+电话维护的方式进行目前的客户管理，很谨慎，但这也是他们擅长的部分。

会员权益可根据情况进行升级调整，一般来说，如非行业霸主，不可将权益降级只能升级。品牌的搭建需要一点一滴维护，任重道远。

总结

会员体系和会员关系管理是一家企业发展到一定阶段必须要重视的部分。这个体系不是一成不变的，需要根据企业业务情况与时俱进。

文章开头就有提到，对于一般的企业来说，目前是存量的争夺时期。通过强调和优化会员体系提高用户留存是不得不去尝试的方法。

传统行业与互联网行业有区别也有融合：

对待互动性的区别，传统行业更强调单向传输，让用户接受并不真正在意反馈。
平等思维，传统行业把用户当作圈养的群体。
互联网产品可在使用过程中对用户进行教育，传统行业的教育用户的机会非常少，更注重直接缩短买卖过程，极为在意成交。
传统行业更强调客户概念，互联网企业更强调用户概念。客户可以带来直接收益是公司的命脉，用户可以带来流量收益是互联网概念的直接表现。可以看到，目前互联网企业迫于变现压力越来越强调客户与用户概念以及运营手段的区分。

多接触不同行业是有必要的，避免陷入惯性思维。

该行业内暂无竞品可对比参考。如有条件，一定要研究对比竞品的设计理念和细节。知己知彼百战不殆。

本文由 @伙夫安妮原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

详解安防产品之“雪亮工程”

Mon, 04 Nov 2019 10:50:46 CST

本文介绍了与安防产品相关的雪亮工程，以及它的特点、应用场景与发展趋势。

01 什么是“雪亮工程”

2015年6月，中共中央政治局委员、中央政法委书记孟建柱到山东临沂平邑县调研时对“雪亮工程”信息化，整合资源、降低成本，提高治安防控能力的经验做法，给予充分肯定/
2016年10月，全国综治“江西会议”指出，中央已将“雪亮工程”建设纳入“十三五”规划，并作为综治工作当前和今后一个时期的重点工作部署推进。
2018年1月2日，《中共中央国务院关于实施乡村振兴战略的意见》建设平安乡村，推进农村“雪亮工程”建设。

“雪亮工程”是以县、乡、村三级综治中心为指挥平台、以综治信息化为支撑、以网格化管理为基础、以公共安全视频监控联网应用为重点的“群众性治安防控工程”。

一句话概括：“雪亮工程”即建设覆盖到村及院落的视频监控点位的“群众的眼睛是雪亮的”。

“雪亮工程”通过三级综治中心和四级综治信息平台建设，结合群防群治、“一户一档”等工作开展，把治安防范措施延伸到群众身边，发动社会力量和广大群众共同监看视频监控，共同参与治安防范，从而真正实现社会治安防控”全覆盖、无死角”。

02 “雪亮工程”的特点

传统安防工程主要是以视频监控为主，并且需要配备专人进行视频监看。

“雪亮工程”监控平台不仅仅能够实现最基础的视频监控，村民通过有线电视机顶盒即可实时监看小区、社区视频监控图像，并可实现“一键报警”。实现人人可监视，处处可监看，让农村百姓实施监督、参与监督。雪亮能够实现安卓手机和苹果手机智能终端的APP无缝接入，通过手机平台即可实现“可视对讲、语音广播、云台控制、一键报警”等强大功能。

项目具有以下特点

（1）让村民通过村务服务监督平台，了解惠民政策、公开公示和共建工程动态，通过这套系统，村民们打开电视机便能看见村里几个重要路口的实时影像。如果村民发现安全隐患，便可立即通过平台与警务室进行视频通话，直接报警。

（2）将短信推送与“雪亮”工程有机结合，实现了信息化值守，大大节约了人工成本，值得大力推广。

（3）利用有线电视和智能手机推动视频监控入户到人，建成综治主导、社会协同、公众广泛参与的综治项目。

（4）与公安“天网工程”互补的群众性综治“雪亮工程”建设，能进一步提升了立体化治安防控体系实战效能。

03 雪亮工程应用场景

普通用户可使用机顶盒查看所在村、社区、街道附近的相关摄像机的实时视频，可以方便用户对周边相关场所现在情况的了解。如：当用户想要查看自己小孩是否在某个公共区域玩耍，或在学校的情况，都可以通过我们的平台进行查看。

场景一雪亮上电视

用户可以通过手机随时随地的查看自己住所周边的相关视频，从而给用户的出行及所希望了解的其他内容提供及时、方便的信息等。

场景二雪亮上手机

村综治办监控值班室，配备一台电脑和显示屏，可实时显示各路视频监控信号，村综治办接收村民的报警信号，并可向上级报警。

通过监控画面，监控人员能在第一时间全面掌握辖区内的治安状况，为及时出警、准确到达事发地段提供可靠依据。

村中各监控装置的实时视频信号，值班人员可以控制云台，操控每一台监控设备。

当居民发出报警信息时，在大屏幕上展示地图上报警地点和联系电话，并有语音提示。值班员可以通过电话与报警的村民沟通，确定出警方式。

当治安事件发生后，村值班人员可调用辖区监控点实况录像，协助事件的调查。对辖区内的难以处理的异常事件上报上级综治办，请求指导和援助。

场景三雪亮工程村综治办监控值班室

04 “雪亮工程”的商业模式

政府采购模式；EPC总包，包括项目的设计、采购、施工、试运行等全过程的总承包；
BT模式，政府购买服务；总投资+资金占有率（5年，4.9%左右），多数按照5~10年期等额本息的方式每年返还；
PPP模式，政府与社会资本化以合资公司的方式，政府出让特许经营权（SPV），按照出资比例利润分成，一般这种模式10年及以上多一些；

利润点

网络带宽利润；视频类的项目，离不开前端设备的网络接入，运营商有天然优势；
设备利润；设备厂家有天然优势，集成商能否拿到设备的低价；
平台定制化建设利润；例如与现有政府信息化系统的对接或一些具有地方特色的定制化功能开发（人脸识别、大数据预判平台等）；
项目利润；政府有预算支持采购，不采用购买服务模式，这种模式最讨人喜，取决于谁的商务关系硬，但也竞争最为激烈；
工程建设与系统维护利润。

05 未来的发展趋势

过去

平安城市建设以城市为主，以道路、重点区域监控建设为主，且主要注重对警务事件的监控管理，而忽视了农村、社区的安防建设以及非警务事件的处理，往往等事件发生或者矛盾激化才采取措施。

现在

通过雪亮工程，以农村、社区为重点，对重要部位、重要场所、农村薄弱地区进行视频监控建设，响应国家“十三五”治安防控体系建设要求，实现城乡治安防控建设一体化，达到预警、预测、预防的效果，提高群众满意度。

将来

通过平安城市和雪亮工程，城乡音视频监控一体化建设完成纵向贯通省、市、县、乡镇、村、网格，横向联通综治中心、公安指挥中心、政务服务中心、数字化城管中心及各服务部门的公共安全视频系统联网应用，实现城乡大联动。最终实现“全域覆盖、全网共享、全时可用、全程可控”。

作者：博哥，微信公众号：博之大者。4年开发，6年安防、通信行业的产品及管理经验。致力于懂技术、懂管理、爱生活的有为青年，愿与大家一起进步成长！

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unspalsh, 基于CC0协议。

复盘：如何从0-1设计SaaS行业CRM系统

Wed, 02 Oct 2019 11:07:28 CST

笔者复盘了做一个SaaS行业CRM系统的关键节点以及重要事项。

从项目启动到现在差不多大半年的时间，这半年中我经历了CRM系统从0-1的搭建过程。不过与以往接触的CRM系统不同，这次我主要负责的系统是面向SaaS行业。从产品形态上看，SaaS行业属于B2B行业大类，但也有着其独有的特征。

这篇文章我希望通过讲故事的方式分享我在V1.0版本时遇到的业务问题以及解决方案，大家如果有不一样的见解，也欢迎大家在评论区进行问题探讨。

一、产品V0.1版本的建立

在刚到公司之前，公司主要以某细分领域的定制化项目作为主要的盈利方式。在这之后公司希望结合自身领域上的优势将自己的产品SaaS化，这其中一方面是出于对产品通用性角度考虑：在这个细分领域中各企业的业务流程有着较多的相似之处，实现产品通用化是可行的；当然更重要的是从商业角度考虑，这样能够降低产品的开发与维护成本；同时通过按需订阅的方式能够争取更多中小“长尾组织”的有限预算。

我在来到公司负责的第一个项目就是将系统架构进行SaaS化改造：首先按照战略思路将产品功能划分为基础服务级、应用模块级，同时支持高可配置化的菜单及功能来满足多租户不同的业务需求，之后将系统权限改造为多租户权限模式，将应用模块与租户ID做灵活关联从而实现按需购买服务。

有关SaaS产品化改造的话题我先大概说到这，更具体的改造细节我会在后面的文章中为大家介绍。

而在改造的过程中，就逐渐有了CRM系统雏形：系统权限在划分为多租户后，需要企业后台系统需要有设置多租户入驻信息及租户开通功能，这也就完成了客户信息的采集与创建，因此我也称之为CRM产品的V0.1版本。

二、SaaS业务的快速扩张促进项目启动

由于是SaaS产品的初步尝试，公司在商业模式上并没有在初期就选择付费，而是希望通过免费的形式获得更高的市场占有率，树立品牌认同；同时持续打磨产品，而后再逐步将产品模块升级，并在原有的基础上做增值服务。

这一打法在市场上确实获得了预期成效：我们在短短一年多的时间内从40w用户量暴涨至240w，租户数也达到将近1w，用户量远远超过入驻即付费的其他平台。

却也随之带来更多业务问题：由于大部分客户是免费入驻与使用产品，产品的运营成本不降反升。因为一方面客户的免费入驻并不能为公司带来收入；与此同时，在售后服务上又需要投入更多的时间和人力成本来培训客户，并要及时解答客户提出的问题。

这时有的同学会问：为什么不通过植入广告的方式来缓解资金压力呢？

我们的是to B的商业软件产品，主要以提升工作与管理效率为目的；
我们所处的行业十分敏感，不宜通过商业广告的形式进行变现。

由于收益增长的压力与成本的提升，导致市场与客户运营部门没有足够的弹药扩充人手，总共不超过12个人的团队在产品上线初期，每天需要应对客户不断打来的电话，同时需要参与开拓市场与售前咨询任务，可谓是身兼多职。

后来，在线上产品慢慢打磨与过渡接近完整后，公司希望能够通过对部分应用采用增值服务的形式实现SaaS产品的业务增长。而争取的客户对象则主要是来自平台在搭建初期积累的这些线索客户，使之成为高意向潜在付费客户并完成付费转化。

这是面临的问题是：如何通过现有的团队来管理与维护如此大体量的客户？这需要引入客户管理系统来解决此问题。

三、项目启动前的研讨：自主研发还是外部采购？

关于系统是通过自研还是外采的问题，我们团队之间讨论过多次。相信很多公司也会有此困惑，如果选择外采，其优势是团队将节省大量的研发及时间成本，但是需要找到与产品业务契合的系统才能有效实施。

最终我们选择了自研系统，原因有以下几点：

产品运营初期，产品战略及商业模式还有待市场考证，需要快速的响应市场快速迭代
市面上的通用CRM系统不能满足当前的业务需求
系统与自身产品的连接较为紧密，需要提供丰富的接口来支持，同时也要相应接口的不断变化

四、明确项目核心问题

在项目启动后，系统待解决的核心问题是：在销售人员较少的情况下，通过系统提升客户营销与管理效率，并最终并实现业务增长。

基于这个核心问题拆解成两个部分，如下图所示：

4.1 业务流程再造

由于是从0到1运营一条新的SaaS产品线，我们需要基于全新的产品形态设计与以往项目型销售不同的业务流程。为此我也做了很多产品调研，从商业模式上分析SaaS产品与原先销售模式的不同。

首先相比于项目型销售，SaaS产品的客单价较低，更多的收入将来自于客户的续费与增购。这就意味着以客户为中心的销售模式将确立主导地位。所谓“以客户为中心的销售模式”的核心就是要参与客户的全生命周期，了解客户在使用过程中产生的各种需求，并及时快速的响应需求。通过这样的销售模式才能真正服务好客户，只有通过这样的方式，才能获得更多的二次收益。

SaaS产品与项目型销售的第二点不同，是更为注重数据驱动而非营销驱动。用户在使用SaaS产品的替换成本会更低，即便客户在销售人员的说服下完成了首单消费，如果产品并不是他们真正需要的，也会直接流失掉。因此SaaS产品需要借助更多的数据挖掘潜在客户而非完全通过线下完成。

基于主流SaaS销售模式调研，并结合公司在组织人员架构与现有业务现状，我对业务流程进行了重新梳理，流程大致如下图所示：

在图中我列出了几个重要的流程节点：

4.1.1 线索获取

考虑前期有限的推广资源以及较低的投资回报率，公司并没有使用付费的市场推广形式。好在产品较好的口碑与高日活量使得在百度搜索的权重较高，加上产品是免费使用，每日的入驻用户仍保有稳定增长。

4.1.2 线索认证

对于线索认证这一阶段的考虑是通过系统目标账户营销（ABM）+人工的方式筛选合格线索（MQL）：

其中系统目标账户营销（ABM）是指通过系统获取用户在浏览付费增值应用时的浏览记录与习惯，通过系统规则标记为潜在客户；
合格线索（MQL）则是根据销售人员以往的经验，手动录入潜在客户信息。

两种潜在客户获取方式分别存成独立的数据表单放入数据库中。

这样做的好处是能够最大程度上起到辅助销售的作用，减少销售人员在客户跟踪与识别上的工作量；在此同时，通过数据还可以挖掘出销售人员在客户识别时的视线盲区，不放过任意一个线索机会。

4.1.3 商机客户转化

严格意义上，线索质量验证与培育应由市场部SDR来完成，而后将合格线索转到销售人员手中做商机客户的转化。但由于产品初期并未配备相关人员，这两个步骤都由同一个销售人员共同完成。

4.1.4 成交客户的续费与增购

前面说到，SaaS产品的大部分收入来自于此步骤，因此在客户完成首单交易后需要做更多的工作，以便实现客户留存并尽可能使之成为高净值推荐客户（NPS）。

在业务实施的开始阶段，我与客户运营部的负责共同制定了详细的相关工作内容及流程：包括客户的回访与跟进频次，产品bug与需求的反馈，客户培训与二次销售流程等等。结合用户需求及业务场景设计产品解决方案，具体解决方案我也会在后面的内容中提到。

4.2 组织架构的优化

在制定了新的业务流程之后，在组织架构层面也会随之调整。客户运营部门明确了岗位角色与分工，一部分人员被拆分到专门负责客户拓展与售前咨询的销售团队；另一部分进入负责售后咨询而增购的客户成功团队。

五、产品路线图规划

在明确了待解决的业务问题后，我们将产品明确定位在“以客户为中心”的核心思路。也就意味着产品功能会在紧张的开发排期中作出取舍。保留现阶段最需要解决的业务问题，同时砍掉与之无关的功能，将视角聚焦在“客户”上。如下图所示：

图中简要列出了一个产品结构示意图，从中可以大致了解产品的全貌。从整体架构上看，我将线索管理与客户成功管理拆分为两个模块，并按照各业务部门职能将权限按照整体模块分配给销售部与客户成功部。当客户处于未达成交易状态时，该条客户会存入线索管理中由销售部跟进，而当客户完成首单后，客户数据将流转至客户成功管理中挖掘二次销售商机。

此外，灰色部分代表暂时舍弃掉的功能，至于舍弃的原因在于客户营销与拓展部门的人数远没有达到通过系统管理的程度，因此暂时不需要开发相应功能。

5.1 线索管理与权限管理

线索管理是销售过程管理中最传统，同时也是最经典的部分；而权限管理是所有后台管理系统的必备工具，基于RBAC的权限设计方法也比较固定和基础，这两部分内容在很多CRM产品相关文章中都有涉及，我就在此不做过多描述。

5.2 客户成功管理

客户成功管理是SaaS领域最重要的部分，一个好的CSM业务体系需要介入客户的完整生命周期中，包括客户的初期促活、中期的客户意见反馈与使用指导。只有服务好客户的每一步，才能最终达成续费或增购的最终业务目的，实现企业收入增长。

在客户流转至客户成功模块后，平台会对客户的使用情况进行数据监控，让客户成功经理实时了解用户的使用情况；并通过系统规则提示哪些客户疑有流失征兆，并设置流失预警，提醒他们及时跟进。

此外，根据特定的业务场景我将商机管理模块放入客户成功模块，使得正式客户表与商机形成1对n的关系，并间接与订单关联；而处于未达成交易状态的潜在客户则直接与订单1对1关联，用户可直接由线上创建订单。这样做的考虑是既能够简化首单流程，又能在客户成功阶段增加对商机过程的管理。为项目后期的客户终身价值（CLV）建模提供较为准确的数据依据。

智能分析模块是CRM产品中非常重要的一部分，但由于初版上线时间紧任务重，以及数据的不完整，因此将放入二期需求；并在一期做好客户信息及销售过程数据的整合与沉淀，搭建数据仓库。

以上是我对V1.0版本CRM产品的设计过程介绍，由于篇幅原因就不再展开对每个功能细节的具体讨论。

六、总结与复盘

回顾整个项目，我认为收获到最多的是对产品全局把控的策略与思路。在产品规划初期，要对现在以及未来的业务发展趋势作出前瞻性预估，从而让系统架构更具扩展性；同时要学会平衡成本与产出，用最小的开发与人力成本完成当前最紧迫的业务问题，在不断地抉择与取舍中验证正确的方向前进。

本文由 @阿猫阿狗原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

电商营销工具之优惠券设计思路分析

Fri, 17 May 2019 16:28:37 CST

本文结合实际经验，与大家分享一下优惠券相关产品的设计思路，一起来看看~

又到了一年618，现在的你是不是已经在各大电商平台开始囤积各种优惠券，什么满减券、折扣券、整点券等，先不管券到底能干嘛，先统统领了再说。于是手机各种定时抢券，等到购物的时候发现，领的券99%都不能用，不是商品不符合就是券已过期。

面对这样的情况，本文结合之前的电商产品活动经验，把优惠券相关产品的设计思路跟大家分享下，希望对各位能有所帮助。

一、明确优惠券活动的目的及意义

优惠券随处可见，基本你知道的行业，都有优惠券的存在，通过发放优惠券，让用户在下单的时候抵扣一定的费用，达到促销的目的。优惠券另一个用处就是合理的提高客单价，从而提高产品的销售利润。

但很多人都不把优惠券当回事，觉得发出去没多少人会使用。但凡抱着这种想法的人，都不是好运营，首先要明白优惠券并不是交易工具，而是一种运营策略。

对活动来说，优惠券是订单转化和拉升客单价的有力工具对品牌来说，优惠券是用户维护乃至用户召回的重要手段。

那么优惠券到底有哪些种类，他们常见的使用场景都是在什么样的呢？

优惠方式：满减券、代金券、折扣券、通用券；
适用范围： 单品券、品类券、店铺券。

总体来说，各个优惠券的具体使用条件及适用范围如下：

目前优惠券玩法里面，因为折扣券的成本核算较为复杂，且无法对用户造成直接的价格冲击，因此用的较少，玩的比较多的是满减券、代金券。

满减券：有一定的使用条件，要满足一定的订单金额才能使用，例如满300-30这种玩法；
代金券：相对条件要简单点，虽然也是满足一定金额才能使用，但额度要求低，常见的就是50-5/100-10这两种形式。

二、优惠券常见的六种发放形式

（1）主动发券

主动发券顾名思义，是商家主动给用户发券。

线上的玩法通常是新人注册礼包、用户福利活动等，承载形式可以是小游戏、品牌宣传等，用户输入账号即可领取，线下一般就是优惠传单。

（2）消费返券

消费返券指的是在用户消费后发券，主要目的是实现二次复购，通常的形式都是满100减X元。

这个玩法也比较多，通常都是直接给纸质优惠券，或者可以邀请用户扫公众号，输入特定关键词领取优惠券链接，也可以是邀请用户参加抽奖活动，设定不同的优惠券档次随机抽取

（3）分享发券

这是目前使用最多的发券玩法，用户在获得红包时需分享后打开领取。最常见的有邀请送红包、外卖红包等，既可以回馈下单用户福利。又可以促活老用户，还可以实现拉新目的。

（4）积分兑券

这是属于用户体系的一部分，通过在积分商城兑换的方式，一方面可以让用户获取福利，同时还能通过消耗积分的方式，让用户为了获取积分再次活跃。

积分的获取来源方式也很多，比如：公众号打卡签到、积分宝任务获取积分等。

（5）任务发券

这是最简单的一种发券方式，用户完成特定任务/活动/游戏后即可获得优惠券。

比如：春节知识问答活动，通过回答春节小问题，根据回答程度领取不同的优惠券

（6）异业发券

这种不属于任何发券玩法，完全是通过异业合作的形式达到目的。

例如：选择与自家目标用户有重叠的平台合作，在该平台发券导流该平台用户到自家平台，实现换量拉新。

以上这些玩法，都可以通过人人秀这种第三方营销平台，将优惠券植入各种营销活动中，例如：抽奖、抽红包、打卡积分兑换、集福等多种营销模式，一方面可以提升粉丝的黏性，同时也可以借助优惠券唤醒部分沉睡用户，实现二次销售转化。

三、优惠券的常见推广渠道

除了做好优惠券本身的活动设置外，最重要的就是如何发放优惠券，很多人以为基于概率论的结果，肯定是发的越多转化越多。

但优惠券绝对不是阳光普照奖，遍地可得的优惠券没人会在意，就像很多新店开业会发优惠传单，可大多数人拿了就扔了，反而是吃饭的时候领的优惠券会一直留着。

这时候就要去探寻优惠券的本质核心，究竟什么样的优惠券是吸引人，什么样的优惠券是会刺激用户用券并付费购物。

首先大家要知道， 优惠券不单单是一种促销工具，更是一种“价格歧视”策略。

举个例子：

物品A成本5元，定价10元时，有100人购买；定价15元时，有60人会购买。

前者利润为500元，后者利润为600元，但我如果使用了5元优惠券去吸引未购买的40人，则利润一共是800元。

从这个例子里就可以看到，对于活动运营来说，优惠券的力度及定价会影响销售转化；对于用户运营而言，优惠券会对不同体系用户进行黏性维护。

因此，优惠券不是一个价格问题，他的本质是心理学问题！所有的优惠券的发放，都是要给到用户一种占便宜的心理和良好的感受，因为用户要的不是占你三块五块的便宜，是享受这种占便宜的优越感。

那么优惠券常见的发放渠道跟发放形式有哪些呢？通常来说有以下几种：

（1）去中心化，社会化传播

优惠卷与其他营销方式的一个很大的区别是，它可以做到脱离电商产品进行独立传播，结合微信购物商城的实际情况，可以将其做成优惠卷链接，在微信用户中传播。

（2）活动娱乐化，游戏化传播

这种形式常见天猫双11、京东618活动中，例如：参加某某游戏，结束后可以随机领取优惠券。

（3）营销精准化，集中投放给价格敏感用户

这种需要有较为完善的客户资源库，已经对客户进行了标签管理，对于那些更看重价格的用户，通过微信定向推送等一系列精准营销的方式，激活唤醒这部分用户。

四、优惠券的八大设计要素

我们会看到，用户之所以愿意使用优惠券，是因为通过使用优惠券，他可以在购物过程中减少实际的资金支付金额，也就是少花钱。

所以我们需要考虑如何让用户了解到全部的信息，也就是用户可以通过什么渠道了解有优惠券可用、如何获取优惠券、购买的商品是否达到用券额度等等，这就需要我们做好各个关键环节的用户体验，让用户的购物过程更加顺畅，同时也要更有利于我们的销售转化。

既然要让用户有一种占便宜的感觉，那就需要对优惠券进行一定的设计，让用户在使用的时候可以抵扣费用。

优惠券的种类虽然五花八门，但核心玩法就两种：

直接抵扣固定金额
在订单价格上打折

这是优惠券的八大要素，其中最核心的是优惠力度。因为优惠力度会直接影响转化，如果力度过大则利润总体变薄，如果力度过小则用户不感兴趣。

所以我们要做的就是找到用户能承担的最高支付价格，但会存在这样的一个问题，东西如果你定价为50元，并没有哪个用户会告诉你，

这个定价低了，我其实能接受75元，这就需要我们分别从不同角度去思考。

另外为了保证业绩，做优惠券发放的时候，一定要考虑到优惠券的时效性和有限性。

时效性：指的是要设置优惠券的使用时间，建议一般为3-5天，如果是通用券可以设置为1个月。
有限性：指限定活动可以优惠的金额，同时限定优惠券的每日发放数量，另外可以针对不同人群进行投放，保证覆盖全整个用户。

五、如何利用优惠券实现业绩突破

为了冲业绩，在不亏本的前提下优惠力度要尽量大，最大化刺激用户购买下单。

为了提升客单价，需要制定阶段性价格策略，比如现在客单价是50元，则可以制定满70元减20元的优惠券。

为了维护用户粘性，针对已有的会员用户体系，可以对不同等级的用户发放不同优惠券，VIP1享受满20减5元优惠券，VIP2享受满30减10元优惠券，VIP3享受满50减20元优惠券，以此类推。

为了刺激用户留存使用，需要针对潜在流失人群发放优惠券，最常见的就是支付宝红包，支付宝红包的逻辑就是，长时间未使用支付宝的用户红包金额，会大于高活跃用户，这也是防止用户流失的一个手段。

六、如何做好优惠券数据统计分析

当我们设计好优惠券，并完成了一定渠道的投放后，我们需要对优惠券的结果做好数据统计。

一般的数学模型通常是： 渠道推广量>用户领取量>实际使用量

我们看这三个中间的转化就可以分析出来结果，简单来说：

推广量到领取量的转化，代表的是优惠券对用户的吸引力如何，主要侧重渠道的有效性和领取页面的好坏。
领取量到使用量的转化，说明的是优惠券的下单吸引力，主要侧重说明运营的价格策略提醒是否有效。

结语

其实优惠券活动并不简单，它涉及到经济学、心理学等多方面问题，也是运营人需要掌握的重要运营策略，尤其是不同行业的运营，更需要针对自身行业钻研优惠券的玩法。

本文由 @人人秀原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

四大模块，带你了解阿里大数据产品技术架构

Mon, 22 Apr 2019 19:21:53 CST

本文笔者将从数据采集层、数据计算层、数据服务层、数据应用层四大层次来带大家了解阿里大数据的产品技术架构。

2014年，马云提出：“人类正从IT时代走向DT时代”。

如果说在IT时代是以自我控制、自我管理为主，那么到了DT (Data Technology)时代，则是以服务大众、激发生产力为主。以互联网(或者物联网)、云计算、大数据和人工智能为代表的新技术革命正在渗透至各行各业，悄悄地改变着我们的生活。

在DT时代，人们比以往任何时候更能收集到更丰富的数据。

IDC的报告显示：预计到2020年，全球数据总量将超过40ZB (相当于40万亿GB)，这一数据量是2011年的22倍!正在呈“爆炸式”增长的数据，其潜在的巨大价值有待发掘。数据作为一种新的能源，正在发生聚变，变革着我们的生产和生活，催生了当下大数据行业发展热火朝天的盛景。

但是，如果不能对这些数据进行有序，有结构地分类组织和存储。如果不能有效利用并发掘它，继而产生价值，那么它同时也成为一场“灾难”。无序、无结构的数据犹如堆积如山的垃圾，给企业带来的是令人昨舌的高额成本。

在阿里巴巴集团内，我们面临的现实情况是：集团数据存储达到EB级别，部分单张表每天的数据记录数高达几千亿条，在2016年“双”购物狂欢节”的24小时中，支付金额达到了1207 亿元人民币，支付峰值高达12万笔/秒，下单峰值达17.5万笔/秒，媒体直播大屏处理的总数据量高达百亿且所有数据都需要做到实时、准确地对外披露……

这些给数据采集、存储和计算都带来了极大的挑战。

在阿里内部，数据工程师每天要面对百万级规模的离线数据处理工作。阿里大数据井喷式的爆发，加大了数据模型、数据研发、数据质量和运维保障工作的难度。

同时，日益丰富的业态，也带来了各种各样、纷繁复杂的数据需求。如何有效地满足来自员工、商家、合作伙伴等多样化的需求？提高他们对数据使用的满意度，是数据服务和数据产品需要面对的挑战。

如何建设高效的数据模型和体系，使数据易用，避免重复建设和数据不一致性，保证数据的规范性？如何提供高效易用的数据开发工具？如何做好数据质量保障:如何有效管理和控制日益增长的存储和计算消耗？如何保证数据服务的稳定，保证其性能？如何设计有效的数据产品高效赋能于外部客户和内部员…..这些都给大数据系统的建设提出了更多复杂的要求。

本文介绍的阿里巴巴大数据系统架构，就是为了满足不断变化的业务需求，同时实现系统的高度扩展性、灵活性以及数据展现的高性能而设计的。

如图1.1所示是阿里巴巴大数据系统体系架构图，从图中可以清晰地看到数据体系主要分为数据采集、数据计算、数据服务和数据应用四大层次。

一、数据采集层

阿里巴巴是一家多业态的互联网公司，几亿规模的用户（如商家、消费者、商业组织等）在平台上从事商业、消费、娱乐等活动，每时每刻都在产生海量的数据。

数据采集作为阿里大数据系统体系的第一环尤为重要。因此，阿里巴巴建立了一套标准的数据采集体系方案，致力全面、高性能、规范地完成海量数据的采集，并将其传输到大数据平台。

阿里巴巴的日志采集体系方案包括两大体系: Aplus.JS 是Web端日志采集技术方案； UserTrack 是APP端日志采集技术方案。

在采集技术基础之上，阿里巴巴用面向各个场景的埋点规范，来满足通用浏览、点击、特殊交互、APP事件、H5及APP里的HS和Native日志数据打通等多种业务场景。

同时，还建立了一套高性能、高可靠性的数据传输体系，完成数据从生产业务端到大数据系统的传输。在传输方面，采用TimeTunnel (TT)，它既包括数据库的增量数据传输，也包括日志数据的传输。

TT作为数据传输服务的基础架构，既支持实时流式计算，也支持各种时间窗口的批量计算。另外，也通过数据同步工具（DataX和同步中心，其中同步中心是基于DataX易用性封装的）直连异构数据库（备库）来抽取各种时间窗口的数据。

二、数据计算层

数据只有被整合和计算，才能被用于洞察商业规律，挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的。

从采集系统中收集到的大量原始数据，将进人数据计算层中被进一步整合与计算。

面对海量的数据和复杂的计算，阿里巴巴的数据计算层包括两大体系：数据存储及计算云平台（离线计算平台MaxCompute和实时计算平台StreamCompute）和数据整合及管理体系（内部称之为“OneData”）。

其中，MaxCompute 是阿里巴巴自主研发的离线大数据平台，其丰富的功能和强大的存储及计算能力使得阿里巴巴的大数据有了强大的存储和计算引擎: StreamCompute 是阿里巴巴自主研发的流式大数据平台，OneData是数据整合及管理的方法体系及工具。

阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。

借助这一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，并可以帮助相似大数据项目快速落地实现。

从数据计算频率角度来看：阿里数据仓库可以分为离线数据仓库和实时数据仓库。

离线数据仓库主要是指：传统的数据仓库概念，数据计算频率主要以天（包含小时、周和月）为单位——如T-1，则每天凌晨处理上一天的数据。

但是，随着业务的发展特别是交易过程的缩短，用户对数据产出的实时性要求逐渐提高，所以阿里的实时数据仓库应运而生。“双11”实时数据直播大屏，就是实时数据仓库的种典型应用。

阿里数据仓库的数据加工链路也是遵循业界的分层理念，包括：操作数据层（Operational Data Store, ODS）、明细数据层（Data WarehouseDetail, DWD）、汇总数据层（Data Warehouse Summary, DWS）和应用数据层（Application Data Store, ADS）。通过数据仓库不同层次之间的加工过程实现从数据资产向信息资产的转化，并且对整个过程进行有效的元数据管理及数据质量处理。

在阿里大数据系统中，元数据模型整合及应用是一个重要的组成部分，主要包含：数据源元数据、数据仓库元数据、数据链路元数据、工具类元数据、数据质量类元数据等。

元数据应用主要面向数据发现、数据管理等，如用于存储、计算和成本管理等。

三、数据服务层

当数据已被整合和计算好之后，需要提供给产品和应用进行数据消费。

为了有更好的性能和体验，阿里巴巴构建了自己的数据服务层，通过接口服务化方式对外提供数据服务。针对不同的需求，数据服务层的数据源架构在多种数据库之上，如：MySQL和HBase等。后续将逐渐迁移至阿里云2数据库ApsaraDB for RDS（简称”RDS ）和表格仔储（Table Store）等。

开放给集团内部各应用使用：现在，数据服务每天拥有几十亿的数据调用量，如何在性能、稳定性、扩展性等方面更好地服务于用户？如何满足应用各种复杂的数据服务需求？如何保证“双11” 媒体大屏数据服务接口的高可用……

随着业务的发展，需求越来越复杂，因此数据服务也在不断地前进。

数据服务可以使应用对底层数据存储透明，将海量数据方便高效的开放给集团内部各应用使用。现在，数据服务每天拥有几十亿的数据调用量，如何在性能、稳定性、扩展性等方面更好地服务于用户？如何满足应用各种复杂的数据服务需求？如何保证“双11”媒体大屏数据服务接口的高可用……随着业务的发展，需求越来越复杂，因此数据服务也在不断地前进。

数据服务层对外提供数据服务主要是通过统一的数据服务平台 (为方便阅读，简称为“OneService”)。

OneService 以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务，主要提供简单数据查询服务、复杂数据查询服务(承接集团用户识别、用户画像等复杂数据查询服务)和实时数据推送服务三大特色数据服务。

四、数据应用层

数据已经准备好，需要通过合适的应用提供给用户，让数据最大化地发挥价值。

阿里对数据的应用表现在各个方面，如：搜索、推荐、广告、金融、信用、保险、文娱、物流等。商家，阿里内部的搜索、推荐、广告、金融等平台，阿里内部的运营和管理人员等，都是数据应用方:ISV、研究机构和社会组织等也可以利用阿里开放的数据能力和技术。

我们相信：数据作为新能源，为产业注人的变革是显而易见的。我们对数据新能源的探索也不仅仅停留在狭义的技术、服务和应用上。我们正在挖掘大数据更深层次的价值，为社会经济和民生基础建设等提供创新方法。

作者：Wilton（董超华），曾任职科大讯飞，现任富力环球商品贸易港大数据产品经理。公众号名称：改变世界的产品经理。

本文由@华仔原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议。

2张图带你看懂今日头条推荐系统

Thu, 18 Apr 2019 11:57:41 CST

推荐系统是一个策略行为，本文将用两张图，来带你看懂今日头条的推荐系统。

今日头条的推荐系统

通过上“一”张图，我们明白了搜索引擎的原理（无论怎样我都会装作你看懂了），而今日头条的这张图，就是比上图上多了一笔，考虑到这两张图高度相似，我这么懒的人，当然是不会去画的了，你们发挥想象吧。

其实，推荐系统也有离线部分和在线部分。上图（那不是图，是PNG）即是推荐系统的离线部分，与搜索引擎大同小异。

和搜索引擎一样，推荐系统也需要获取内容。推荐系统通过数据库导入、协议同步和用户提交等方式获取推荐内容。区别于搜索引擎，推荐系统获取内容的方式较多，且内容的结构化程度要远胜于搜索引擎爬虫抓取的内容。
推荐系统也需要将待推荐的内容进行索引化处理，这一点与搜索引擎较为相似。推荐系统的维度会更多。

接下来，就是推荐系统的在线部分了。天啊，看到上图，发现推荐系统真的和搜索引擎太像了，就多了一笔。

搜索引擎的输入为用户的搜索关键词，推荐系统同样需要输入，只是这个过程用户没有感知，对推荐系统来说，它的输入为场景信息，比如时间、地点和设备等。
搜索引擎获得输入后，会进行关键词处理，对于推荐系统来说，会进行用户画像查询。这个案例中，推荐系统了解到，该用户在实体词维度，对NBA感兴趣，在分类维度，对体育和科技感兴趣。
查询到用户画像后，推荐系统就进入召回环节。它通过多种方式，根据用户画像查询结果“NBA、体育和科技”，从不同索引数据里获得候选集合。
在召回完成后，和搜索引擎一样，推荐系统按照预定预估目标对候选集进行排序。
同样，推荐系统也需要经过规则干预步骤后，才会将最终结果展示给用户。
对于最后一步，用户的各种动作行为，在搜索引擎里，会持续优化排序模型，在推荐系统里，还会持续改进自身的画像。

对以上两图进行总结就是下图，就是想让你们看的第二张PNG（图)：

我对中台的定义：企业级能力复用平台

Fri, 05 Apr 2019 15:39:54 CST

笔者对中台的定义是“企业级能力复用平台”，本文将针对这九个字进行拆解分析，具体讲述：中台是什么？

《白话中台战略》已经写了三篇，尤其是第一篇「中台是个什么鬼」收到了很多朋友的反馈。写“白话”这个系列主要是想通过写文章来驱动自己思考，并借此和更多人一起交流和探讨中台这个话题。

幸运的是，确实有很多朋友在公众号后台给我留言来表达自己的想法，在此摘出来一个具有代表性的：

“互联网的企业就是爱炒概念。本来很明白的东西，被他们一包装，就变得高深莫测了。我理解中台，就是敏捷响应机制……是一种思维或者理念……企业根据自己的实际情况落实就行。”

我很赞同这位同学的观点，中台本身就是一个比较抽象的概念，很多时候我们被那个“中”字困住了，整天在前与中、中与后的具体差别和评判标准上纠结不已。

但是，就像「看板」不是“我们看到的那个板子”一样，「中台」也不一定就是代表“处于中间平台”，这两个字作为一个整体，代表了一种新的思维和理念。在最新一期的ThoughtWorks技术雷达讨论阶段，中国区的同学就把“ZhongTai”作为一个独立的技术点提交，并没有做意译，就像“Kanban”一样。

那这种新的思维和理念到底是什么呢？“中台”的背后到底意味着什么？有没有价值？价值何在？这也我一直在不断询问自己的问题。

要想搞清楚这些问题，我认为一个关键点就是：是否能够给「中台」这个相对抽象的概念找到一个清晰的定义。因为只有通过定义才能让抽象的概念清晰化，从而明确边界、体现价值。

废话不多说，回到「中台」，如果让我给出一个定义，目前我认为最贴切的应该是： 中台就是「企业级能力复用平台」

很简单，有点失望是不是？但是为了找到一个靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来。但至少到目前为止，只有这个定义是我觉得最贴切、最简单、也最准确的，它能解释几乎所有我碰到的关于中台的问题，例如：

为什么会有那么多中台，像上文提到业务中台、数据中台、搜索中台、移动中台，哪些才是中台，哪些是蹭热点的？
中台与前台的划分原则是什么？
中台化与平台化的区别是什么？
中台化和服务化的区别是什么？
中台该怎么建设？
……

这9个字看起来简单，重要的是其背后对「中台」价值的阐释，下面就让我为大家一一拆解来看。

一、企业级

首先，中台一定是企业级的，这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围，甚至可以是跨企业，例如：现在同样火爆的“生态”的概念。按照徐昊（ThoughtWorks中国区CTO）的说法，更贴切的叫法应该是「多前台产品团队」，这里为了简单我还是用企业级来代表。

当做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景，寻找可复用的能力进行沉淀，从而希望通过能力的复用一方面消除数据孤岛、业务孤岛，一方面支撑企业级规模化创新，助力企业变革，孕育生态。

所以，虽然中台的建设过程虽然可以自下而上，以点及面，但驱动力一定是自上而下的，从全局视角出发的，并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门，例如CIO级别领导或是企业的战略规划部门，因为只有这些横跨多条业务线的角色和组织，才会经常去反思与推动企业级的能力复用问题。

这一点也引出了中台建设的一个关键难点，就是组织架构的调整和演进以及利益的重新分配是技术所不能解决的，也是中台建设的最强阻力，这个我打算在后续的文章里详细阐述。

同时企业级也是区分企业中台化与应用系统服务化的关键点，简而言之中台化是企业级、是全局视角，服务化更多是系统级、是局部视角。

所以，从中台的兴起与爆发可以看到一种趋势——越来越多的企业无论是由于企业运营效率的原因还是由于创新发展的需要，对于企业全局视角跨业务线的能力沉淀都提高到了前所未有的战略高度。

二、能力

提到中台，最常听到的一个词就是「能力」。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。

企业的能力可能包含多个维度，常见的例如：计算能力、技术能力、业务能力、数据能力、AI能力、运营能力、研发能力……其中大部分的能力还可以继续细化和二次展开，从而形成一张多维度的企业能力网。

可以说，中台就是企业所有可以被「多前台产品团队」复用能力的载体。

这里有一个经常碰到的问题，就是：对于某一家企业来讲，你说了有这么多种不同类型的能力，到底哪些能力才是我们企业需要的？哪些是值得中台化的？优先级又怎么划分？

这个问题比较大，也很难有一个统一的答案。

我们现在的做法是尝试通过一系列Workshop，从业务、数据、技术等多个方面切入，通过一系列方法，结合企业愿景，市场定位和数字化现状，跨越多条业务线，试图将企业需要的能力和可复用的能力识别出来，并为落地做好规划和准备。

这些会在后续写到中台如何落地的文章时再详细展开。

三、复用

讲到这儿，相信大家一定有一个疑惑，无论是企业级，多前台产品团队，还是讲能力沉淀，都不是什么新话题。很多企业在组件化、服务化平台化上搞了好多年，那「中台」到底有哪些新的启发？

我的答案就是对于「复用」的关注被提高到了一个前所未有的高度。

虽然我们一直讲「去重复用」讲了很多年，但仔细想想，大多平台化建设会将重点放在「去重」（消除重复）上，而对于「复用」则没有足够的关注。

很多企业都号称已经建成了各种各样成熟的平台，但是我们扪心自问一下，有多少平台是业务驱动的？有多少前台产品团队又是自愿将自己的产品接入到平台上的？有多少平台建设者是在真正关注前台产品团队的平台用户体验？

「去重」讲的更多是向后看，是技术驱动的；「复用」讲的更多是向前看，是业务驱动和用户驱动的。

所以，「去重」与「复用」虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情——目的不同，难度也不同，做到「去重」已然非常困难，关注「复用」的就更是寥寥无几。

所以：

「复用」是中台更加关注的目标；
「可复用性」和「易复用性」是衡量中台建设好坏的重要指标；
「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。

而实现更好的复用，常常从两个方向做改进：

将更高抽象（例如：业务模式级别）的通用业务逻辑通过抽象后下沉到中台，这样前台就会更轻，学习成本和开发维护成本更低，越能更快的适应业务变化；缺点是：抽象级别越高，越难被复用，需要架构师对于各业务有深入的理解和非常强的抽象能力。
就是通过对于中台能力的SaaS化包装，减少前台团队发现中台能力和使用中台能力的阻力，甚至通过自助式（Self-Service）的方式快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。

这里还有一个很有意思的点，相对于「能力复用」其实我们更常用到的词就是「能力共享」，这两个词有些相似。但考虑到「中台」这个概念更加强调对于前台业务的支撑与赋能，除了基本的能力沉淀与共享外，也会更加关注前台的易用性和使用体验，所以我觉得「复用」更能体现出这一点。

四、平台

这里的平台主要是区别于大单体的应用或是系统。

传统的企业数字化规划更多的是围绕业务架构、应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划，例如：要采购或是自建哪些具体的系统（例如ERP、CRM等）。

当然这个过程并没有什么问题，可以理解此时这些独立的系统就承载了企业的各种能力，由于企业各业务线统一使用一个应用或系统，也自然实现了能力的复用。

但问题常常出现在两个方面：

一个是大单体系统的业务响应力有限，缺少「柔性」，当业务发展到一定阶段后，必然产生大量定制化需求，随着内部定制化模块的比例逐渐上升，响应力成指数下降，成为业务的瓶颈点。
另一个则是系统间的打通通常比较困难，容易形成业务孤岛和数据孤岛。

所以，越来越多的企业开始向互联网学习，以平台化的方式重塑企业IT架构，从而给业务提供足够的「柔性」，来满足对于业务的快速响应和复用的需求。

五、总结

「 企业级能力复用平台」这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得如上文所述的这个定义背后所代表的意义是目前对中台价值的最贴切的阐释：

「企业级」定义了中台的范围，区分开了单系统的服务化与微服务；
「能力」定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
「复用」定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；
「平台」定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。

有了定义后，如何建中台的思路也就豁然开朗。

如果说中台是「企业级能力复用平台」的话，那中台化就是「利用平台化手段发现、沉淀与复用企业级能力的过程」，再回头看看这两年做的事情，确实也都在围绕着这些展开。

这就是我对中台的定义，如果你有不同观点或是意见，欢迎留言一起探讨。

PS：至于有同学给我反馈最近“假大空”说的有点多（虽然我誓死不认……），但还是决定接受反馈开始写一些落地实践之类的内容，敬请期待。

作者：ThoughtWorks王健，微信公众号：ThoughtWorks洞见

本文由@ThoughtWorks王健原创发布于人人都是产品经理，未经允许，禁止转载。

题图来自Unsplash, 基于CC0协议

SaaS+PaaS | 产品设计，如何满足用户个性化需求

Mon, 11 Mar 2019 17:05:04 CST

在设计To B产品的时候，因为客户的行业，规模体量，商业模式以及内部管理流程的不同，同样的一个需求在不同的公司可能需要不同的解决方案。所以，在产品的设计上，如何能以灵活的方式在同一个应用体系上满足不同客户的个性化需求，成了To B产品经理的必修课。本文将基于SaaS+PaaS平台的产品设计，重点解决如何让产品满足客户个性化需求的问题。

一、 SaaS产品设计

1. SaaS产品结构

与To C产品通常的管理后台和用户客户端两层产品结构不同。

SaaS产品至少有三层结构，分别是：产品管理后台，租户管理中台和用户客户端。

后台对中台可用的产品功能进行管理，而中台对客户端可用的功能进行管理，从而形成一个最基本的SaaS产品结构。

2. 产品管理后台

产品后台最重要的功能，是针对每个租户所需要的账号多少以及所使用的功能进行控制。

目前SaaS软件常见的收费点有按使用账号收费和按增值功能收费两种，按账号收费的方式是最普遍的形式，按照租户每年使用的账号数来结算。

例如：一个企业有500名员工，那么一个员工使用一个账号；每个账号200元，那么一年的费用就是10万。

另外一种是：按照产品的功能收费，如果产品提供了收费功能，那么可以按年收取增值功能的费用。

根据增值功能的不同可能会有不同的定价模式，例如：网盘可能会根据存储空间的不同来收费，需要给不同的租户设置可用空间等等。

除此之外，产品管理后台还需要对平台通用的一些功能进行管理和设置，例如：平台给租户发送产品站内短消息，或者是上传最新版本的操作手册供租户查看等等。

产品后台对于SaaS产品而言就是总控中心，但设计起来并不复杂，通常都是公司内部的运营人员和销售人员使用。

需要注意的点是：对于租户在使用权限上的控制需要做到灵活处理。

例如：如果租户购买了500个账号一年的使用权，但是因为租户业务增长，所激活的账号超过了500，那么这时候就需要给租户提示，并同时通知客户经理与租户进行新的商务洽谈。

3. 中台权限管理

对于企业产品而言，权限管理系统可以说是整个中台的基础，所有的产品功能都是基于权限系统之上来设计的。

权限管理又分为功能权限与数据权限两种。

功能权限是指：用户在系统中是否有权限使用某些功能。

而数据权限是指：当用户在使用该功能时，可以在哪个数据权限范围内使用。

举个例子来说：如果某SaaS产品提供包含财务和人事两大模块的产品功能，那么能够使用财务模块功能的应该只有财务人员，而能使用人事功能的也只有人事人员。这是对功能权限的控制。

当授予了某个财务人员功能权限之后，还要对他的数据范围作出限制，例如：总公司的财务总管可以查看全公司的财务情况。

而A分公司的财务人员仅能查看A分公司的财务情况，无权查看B分公司或总公司的财务情况，这是对数据范围的控制。

在设计功能权限管理系统时，如果将权限直接授予个人会比较麻烦，而且不利于权限的管理。所以，通常会先将功能权限组合成对应的一个管理角色，然后再将角色授权给对应的个人。这样如果后续对角色授予了新的功能权限，或删减某些功能权限的时候，只需要对角色的功能权限进行设置就可以了，不需要一个一个用户来进行设置。

如果产品的业务形态较为简单，那么可以在设计权限系统的时候，用比较简单的一级菜单控制的方式来进行控制——即只有拥有权限的角色可以看到对应模块的一级菜单，无权限的人则无法看到该模块的一级菜单，这样就可以确保权限管理的正常。

但是，对于业务形态较为复杂的产品，只控制模块的一级菜单可能无法满足。需要对功能模块中更细小的功能进行权限控制，在管理系统中最常见的管理操作有增删改查。对于某些用户可能可以授予全部的权限，而有些用户就只能有查看的权限，没有编辑的权限。

例如：纷享销客CRM系统中的关于角色权限的设置就非常的细致和灵活，租户可以在中台自由的给管理角色授予对应的权限。除了系统提供的角色外，还可以自定义创建管理角色。

4. 中台功能设置

功能层级的设置在To C产品设计过程中，通常都是由产品经理根据调研，或自己的专业经验来定义用户的使用流程，然后以流程图的形式表示出来。

用户在使用产品的时候，就遵循设计好的流程来使用。

但是，对于To B的产品而言，即使是同一个任务，不同的客户也可能有不一样的需求。

从需求的实现难度从低到高来看，分为：共性需求、特定场景需求，以及个性化需求。

先来看看共性需求，这个较好处理——直接排入需求池，然后根据优先级排期进行迭代就可以了。

判断共性需求的原则是：这条需求除了提需求的这个客户之外，是否其他的客户也可以用上，如果答案是肯定的那就是共性需求。

而对于特定场景需求，则有可能是某一行业的客户在特定的业务场景下才需要用到的功能。如果把这类的需求当成共性需求来实现，那么对于那些不需要这个功能的用户来说，系统就会变得越来越臃肿，使用起来越来越复杂。

所以，最好的方式，是在管理后台的功能设置中，将这个功能设置为“只有配置了才可以使用的功能”，然后针对需要的客户开放。

只有通过这种灵活的设置方式，才能确保不同的用户都能基于自己的实际需要使用产品功能。

通过管理后台可以对功能层级的使用进行设置，但是对于功能内部的字段层级使用，不仅在不同的公司之间可能有较大的差异，在公司内部不同的用户之间也有较大的差异。

所以，产品经理在设计用户的流程图的时候，有必要将流程图的流程块拆解到字段层级，并标注：哪些字段是必填项？哪些是可选项？哪些是可配置项？

然后，在租户的管理中台做一个设置功能，由租户的管理员根据需要，将字段的权限配置给不同的角色。

最后是对于客户完全个性化的需求——即只有该用户才会需要的功能。

如果这个功能是用户需要但还未开发的，那么可以根据客户的预算来评估是否可以给用户做定制化的开发。而如果是客户已经通过其他系统实现了的现有产品，则需要在产品内部提供对接，允许外部应用以插件的方式接入到我们的产品中来。如果是native方式实现的外部应用，则需要我们的产品能动态配置跳转协议，允许应用间的跳转。

二、 PaaS产品设计

1. 什么是PaaS

对于企业而言，使用SaaS的好处是显而易见的——那就是可以快速而又简单的使用已有的成熟产品，帮助企业降低成本，增加利润，避免重复造轮子。

但是，SaaS平台有一个弊端，那就是SaaS多数只能满足共性需求。虽然可以通过个性化的二次开发来帮助用户实现需要的功能，但通常来讲都需要较长一段时间的开发周期，客户的需求无法得到及时的满足。

而对于SaaS平台而言，核心的要点还是：服务于大多数的共性客户。给单一客户开发一个个性化的需求性价比是非常低的，除非客户愿意花费一定的预算来投入开发，或客户的重要性很高，否则这类需求的优先级一般会比共性需求要低，导致迟迟无法上线而引起客户的不满。

PaaS平台就是针对这个问题的最佳解决方案，PaaS指的是：给开发人员提供构建应用程序的环境。

通过在PaaS平台上，进行编程创建的应用功能可以快速部署到平台上并且实时生效——简单的来讲，PaaS就是在线编程平台。

相较于常规的编程工具，PaaS平台的好处是：可以基于SaaS产品已有的字段和对象来进行二次开发，快速对接平台已有的功能，在SaaS已有的功能之上进行个性化功能的设计，具有快速，灵活，稳定的特点。

下图是早期的PaaS平台，著名的HR应用PeopleSoft，它能提供字段级别的功能自定义，并且有自己专属的编程语言PeopleSoft code。开发者必须使用专属语言进行二次开发。

目前国内做PaaS平台的公司并不多，知名的有做财务系统的金蝶，CRM领域的纷享销客，以及做HRM的北森云计算。

且不再使用专属语言，而是支持多种主流的编程语言，例如python，php等，极大的降低了开发的门槛，让有经验的开发人员可以快速上手。

另外，为了进一步降低PaaS平台的使用门槛，很多公司正在开发图形化PaaS平台，只需要拖拽和点击就可以完成编程的工作，无需专业的开发人员。而售前工程师或客户方的管理员也可以很方便的进行个性化功能的配置，相信未来PaaS平台在产业互联网的应用中一定会迎来一波高速发展。

对于PaaS产品的设计而言，主要分为三个部分，分别是：创建个性化对象，创建个性化流程以及部署个性化功能。

下面以纷享销客为例，大致的介绍一下：PaaS平台是如何进行个性化功能快速开发上线的。

2. 创建个性化对象

对于开发工程师而言，万物皆对象。

所有的事物都是由一个个的对象构成的，所以在创建个性化需求的时候，首先要创建个性化对象。

CRM管理员可以创建自定义对象，添加任意类型的对象字段，并且可以对对象的管理权限进行设置。通过设置对象的主从关系，可以将自己创建的对象与系统已有的对象或其他自建的对象进行关联，做到了充分的灵活性。

3. 创建个性化流程

创建完自定义的对象之后，用户可以根据业务的需要，创建自定义的业务流程。

业务流程包含：触发条件，传入参数，完成条件，传出参数等多个设置项。

管理员可根据自己业务的需要选择系统自带的对象来进行某些操作，或使用自定义的对象来实现某些功能，在这一步的时候可以使用平台自带的编程工具进行编程。

4. 创建个性化功能

当功能创建好之后，可以将自定义的功能自由的配置在菜单或者是页面上，到这一步，基本就可以满足于用户的任何个性化需求了。

三、产品私有化部署

私有化部署，是指：客户将产品的部署在自己的服务器上，而不是与其他用户一样使用平台提供的云服务。

可能有人会奇怪：如果SaaS+PaaS的模式已经可以满足任意的个性化需求了，那为什么还会有公司要进行私有化部署呢？

原因有两个：

一个是从数据安全方面考虑：有一些公司对于数据的安全性要求非常高，希望所有的数据都能保存在自己的服务器上，所以如果要使用外部的产品，让自己原有的数据和外部产品进行打通，就需要做私有化部署。

另外一个原因是：从性价比方面来考虑，SaaS产品通常按照用户的账号来收费，对于员工人数非常多的企业而言，按这种方式收费会导致成本很高。

例如：一个100万员工的企业，如果按照200块钱一个账号来采购某SaaS产品，一年成本就是2亿。这笔钱与其去买SaaS服务，不如自己组建一个开发团队自研产品了。而如果不想从0开始的话，也会选择将市面上已有的产品进行私有化部署之后，再进行迭代开发。

四、总结

根据行业预估：产业互联网的市场规模在未来数年将持续保持40%左右的增长率，市场前景广阔。

而对于产品经理而言，最重要的核心竞争力是对行业的理解深度，只有深入了解某一个行业的业务流程，了解这个行业的从业人员诉求，才能设计出真正符合客户需要的产品。

参考文章：

《PeopleSoft技术(Application Designer学习，简称AD)》——灵魂_漫步

本文由 @黄瀚星原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

4个步骤，小结搜索系统

Wed, 19 Dec 2018 22:04:37 CST

搜索系统作为用户自行使用的引导工具，重要程度不言而喻；本文主要从4步：需求识别、检索、排序、展现来总结搜索系统的工作机制。

搜索是一个比较有年份的功能，他不是一个简单的搜索框，毕竟搜索造就了一个百度帝国。

搜索系统在产品架构中是帮助用户搜索到他们想要的内容，当用户不知道如何通过其他路径直接获取特定内容的时候才会使用，也就是说搜索是用户自行使用最后的一个引导工具，重要程度不言而喻。

首先对搜索建立一个整体大概的认知，搜索工作机制如上图，主要分为4步：需求识别、检索、排序、展现。

一、需求识别

用户在搜索框中输入的关键词即用户想要查询的内容，首先需要机器去识别出用户想要的是什么，才能把用户想要的东西递给用户，首先介入工作就是分词系统，通过对关键词的整分词匹配或通过语义解析尽可能的了解当前用户的需求。

检索：了解用户想要什么东西了后，就去仓库里面把不同区存在的货物提取出来，准备交付。
排序：为了卖出更多的货物，会对自己的仓库定一系列的规则，如：近期要卖的优先、信誉好的供应商优先等进行排序，保证给到用户我们最好的货物。
展现：知道用户想要什么、也从仓库提取了后，按照排序规则展现给用户就可以了。

接下来落实到具体的产品方案，坚持一个底层原则：从业务中来，到业务中去。

明确本次搜素策略优化目标，围绕目标高举高打：

如：能够准确识别用户query背后对商品的需求，并根据排序规则在页面反馈结果集。

关键衡量指标：

商品需求识别准确率：已识别出的query中真正带有商品需求的query占比，越高越好；
商品需求识别召回率：已识别query中真正带有商品需求数量的query在所有带有商品需求query中占比，越高越好。

检验策略效果计算方式：

正确率 = 提取出的正确信息条数 / 提取出的信息条数
召回率 = 提取出的正确信息条数 / 样本中的信息条数

想要更好的优化方案，可以对现有的搜索关键词和模块数据进行分析，从某交易产品月上万个搜索关键词中，随机抽取了1000条搜索关键词字数分布如下图：

通过对用户输入的关键词进行分析，结论：

用户输入关键词数量：2、3、4占据总字数的80%，所以：我们需要做一个搜索联想提升用户搜索效率。
用户关键词主要分布在：品牌、商品名、品类名、其他特殊字词等，所以：我们要根据各种场景细化出不同的排序方案。
用户有较多次出现搜索为空的情况，引起这种结果有两种可能：① 搜索现有的准确率较低。 ② 现在平台商品SKU 较少。

二、用户搜索输入分析

该部分需要考虑到用户在使用搜索时有什么使用场景，在不同场景下有怎样的行为反应：

三、排序计算方式

排序是整个搜素平台最为关键的一环，此处需要权衡商家、用户、平台的综合利益考虑，如商品搜索可以将特征维度分为：商品维度、卖家维度、平台维度、个性化、反作弊等维度，通过落地到自身业务的当前状态，可得出关键参考点有：

商品名称：商品的全称匹配率。
副标题：副标题与关键词的匹配率。
销量：商品销售数据权重较高。
标签：有标签的商品比没有标签的商品权重更高，标签排名：促销（满减、N元任选）>秒杀>包邮 >其他。
权重参考值排序：商品名称 > 副标题 > 销量 > 标签

四、展现

最后根据用户搜索不同的关键词，使用特定的排序方案，输入机器得出的结果集：

本文由 @World 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

分账平台的基础设计

Tue, 18 Dec 2018 22:07:26 CST

本文主要介绍分帐平台的基础设计：平台如何提供资金清算服务、向支付公司发送资金清算请求、由支付公司替平台商户将资金清算给平台中的商家。

一、实现目标

为平台商户提供资金清算服务，平台商户向支付公司发送资金清算请求，由支付公司替平台商户将资金清算给平台中的商家，从而避免平台商户涉及“二清”风险。

二、基本业务流程

三、商户管理模块

提供子商户批量进件API接口，运营人员在管理后台先开通平台商户权限，平台商户开通后，平台工作人员可以人工在分账系统管理后台录入子商户信息，也可以调用分账系统的子商户批量进件接口，批量录入子商户信息，子商户信息自动与平台信息进行绑定。

1. 分账规则设置

预设分账规则

在平台商户进行子商户进件时，将分账规则提前报备到分账系统，后续做交易时，只需要上送主订单的订单金额、子订单金额和参与分账的子商户号即可。

例如：平台M，与商户A的分账规则是M分10%，与商户B的分账规则是M分20%，与商户C的分账规则是M分30%。若平台M的分账规则是预设的话，那么订单接口只需要送主订单金额和子商户今天即可，系统会依据子订单的金额，计算出平台商户的分账金额。

分账规则接口上送

平台商户不需要提前报备分账规则，提交订单时，只需要接口上送主订单信息和各个分账方的订单金额（包括平台的）。

2. 手续费管理

手续费的承担方式有三种：平台承担、子商户承担和共同承担。手续费的收取规则沿用传统支付行业的收取方式，定额收取、比例收取和阶梯。

若平台商户的手续费承担方式为共同承担，那么手续费的计算可以支持两种模式，预设手续费规则和接口上送。

四、结算管理

结算支持直接清算和平台指令清算。

1. 直接清算模式

平台和商户在进件时，运营人员后台配置结算周期到了结算日期，分账系统直接将资金结算到商户账户中。

2. 平台指令清算模式

分账订单交易成功后，分账平台自动清分完成，在各个参与方的虚拟户增加相应的余额。但是子商户要做提现，需要向平台商户发起提现请求，平台商户向分账平台发起提现指令，方可完成提现动作。

五、风控管理

子订单金额的总额要等于主订单的金额，不匹配的订单拒绝交易；
对平台商户和子商户做交易限额，可配置订单限额和每日限额；
交易请求IP地址设置白名单，非白名单内的IP请求，拒绝处理。

本文由 @懵懂懂原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

优秀的产品经理/糟糕的产品经理

Mon, 19 Nov 2018 18:21:24 CST

每个产品经理都希望自己时优秀的，而不是糟糕的。但如何定义是否优秀却没有一个统一的标准。最近看到了一片文章，中间的一些观点给了我非常大的启发，让自己意识到原来自己做的很多事情，其实是属于糟糕产品经理做的。以下为简单的翻译，分享给大家。

优秀的产品经理：关注团队的快乐指数。当一个团队对产品开发过程感到不满的时候，就无法为客户创造出好的产品，他们也不会喜欢自己的工作，一个好的产品经理除了会收集正式的反馈，同时也会收集一些关于项目、迭代余流程的非正式反馈。目标总是期望不断的提升和改进

糟糕的产品经理：让团队加班加点，把所有东西都安排到紧凑的时间线中，将加速产品的开发。他们自认为时产品的CEO，自认为自己必须是说服他们认真做好自己工作的角色。他们不相信团队的成员能有自己把事情做好的内在动机。

优秀的产品经理：坚持不懈的专注于接触和倾听客户，客户可以很容易的接触到他们，他们还会很主动的余用户交流，不管是短暂的可用性测试或深度访谈，或仅仅了解用户是怎么适用产品的。

糟糕的产品经理：会将所有客户的需求作为产品的开发特性。产品经理接收到的客户需求不应该是开发线路的基础，而是仅仅作为参考。糟糕的产品经理监听所有功能需求，优秀的产品经理通过了解用户潜在的和未知的需求去指定战略。

优秀的产品经理：从整个团队中收集知识和想法，并提炼成有效的产品策略。他们知道，最好的产品洞察力和想法是每个团队成员多种多样的观点的结果。他们知道他们的工作不是拥有最好的想法，而是从团队中提取这些想法，然后推动他们前进。一个好的产品经理也能简洁地传达产品的整体战略，以确保团队的协调一致。

优秀的产品经理：能很好的传达优先级，并确保这些优先级与产品战略和公司总体目标保持一致。他们知道一个团队在合理的时间内可以完成多少工作，他们不会试图通过偷偷加入超出团队能力的事情一个好的产品经理不会孤立地进行优先排序。他们促进与团队的讨论，平衡客户、业务和技术需求，为下一个工作周期提出一套灵活但清晰的优先级设置。

优秀的产品经理：对于执行的细节有很深的了解。他们和团队一起走，帮助他们完成功能规格，设计方向，排除障碍，保持一切正常运行。这有时意味着调整时间表或范围，为产品和客户做正确的事情。

优秀的产品经理：总是在提高他们的能力水平，通过参加会议，学习各种经验，从而为更大的产品管理团体做出贡献。他们意识到自己正在扮演一个不断变化的角色，他们接受自己的流动性。他们不是独自行动，而是寻找志同道合的从业者，他们喜欢创造伟大的产品，并在社区内建立持久的关系。

原文链接： https://medium.com/wildbit/good-bad-product-manager-538d817500f3

The post 优秀的产品经理/糟糕的产品经理 appeared first on 标点符.

No related posts.

Paul Graham 的创业建议

Wed, 01 Aug 2018 18:59:52 CST

描述创业的13句话

选择好合伙人
快速发布
让你的创意进化 (大多数创意来自实现过程)
理解你的用户 (许多成功的创业公司创造了创业者所需的东西)
让一部分用户爱上你比让大部分用户忧喜参半更好
提供出人意料的优质客户服务
You make what you measure (measuring something has an uncanny tendency to improve it)
少花钱
有利可图 (足以支付创始人的生活费)
避免分心 (the worst type are those that pay money like day jobs and consulting)
不要让士气低落
不要放弃
Deals fall through

创业idea

想出创业点子的最好方法就是问自己一个问题: 你希望别人为你做什么？
将注意力放在创意部分而非创业部分，去修复哪些看起来破碎的东西，不管这个问题是否重要到足以创建一家公司。如果你一直按照这样的思路进行推进，最终会为很多人带来价值，当你做到的时候，就自然成为一家公司。
如果您最初生产的产品在其他人看来只是个东西，请不要气馁。事实上，这是一个好兆头。这可能就是为什么其他人一直在忽视这个想法的原因。
没有什么比解决未满足的需求更有价值

如何获得创业ideas

最好的创业思想往往有三个共同点：它们是创始人自己想要的东西，他们自己可以构建的东西，而其他人很少意识到这些东西值得做。
很明显，你应该只针对存在的问题进行研究。然而到目前为止，创业公司最常犯的错误是解决没有人遇到的问题。
您可以构建大多数人想要的少量东西，或者少数人想要的大量东西。选择后者。
如果扎克伯格建立了一些只能吸引哈佛大学学生的东西，那就不是一个好的创业想法。 Facebook是一个好主意，因为它开始于一个小市场，有一条快速的道路。大学是相似的，如果你建立一个在哈佛工作的Facebook，它将在任何大学工作。
当你既是程序员又是目标用户时，它会更好，因为生成新版本并在用户身上测试它们的循环可以在一个头脑中发生。
你很有可能在另一个领域找到好的问题：（a）那个领域的居民不像软件人那样已经用软件解决了他们的问题，而且（b）因为你完全进入无知的新领域，你甚至不知道现状是什么。这是理所当然的。
初创公司被竞争对手杀死的情况极为罕见 – 如此罕见，你几乎可以低估这种可能性。如果你有一些没有竞争对手的东西，并且有一部分用户迫切需要，你就有了滩头阵地。
拥挤的市场实际上是一个好兆头，因为它意味着需求和现有解决方案都不够好。

做那些不能规模化的事

创始人一开始必须做的最常见的不能规模化的事情是手动招募用户。几乎所有创业公司都必须这样做。你不能等待用户来找你。你必须出去获取他们。
我们鼓励每个初创公司按周增长率衡量他们的进度。如果你有100个用户，你需要在下周再获得10个用户，每周增长10％。虽然110看起来似乎并不比100好，但如果你每周保持10％的增长率，你会惊讶地发现这个数字有多大。一年之后，你将有14,000名用户，2年后你将有200万用户。
当您一次获得一千个用户时，您将做不同的事情，并且最终增长速度必须放慢。但如果市场存在，您通常可以从手动招募用户开始，然后逐渐转向非手动方法。
如何找到手动招募的用户？如果你建立一些东西来解决你自己的问题，那么你只需找到你的同伴，这通常是直截了当的。否则，你将不得不更加刻意地找到最有希望的用户。通常的做法是通过进行相对无针对性的发布来获得一些初始用户，然后观察哪种用户看起来最热情，并寻求更多类似用户。
购买Apple产品后，库克不会向您发送手写的便条。他不能。但是你可以。这是小的一个优点：你可以提供大公司无法提供的服务水平。
A consulting-like technique for recruiting initially lukewarm users is to use your software yourselves on their behalf.

Startup = Growth

创业公司的目标就是快速增长，在YC好的增长率为每周5-7%，如果你能保持10%的增长，那么就非常厉害了，如果你只能增长1%，说明你还没搞清楚你在做什么。
衡量增长的最好方式是收入，其次是活跃用户
我们通常建议初创公司选择他们认为可以达到的增长率，然后每周尝试一次。。如果他们决定每周增长7％而且他们达到了这个数字，他们没有什么需要做的。但如果他们没有击中它们，那么它们在唯一重要的事情上就会失败，并且应该相应地发出警告。

导致创业失败的18件事

单个创始人，你需要同事进行头脑风暴，告诉你哪些是愚蠢的决定，并在出现问题时为你加油。
不好的位置，想想你想雇佣的人想住在哪里？
边缘生态，你只能通过回避好的想法来避免竞争
拷贝想法
固执，大多数成功的初创公司最终会做出与原先预期不同的事情。当它到来时你必须准备好看到更好的主意。每周切换到一个新想法将同样致命。
雇佣糟糕的程序员
选择了错误的框架，解决方法是聘请优秀的程序员
发布缓慢，只有通过将您的想法从用户那里反射出来才能完全理解它。
太早发布
没有特定用户的想法，如果不了解用户，就无法构建用户喜欢的东西。
筹集到的钱太少
花费太多，烧钱的经典方式是雇佣很多人。
筹集太多资金，一旦你花了很多钱，改变方向变得更加困难。你拥有的人越多，你就越多地指向同一个方向。
投资者管理不善，你不应该忽视它们，因为它们可能有有用的见解。但你也不应该让他们管理公司。
牺牲用户利益，因为制造人们想要的东西比从中赚钱要困难得多，所以你应该留下商业模式以供日后使用。
不想弄脏你的手，如果你要吸引用户，你可能不得不从电脑上站起来找一些。
创始人之间的争斗，制定好退出机制。
半心半意的努力失败的初创公司的大多数创始人都不会放弃他们的日常工作，而大多数成功创业者的创始人都会这样做。

初创公司要学习的经验教训

尽早发布，快速获得版本1，然后根据用户的反应进行改进。我并不是说你应该发布一些充满bug的东西，但你应该释放一些最小的东西。用户讨厌错误，但他们似乎不介意最小版本1，如果有更多即将推出。
保持功能更新，你应该每天或每两天至少以一些小的方式改善你的系统。用户喜欢一个不断改进的网站。当你根据他们的评论做出改进时，他们会更喜欢你，因为顾客不喜欢忽视他们的公司。
让用户开心最重要的是尽可能简洁地解释您的网站到底是什么。如果你有一些令人印象深刻的东西，试着把它放在头版，因为这是大多数访客会看到的。
害怕正确的事情，更多的创业公司自己软化，而不是被竞争对手压垮。有很多方法可以做到这一点，但三个主要方面是内部纠纷，惯性和忽视用户。
承诺是一种自我实现的预言，创业公司创始人最重要的品质就是决心。不过，你必须是正确的决心。你必须有决心，但要灵活。
总有房间，我们没有看到我们周围的机会的原因是我们适应了事情，并假设事情必须如此。
不要让你的希望升温，可以对你能做什么持乐观态度，但是需要假设最糟的情况。当你听到有人说“我们想要投资你”或“我们想要收购你”时，我希望下面的一句自动出现在你的脑海中：不要抱有希望。
速度，而不是金钱，从经济角度来说，创业公司最好不是一种致富的方式，而是一种快速工作的方式。你必须谋生，创业是一种快速完成任务的方式，而不是让它在你的整个生命中拖延。

如何说服投资者

说服自己，你的创业公司值得投资，然后当你向投资者解释时，他们会相信你。通过说服自己，我并不是说与自己玩心灵游戏来增强自信。我的意思是真的评估你的创业公司是否值得投资。
如果不是，请不要尝试筹集资金。但如果确实如此，当你告诉投资者值得投资时，你会说实话，他们会感觉到这一点。如果你理解了一些事情并且说实话，你就不必是一个流畅的主持人。
要评估您的创业公司是否值得投资，您必须成为领域专家。如果您不是领域专家，那么您可以对自己的想法充满信心，投资者看起来只不过是Dunning-Kruger效应的一个例子。事实上它通常是。
投资者可以通过你回答的问题判断出您是否是领域专家。是否了解市场的一切。
创始人将初创公司视为创意，但投资者将其视为市场。如果有X个客户每年平均支付Y美元，那么您公司的总可寻址市场（TAM）是$XY。投资者不希望你收集所有的钱，但它是你可以获得多大的上限。
您的目标市场必须很大，而且您必须可以抓住它。但市场不一定要大，你也不一定要参与其中。事实上，从一个小市场开始往往会更好，这个小市场要么变成一个大市场，要么从中变成一个大市场。

如何向投资者展示

解释你在做什么，尽快说出你在做什么，最好是在第一句话。
快速进行演示，演示解释了您比任何口头描述更有效的内容。
比模糊的描述更好的描述，您的主要目标不是描述您的系统有朝一日会变成什么样，而只是为了让投资者相信您值得进一步讨论。
不要边说话边操作，让一个人说话而另一个人使用电脑。只要你站在观众附近并观察他们，礼貌（和习惯）就会迫使他们关注你。
不要谈论次要问题，如果您只有几分钟时间，请花时间解释您的产品的功能以及产品效果。
不要过于深入商业模式，这不是聪明的投资者在简短的演示文稿中所关心的，而且你现在的任何商业模式都可能是错误的。
向观众慢慢清晰地讲话，如果你觉得你讲得太慢，那么你的讲话速度是合适的。
让一个人说话，初创公司通常希望表明所有创始人都是平等的合作伙伴。这是一种很好的直觉;投资者不喜欢不平衡的团队。但试图通过划分演示文稿来展示它太过分了。这令人分心。
似乎有信心，我的意思是秀，而不是说。永远不要说“我们充满激情”或“我们的产品很棒。”如果你真的做了一些好事，那么你就可以通过告诉他们这件事给投资者带来帮助。
不要试图看起来比你更多，所有你需要说服他们的是，你是聪明的，你是在做一些好事。如果你太努力隐瞒你的原始状态 – 试图看起来像是公司，或者假装知道你没有的东西 – 你可能只是隐瞒你的才能。他们可能更善于发现废话，而不是制作废话。
不要在幻灯片上放太多字，当幻灯片上有很多单词时，人们只是跳过阅读它。不要阅读你的幻灯片。
具体数字很好，如果您有任何类型的数据，无论多么初步，请告诉观众。数字贴在人们的头上。如果您可以声称中位数访问者生成12个页面浏览量，那就太棒了。但是不要给他们超过四五个数字，只给他们特定的数字。您无需告诉他们您所在市场的规模。
讲述用户的故事，如果您可以谈论特定用户遇到的问题以及如何解决这些问题，那就太好了。关于用户需求的最佳故事是关于您自己的。接下来最好的事情是谈谈你个人认识的人的需求，比如你的朋友或兄弟姐妹。
Make a soundbite stick in their heads，In the startup world, they’re usually “the x of y.”

参考链接： https://medium.com/swlh/graham-for-the-lazy-51a170dacc86

The post Paul Graham 的创业建议 appeared first on 标点符.

APP用户体验量表：SUPR-Qm

Tue, 10 Jul 2018 19:53:21 CST

前面一系列的文章介绍的用户体验量表针对的都是软件和网站，今天要介绍的是针对手机APP的量表SUPR-Qm。SUPR-Qm由 SUPR-Q的作者Jeff Sauro创建，主要目的是面向一定APP做用户调研。

SUPR-Qm的来源

SUPR-Qm来源于最23个其他相关文献中的题目和4个开放性的问题。

23 个相关题目

翻译成中文：

4 个开放性问题

翻译成中文：

具体中间是如何去设计问卷的，可以参考文章后面的参考链接了解更多。

SUPR-Qm 的问卷内容

通过对上面的一些内容的综合分析，得出的SUPR-Qm的最终问卷内容为：

上图中的Logit Position为获得此项高分的难易程度，数值越高代表越难。

翻译成中文：

SUPR-Qm的内部一致性信度达到0.94，与其它体验量表的得分有着显著的相关性：与LTR(推荐度)的相关性为0.74、与 SUPR-Q相关性为0.71、与 UMUX-Lite的相关性为0.74。同样的，SUPR-Qm的分数与Apple Store和Google Store的用户评分之间有0.38的相关性。

SUPR-Qm 的适用场景

在可用性测试中或者网络投放的回忆性测试中评估APP的整体性用户体验，作为之后产品提升或改变的基线对比
在可用性的前后分别进行施测，以便于进行对比分析产品的优化成果
SUPR-Qm可以和其它具有领域特殊性的问题混合在一起使用，以便于测量某些特殊产品(如游戏)的用户体验

另外，在验证SUPR-Qm信效度时，Sauro评估了国外比较常用的一部分APP，有需要的也可以用这些去做对比，如下：

参考链接：

The post APP用户体验量表：SUPR-Qm appeared first on 标点符.

从8个方面告诉你：客服系统应该怎么搞

Mon, 14 May 2018 18:16:07 CST

客服系统到底应该怎么弄？本文从八个方面详细解说，一起进来看看~

客服系统可谓是一款经久不衰的产品，产生时期要追溯至曾经电视购物盛行的前夕，在电商大时代被各种身怀绝技的产品经理再一次的革新与发展。

从最初简单的用户信息记录、工单跟踪，到后期的服务数据量化、沟通质量指标化、智慧应答，一步步在走向全机器智能客服的时代。

将成型的客服系统继续商业化已经成为不少公司的主流业务，比如：网易七鱼、Udesk、AiKF、智齿（虽然听起来像个口腔诊所，但真的是客服系统）。

将服务行业的必要产品商业化，提供打包服务、整体解决方案，以席位为单位进行切割式零售出租模式，也同样应景了企业需要短期内、低成本建立起客服这种刚性功能的需求。

今天我将与大家分享一款我曾经做过的（注意：曾经！曾经！曾经！愿意的话你们可以自己完善）电商在线客服系统，这款系统的角色包括如下：

供应商客服：商家入驻电商平台并自己维护店铺；
呼叫中心客服：集团旗下统一的所有业务客服；
客服部客服：电商平台专属客服。

以上这三个角色我知道你们可能很难理解，各个公司的背景、文化均有不同，所以产品产出形态不拘泥一格，你若能明白，更好；若无法理解，那么你只需要看原型与功能即可，切勿钻角色的牛角尖。

因为这不是我分享这个原型的初衷！同时还请注意：这套客服系统未接入400呼叫业务，是一个IM沟通形式的系统！

有问题评论问我！我会尽量能以你听明白的方式进行解答！

一、客服系统主要模块

操作台：客服人员可在操作台对用户的询问进行文字回复；
信息查询：一个多功能查询页面，方便客服人员快速定位用户或订单；
服务单管理：用户发起的每一次会话都将以服务单的形式进行历史保存；
工单管理：客服系统必备功能，不多解释，但是要说，工单具有追踪、时效、提醒、记录等功能；
客服管理：对客服人员进行数据查询，包括服务客户数、创建功能数、平均响应时间等，量化客服具体工作，数值可用来评判客服效率；
客席监控：监控系统中在线与离线的客服信息，我最初做过一个特别炫的版本，后来………
客服设置：对一些渠道来源、问题类型等字段功能的设置。

二、其他功能

客服功能要与电商后台其他业务打通，如：退货、退款、订单、用户、积分、身份等等。
客服系统可以在原有电商后台框架中直接分模块进行搭建，也可以单起炉灶，这取决于你们公司的业务场景。
客服可查看的信息边界需要不同公司不同考虑，我要分享的这套客服系统在页面中并没有将任何敏感信息加密，但是在权限管理中我设计了按照不同角色进行权限配置的功能。
这套系统分享页面不全，有些敏感页面已经进行了隐藏，但是主流程、客服基本功能全都进行了无保留展示，拿去直接用都不存在问题。

三、客服操作台

客服操作台的首要功能为，与用户产生线上直接沟通之必备工具，一共分为四个模块：

服务信息展示：最左侧显示待接入、正在接入、已接入等信息。在“正在接入”模块中，用三种颜色标示，绿色为当前正在服务的用户信息，白色为正在接入且无未读信息的会话，灰色为正在接入且有未读会话的信息。这方面没有使用未读数字表示，是因为考虑客服在服务的时候，需要一个良好平静的心态，满屏的红色小点+未读数字，不利于客服人员的心态。
沟通信息展示：中间区域使用户与客服人员的沟通记录显示区域，同时会显示一些数据如沟通用时、对话次数（用来判断用户是否即将会爆发）、当前用户等待接入用时（用来判断用户是否具有急躁、愤怒的可能性）。
用户信息展示区：包括客户信息、订单查询、沟通历史、物流查询等相关内容，通过沟通历史，可查看到当前用户的所有会话记录，方便不同客服沟通服务时，能够有据可查。
快捷信息发送区：主要体现为常用语和知识库。

各种逻辑规则不在叙述，如果你是产品，我相信你一定有你自己的规则判断。

四、服务单管理

用户发起的每一次会话都将以服务单的形式进行保存，包括转接路径、可量化指标、服务单类型、关联订单、关联工单的相关内容。

服务单的价值在于会话中全部信息保留，相当于黑盒子的概念，无需通过开发人员调取数据库信息，将所有信息展示于页面即可。

五、工单管理

工单需需要具备几个必要的功能，如创建、修改、指派、跟进、需要与各种业务系统打通（如订单、退货退款）。

另一方面工单要完善到进程或叫做节点，系统清晰的记录着工单的创建，每个环节的工单处理结果，用来回溯事件。

六、客席监控

客席监控功能比较简单，主要是跟踪客服在线状态，实时显示服务质量、服务情况。

七、客服管理

客服管理模块中，主要针对所有客服账号进行服务数据、服务单历史、工单历史等内容的查询功能，用于更好的管理客服团队，输出必要的客服指标。在这个模块中，大家可以加入更多的客服数据KPI。

八、客服设置

客服设置就不以图形进行展示了，主要设置内容包括：会话结束条件、客席分配规则、知识库内容编辑、问候语内容编辑、客服投诉规则等等诸如此类内容。

注：客服系统是非常简单的一套系统，难点并不在于逻辑，而是在于页面功能布局。

比如：操作台，在有限的空间内，要摆放更多的、能够帮助客服了解用户的内容，且页面还需要规整与合理，这才是重点关注地方。

本文由 @王队原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议

网站开发中的字体设置

Fri, 09 Feb 2018 07:59:49 CST

字体的选择，是网页开发的关键因素之一。合适的字体，对网页的美观度（或可读性）有着举足轻重的影响。由于字体设置在代码实现上非常的简单，导致了大多数开发人员都没有重视。在前端、设计分工协助的状态下很容易导致字体设置成为三不管的状态。

衬线体和无衬线体

在西文（英文）字体中，最简单的字体分类方式是将字体分为衬线体（serif）与无衬线体（sans-serif）。其中sans在法语中的意思是“没有”。衬线体与无无衬线体的区分方式非常的简单，只需要判断文字的笔画开始部分或结束部分是否有装饰细节即可，如下图：

在印刷品的正文中，衬线体用的比较多。而在屏幕显示中更多的会采用无衬线体。主要原因是油墨印刷时，将油墨印刷到纸张上时，在没有非常精确的控制好油墨量时，非常容易造成文字变粗或变细，从而导致颜色太深或太淡，在阅读时产生疲惫。如果采用有棱角的衬线字体，可以使得文字笔画的开始或结束更加容易识别到，阅读效率会更高。而在电脑屏幕上，由于不涉及到油墨问题，衬线体在笔划上有过多的点缀很容易造成视觉疲劳。

另外，为了使得标题与正文形成差异，一般在使用与正文相反的字体。如在印刷品中标题采用无衬线体，由于标题要比一般的文字大或者粗，且不会大面积出现，所以采用无衬线体不会影响到阅读。同理，屏幕上的标题也不会大面积出现，采用衬线体也不会带来视觉疲劳。

网页中的字体渲染

在衬线体和非衬线体的介绍中谈到了字体的渲染，而字体的渲染又与各个操作系统有非常大的关联，为了更好的掌握字体在计算机屏幕上的应用，这里再来学习下字体渲染的相关知识。

理想形状与三代渲染策略

理想形状

理想形状，如上图所示，指的是使用矢量图形描述出来的形状。当文字需要在屏幕上显示时，字体形状需要用一定数量的像素栅格来呈现。你可能已经注意到了，理想形状示意图里的字母e并不能和灰色的网格（可以理解为像素点）对应起来，尤其是曲线的边缘，只占了网格的一部分。理想的形状与实际呈现的现状受单位面积内的像素点影响，原理上像素密度越密，呈现效果与理想形状越接近。

黑白渲染

黑白渲染是最早人们使用的渲染技术，这种渲染方式只使用黑白两种颜色来表达文字的形状。这种方法也被称为二值渲染（bi-level rendering）。目前打印机就仍在使用这种方法，由于打印机的高输出分辨率，打印的结果能很好地再现原图。但是在屏幕上，有限的像素（屏幕通常是72dpi，而印刷时通常使用300dpi。即印刷品的像素密度是屏幕的4倍）无法很好地传递字体形状的微妙之处。虽然我们无法分辨单个像素，但是肉眼仍可觉察到弧形轮廓线上的毛刺。即锯齿。这时字体渲染技术还处在初级阶段。

灰度渲染

在上世纪90年代中期，操作系统开始采用非常巧妙的渲染手段。尽管屏幕的分辨率非常低，但是操作系统可以控制每个像素的明暗。这就可以在栅格化图像中存储更多信息。在灰度渲染模式下，处于字形边界上的像素变成灰色。该像素亮度取决于自身被理想字体形状所覆盖的面积比值所决定。这样，字体轮廓看起来就更平滑，字体设计的细节也得以再现。字体在屏幕上看起不仅清晰——而且还能体现字体本身特征及风格。

亚像素渲染

亚像素渲染的重要特征是引入彩色像素。在液晶显示屏中，一个像素是由红绿蓝三个紧密排列的亚像素构成的，它们决定了这一像素的颜色和亮度。因为这些子像素非常小，以至于人眼无法察觉到他们是一个个独立的颜色点。与单纯的灰度渲染相比，水平方向的分辨率翻了三倍。竖笔的位置及粗细就可表现的更为精确，文本外观也就更为清晰。

参考链接： https://www.smashingmagazine.com/2012/04/a-closer-look-at-font-rendering/

点阵字体与轮廓字体

点阵字体（Bitmap Fonts）和轮廓字体（Outline Font）的区别其实和图片格式中的png8和png24的的区别很类似，点阵字体都是实色，没有过渡色，边缘锐利，而轮廓字体有过渡色，边缘也比较平滑。点阵字体类似上面的黑白渲染。我们日常使用的字体大部分为轮廓字体，在Windows操作系统中，宋体会在12px~17px的时候按照点阵方式呈现，但是起本质上还是轮廓字体只不过宋体内置了点阵信息而已。

点阵字体：本质上是点阵图片的集合。渲染极快，显示效果稳定，容易创建，在小字号、多笔画时渲染效果较好。视觉效果较差，不适合缩放。
轮廓字体：是向量图的集合，用 Bézier 曲线描述字形，适合缩放。

常见的轮廓式字体格式可分为：PostScript、TrueType和OpenType。

PostScript由Adobe 开发，用三次 Bézier 曲线描述字形。私有 hinting，价格昂贵。质量高，适合打印专业质量的印刷出版物。又细分为Type1/Type3/CID 等类型。扩展名是.ps
TrueType是Apple 为对抗 Adobe 的 Type1 与 Microsoft 共同开发，用二次 Bézier 曲线描述字形，渲染较快。可内置点阵字体。在 Mac OS X 和 Windows 中是最常见的字体格式。扩展名是.ttf
OpenType源于Microsoft独自开发的TrueType Open，后 Adobe 加入开发，增加对 PostScript 轮廓的支持。是TrueType的升级版，最明显的一个好处就是可以在把PostScript字体嵌入到TrueType的软件中。
- 包含TureType字体的OpenType文件后缀名为.ttf
- 包含PostScript字体的OpenType文件缀名为.otf
- 包含两者的，后缀名为.ttc

总结：轮廓式字体的格式对网页呈现的影响并不是很大，仅做了解即可。

不同操作系统的渲染区别

了解完了三种字体渲染策略，我们来看一下各种操作系统对渲染方式的选择。首先要了解的是苹果与微软针对字体渲染的不同理念：苹果认为，字体渲染应尽可能还原字体的设计，即使代价是造成些许模糊。微软认为，字符的形状应和像素契合，以防止模糊，提高可读性，即便扭曲了字体的构造。技术上说，两者的主要区别是：

Windows 默认是使用很重的 hinting（字体微调），直到 DirectWrite开始才禁用 horizontal hinting（水平微调）；而 Mac OS X 完全不用 hinting 信息，只在 vertical（垂直）方向做一些 autohint（自动调整）
Windows 关闭小字号的 antialiasing（反锯齿），直到 DirectWrite 才启用大字号的 vertical antialiasing（垂直方向反锯齿）；而 Mac OS X 默认要到非常小的字体才会关闭 antialiasing（反锯齿），大部分情况下都是启用的。
Windows 在 DirectWrite 之前没有subpixel positioning（亚像素定位）支持，而 Mac OS X 一直有，当然这个只影响间距。

在Windows系统下，使用什么渲染技术取决于使用什么样的字体以及应用程序的设置。Windows系统有两套图形文字渲染接口，一个是GDI，另一个是Windows Vista之后推出的 DirectWrite，用于取代老的GDI。严格来说，微软自己的亚像素渲染技术有另一个名字—— ClearType，这个技术与两套图形文字渲染接口是被包含的关系。

简单地说：Mac OS X 的字体渲染强调忠实字体设计，最大化保留字体的外形。边缘平滑是为了更好地传递字体设计中的曲线等细节，而小字号时显得模糊也是在此方针下的妥协。而 Windows 的字体渲染强调文字的锐利和清晰。在操作系统介面和网页正文等小字号的地方比较清晰，但大幅牺牲字体的原貌。

要想在Windows上是哟个Mac OS的渲染方式，可安装 MacType软件。

另外在iPhone或者安卓手机上找一个网页打开截屏，图片拿到电脑上不断放大后，你会发现手机上的字体渲染并没有使用亚像素渲染。最优可能的原因是减少CPU的使用。

同样，不同的渲染方式对网页呈现的影响并不是很大，仅做了解即可。

英文字体分类

英文字体的分类方式有很多中，在《写给大家看的设计书》这本书中，将英文字体主要分为了6类：

Oldstyle：倾斜衬线+粗细过渡（对角线强调线），适合阅读。
Modern：水平衬线+剧烈的粗细过渡（垂直强调线），冷酷高雅，不太适合正文。
Slab Serif：Modern的变形版，水平衬线+粗细过渡变小或没有。有较好的可读性，常在儿童书籍中使用。
Sans Serif：无衬线+无粗细变化（无强调线）
Script：书法笔或者书法刷写出来的字
Decorative：装饰性字体。

参考链接：

中文字体分类

同样，中文字体也有非常多的分类方法，这里简单的将中文字体分为如下四类：

对比 Modulated（宋体、仿宋等所谓的中文「衬线体」）
等线 Monolinear（黑体）
书写 Handwritten（楷书、草书等书法字体）
图案 Graphic（偏几何图形的字体）

我们最常使用的是宋体和黑体：

传统型宋体：竖线粗、横线细、书写至结束的地方有一个类似三角形，名为“麟”的装饰
传统型黑体：横线和竖线宽度几乎相同的字体。

网页中的字体设置

在网页中设置时，优先要考虑的是可读性，所以一般正文或长段的文字都采用无衬线字体，另外在标题上基本上会采用与正文有强烈对比的字体（也可以是字号和颜色的高对比度）。另外在网页中进行字体设置时最先需要考虑的是该字体是否在用户的操作系统中存在，如果没有，替代字体是什么？即设置安全字体。

CSS中的字体设置项

与字体有关的 CSS 属性，通常有以下几个：font-family、font-style、font-weight、font-size、line-height、letter-spacing、word-spacing、text-align、text-decoration。

font-family：用于定义字体，通过给定的顺序来选择，更详细的资料请看： font-family
font-style：用于定义字体的样式，包括正常、斜体、倾斜等，对应的属性值为：normal(文本正常显示)、italic(文本斜体显示, 为单独设计的斜体字体)、oblique(文本倾斜显示，由普通字体变形而成)。
font-weight：用于定义文字的粗细，详细的属性值请看： font-weight 数值-样式名对照表如下：
- 100 – Thin
- 200 – Extra Light (Ultra Light)
- 300 – Light
- 400 – Normal
- 500 – Medium
- 600 – Semi Bold (Demi Bold)
- 700 – Bold
- 800 – Extra Bold (Ultra Bold)
- 900 – Black (Heavy)
font-size：设置字体大小。
line-height：用于设置文字中的行间距，合适的行间距对用户阅读带来良好体验。同时还可以用于垂直布局单行文字。
letter-spacing：设置文字之间的字间距，使文字之间的距离增大或者减小。
word-spacing：用于调整单词的间距。
text-align：用来对齐文字，例如左对齐、右对齐、居中对齐等。
text-decoration：用来修饰一段文本，例如添加下划线等。常对 a 标签使用这个属性消除其默认的下划线。
font 属性是设置 font-style, font-variant, font-weight, font-size, line-height 和 font-family属性的简写，详细资料请看： CSS font 属性

操作系统字体区别

操作系统所包含字体不只和系统预装的字体有关，还和系统上安装哪些软件有关，微软操作系统下，详细的系统和一些软件包含的字体可以查看这个索引： Microsoft typography ，Mac系统可以查看这个索引： List of typefaces included with OS X。以下为各操作系统所在的中文字体：

Windows操作系统：

黑体：SimHei
宋体：SimSun
新宋体：NSimSun
仿宋：FangSong
楷体：KaiTi
仿宋GB2312：FangSongGB2312
楷体GB2312：KaiTiGB2312
微软雅黑：Microsoft YaHei （Windows 7开始提供）

如果用户装了MicroSoft Office，还会多出一些字体：

隶书：LiSu
幼圆：YouYuan
华文细黑：STXihei
华文楷体：STKaiti
华文宋体：STSong
华文中宋：STZhongsong
华文仿宋：STFangsong
方正舒体：FZShuTi
方正姚体：FZYaoti
华文彩云：STCaiyun
华文琥珀：STHupo
华文隶书：STLiti
华文行楷：STXingkai
华文新魏：STXinwei

OS X操作系统：

冬青黑体: Hiragino Sans GB （SNOW LEOPARD开始提供）
华文细黑：STHeiti Light （又名STXihei）
华文黑体：STHeiti
华文楷体：STKaiti
华文宋体：STSong
华文仿宋：STFangsong
苹方：PingFang（OS X El Capitan开始提供）

Linux操作系统：（每个发行版都有些差别）

文泉驿点阵宋体
文泉驿正黑
文泉驿微米黑

font-family的设置

在设置font-family是为了保障在页面上能够合适的呈现，通常需要考虑各种操作系统。如下是我整理的font-family。

font-family: system, -apple-system, BlinkMacSystemFont, “Segoe UI”, “Roboto”, “Droid Sans”, “Ubuntu”,”Oxygen”, “Cantarell”, “Helvetica Neue”,Arial, “Hiragino Sans GB”, “PingFang SC”,”Heiti SC”, “Microsoft YaHei UI”, “Microsoft YaHei”, “Source Han Sans”, “Noto Sans CJK SC” , “WenQuanYi Micro Hei”,sans-serif, “Apple Color Emoji”,”Segoe UI Emoji”,”Segoe UI Symbol”;

这个列表非常的长，这里来讲解什么意思：

第一组：映射系统 UI 字体

system ：将来有可能成为标准，-apple- 为过渡阶段的厂商前缀
-apple-system：macOS 和 iOS 平台的 Safari 指向 San Francisco，更老版本的 macOS 指向 Neue Helvetica 和 Lucida Grande
BlinkMacSystemFont：为 macOS Chrome 应用系统 UI 字体，与上面等同

第二组：定义英文字体

“Segoe UI”：面向 Windows 和 Windows Phone
“Roboto”：Android 及较新的 Chrome OS
“Droid Sans”：面向老版本 Android
“Ubuntu”：Ubuntu操作系统
“Oxygen”：KED桌面字体
“Cantarell”：GNOME桌面字体
“Helvetica Neue”：El Capitan 之前的 macOS 系统 UI 字体
Arial：Windows自带字体

第三组：定义中文字体

“Hiragino Sans GB”：冬青黑体（苹果操作系统）
“PingFang SC”：苹方（苹果操作系统）
“Heiti SC”：黑体-简（苹果操作系统）
“Microsoft YaHei UI”：微软雅黑（行间距比普通版小一点）
“Microsoft YaHei”：微软雅黑
“Source Han Sans”：思源黑体（Android系统）
“Noto Sans CJK SC”：思源黑体别名
“WenQuanYi Micro Hei”：文泉驿微米黑（Linux系统）

第四组：字体回退

sans-serif：不是某个字体的名称，而是一种在前面叙述的字体都无效时而最终选用的字体，称为浏览器通用字体，它取决于你所用的浏览器默认的通用字体是什么，可能是“Arial”，也有可能是“Helvetica”。

第五组：定义emoji表情或符号

“Apple Color Emoji”,
“Segoe UI Emoji”,
“Segoe UI Symbol”;

在设置font-family是，需要特别注意的点：

英文字体应该在中文字体之前：绝大部分中文字体里包含英文字母（但是基本上都很丑）
Mac字体要放在Win前面：大部分Mac用户会去安装Windows字体，反之就很少。

CSS3中的@font-face

@font-face是CSS3中的一个模块，他主要是把自己定义的Web字体嵌入到你的网页中著作权归作者所有。在 CSS3 之前，web 设计师必须使用已在用户计算机上安装好的字体。通过 CSS3，web 设计师可以使用他们喜欢的任意字体。

@font-face的语法规则：

@font-face {
    font-family: <YourWebFontName>;
    src: <source> [<format>][,<source> [<format>]]*;
    [font-weight: <weight>];
    [font-style: <style>];
}

取值说明

YourWebFontName:此值指的就是你自定义的字体名称，最好是使用你下载的默认字体，他将被引用到你的Web元素中的font-family。如“font-family:”YourWebFontName”;”
source:此值指的是你自定义的字体的存放路径，可以是相对路径也可以是绝路径；
format：此值指的是你自定义的字体的格式，主要用来帮助浏览器识别，其值主要有以下几种类型：truetype,opentype,truetype-aat,embedded-opentype,avg等；
weight和style:这两个值大家一定很熟悉，weight定义字体是否为粗体，style主要定义字体样式，如斜体。

@font-face法语目前在大部分浏览器上都能支持，但是存在不同的系统和浏览器支持不同的字体类型：

TureTpe(.ttf)格式：.ttf字体是Windows和Mac的最常见的字体，是一种RAW格式，因此他不为网站优化,支持这种字体的浏览器有IE9+,Firefox3.5+,Chrome4+,Safari3+,Opera10+,iOS Mobile Safari4.2+
OpenType(.otf)格式：.otf字体被认为是一种原始的字体格式，其内置在TureType的基础上，所以也提供了更多的功能,支持这种字体的浏览器有5+,Chrome4.0+,Safari3.1+,Opera10.0+,iOS Mobile Safari4.2+
Web Open Font Format(.woff)格式：.woff字体是Web字体中最佳格式，他是一个开放的TrueType/OpenType的压缩版本，同时也支持元数据包的分离,支持这种字体的浏览器有IE9+,Firefox3.5+,Chrome6+,Safari3.6+,Opera11.1+
Web Open Font Format 2.0（.woff2）格式，相比woff最大的优化应该是加强了字体的压缩比。目前支持的浏览器最新的Chrome和Firefox。
Embedded Open Type(.eot)格式：.eot字体是IE专用字体，可以从TrueType创建此格式字体,支持这种字体的浏览器有IE4+
SVG(.svg)格式：.svg字体是基于SVG字体渲染的一种格式,支持这种字体的浏览器有Chrome4+,Safari3.1+,Opera10.0+,iOS Mobile Safari3.2+

字体文件格式转化工具：

根据上面的信息@font-face中我们至少需要.woff、.eot两种格式字体，甚至还需要.svg等字体达到更多种浏览版本的支持。

为了使@font-face达到更多的浏览器支持， Paul Irish写了一个独特的@font-face语法叫 Bulletproof @font-face:

@font-face {
    font-family: 'YourWebFontName';
    src: url('YourWebFontName.eot?') format('eot');/*IE*/
    src:url('YourWebFontName.woff') format('woff'), url('YourWebFontName.ttf') format('truetype');/*non-IE*/
}

为了让各多的浏览器支持，也可以写成：

@font-face {
    font-family: 'YourWebFontName';
    src: url('YourWebFontName.eot'); /* IE9 Compat Modes */
    src: url('YourWebFontName.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
        url('YourWebFontName.woff') format('woff'), /* Modern Browsers */
        url('YourWebFontName.ttf')  format('truetype'), /* Safari, Android, iOS */
        url('YourWebFontName.svg#YourWebFontName') format('svg'); /* Legacy iOS */
}

@font-face的功能虽然很强大，但是在使用的时候还是会存在问题。目前主要遇到的问题是中文字体太大。相较于英文字体只需要字、标点、英文字母，中文有上万个不同的文字，字体文件通常十几M，这样大的文字直接应用在网页上将会大大的影响网页的性能，所以@font-face在中文网站上使用到的非常的少。对于少量的使用（比如使用中文Logo），通常会制作精简版的字体。

另外，目前有两家公司提供中文 WebFont 云托管服务，他们能够压缩与转码字体：

font-size字体大小的选择

字体大小的单位

在 CSS 中，最常用的描述字体大小的单位有两个：em、px。通常认为 em 为相对大小单位，px 为绝对大小单位。但从实际应用中来讲，px 像素其实也是一种相对大小单位。例如，在一块15寸分辨率为 800×600 像素的屏幕上，10px 大小的文字，要比一块10寸分辨率 1024×768 像素的屏幕上的 10px 大小的文字显得更大一些。

px：像素单位，10px 表示10个像素大小，在现在的网页设计中，常被用来表示字体大小。很方便很直观，但是有一些弊端。对于可用性不太友好，因为是“绝对”单位，所以有些浏览器（早期）的字体放大缩小功能失效。浏览器的默认字体大小为 16px ，早期的网页，由于屏幕分辨率比较低，通常采用12px作为网页正文的标准字体大小。但是在现在，感觉有点偏小，比较长的文章来说，浏览者看起来费劲。
em：相对大小，它表示的字体大小不固定，根据基础字体大小进行相对大小的处理。浏览器默认的字体大小为 16px，如果你对一段文字指定 1em，那么表现出来的就是 16px大小，2em 就是 32px 大小。相对大小单位有很广泛的用途，由于它的相对性，所以对跨平台跨设备的字体大小处理上有得天独厚的优势，同时对于响应式的布局设计也有很大的帮助。

更多信息请查看： https://www.biaodianfu.com/css-font-size.html

字体大小的选择

通过上面的单位介绍，对于 px 单位中，举得例子都是 12px、14px、16px、18px等等，为啥不是11px、15px？这涉及到一个锯齿的问题，特别是在早期的显示器中，往往不能很好的处理文字的锯齿问题，而使用单数的像素，极有可能造成锯齿，所以默认的通常使用偶数大小。Windows 自带的点阵宋体从 Vista 开始只提供 12、14、16 px 这三个大小的点阵，而 13、15、17 px 时用的是小一号的点阵（即每个字占的空间大了 1 px，但点阵没变）。对于13、15、17px的宋体，其大小与其小一号一样，只是间距多了1px。所以在Photoshop中所使用的13、15、17px宋体并不能在web上正常还原，设计时应避免使用13、15、17px的宋体。推荐的字体大小：正文16px，标题22px。

总结

字体设置涉及到的知识点非常的庞大，整理的时候只涉及到了皮毛，前端开发人员和设计人员可以好好的再进行深入研究。

The post 网站开发中的字体设置 appeared first on 标点符.

经纬中国投资了哪些项目？

Tue, 30 Jan 2018 18:54:10 CST

投资人会比较喜欢什么类型的方向或者企业，可以从一些投资公司的行为大致做下了解。以下信来自经纬2017年终盘点：Come Hell or High Water

投资分布：

投资的一些企业：

出行

滴滴出行
ofo小黄车
瓜子二手车
小鹏汽车：新能源汽车
车和家：新能源汽车
e代驾
ETCP：停车
航班管家
凹凸租车：共享经济型租车服务

教育

VIPKID：在线少儿英语
猿辅导：K12在线辅导班
尚德机构：职场技能培训
传智播客：IT培训
百词斩：英语学习
宝宝玩英语：幼儿英语
考虫：大型备考
轻课：英语学习
上海STEM云中心：STEM教育

饮食

饿了么：外卖
美味不用等：餐厅排队
宋小菜：食材B2B
大丰收168：农药
热辣生活：连锁品牌餐馆
美味生活：餐饮学习
嘉席：米其林大师O2O平台
恒记联和：鲜切水果
六膳门：外卖供应

新服务&新零售

链家地产
路客旅行：当地旅游服务预订
土巴兔：装修
有赞：B2C商城搭建
野兽派：鲜花
租租车：境外租车
摩天轮票务：票务预订
趣学车
黄包车旅行：境外专车
优剪：理发
无界空间：联合办公室
土著游：跟着当地人旅游
婚礼纪：结婚一条龙服务
乐铺：商铺出租转让平台
觅跑：共享建身仓
闪修侠：电子设备修理
多抓鱼：二手书交易
诗莉莉：度假酒店
有福妈妈：月嫂服务
知果果：商标注册
植观：洗发水

颜值经济

新氧：美容整形
美柚：经期记录
更美：微整形
Camera 360：照片特效
裂帛：独立设计师服装品牌
花点时间：包月鲜花
美甲帮：美甲
女神派：共享衣橱
Plum：二手时尚电商
石榴集：印花女装

B2B交易平台

找钢网：买卖钢材
云鸟：物流
猎聘：招聘
震坤行：工业超市
房产销冠：卖房
酷家乐：专修设计软件
找塑料：塑料交易
易点租：办公电脑租赁
中国会甲集团：会场预订
车通云：汽修配件交易
猎芯网：电子元器件交易
一手：女装批发

企业服务

科瑞国际：猎头
七牛云：富媒体云服务
北森：HR管理软件
销售易：移动CRM
QingCloud：富媒体云服务
名片全能王：名片识别
GrowingIO：数据统计
树根互联：物联网
oTMS：运输管理
PingCAP：统计云服务
上上签：电子签名
佳格天地：卫星遥感监测
环信：即时通讯云
盖雅工厂：考勤排班管理
智慧图：市内导航
永洪科技：大数据分析平台
NewBanker：财富管理
SamrtX：虚拟化云
亿方云：企业文件管理和云协助
云杉网络：网络管理工具
玉符科技：身份认证
才云科技：容器云

新技术

猎豹移动
易航：航空培训
机智云：物联网开发平台
深醒科技：人脸识别
泰迪熊：短信电话拦截
库柏特：工业机器人操作系统
蓦然认知：自然语言识别
Perceptln：视觉扫描
天仪研究院：微小卫星太空实验室
亮亮视野：只能眼镜
橙子自动化：3C自动装配
TVR时光机：VR游戏
烁思科技
Autobot：汽车智能
酷咔数字：VR

金融

乐信：分期购物
富途证券：港股、美股交易软件
积木拼图集团：小微信贷
91科技集团：在线金融产品购买
第1车贷：车贷
保险师：保险代理
钱方好近：线下营销系统
e代理：海外资产配置
磁金融：小微企业信贷
保准牛：保险定制
真融宝：融资平台
91征信

医疗

键友药业：药物研发
理邦仪器：医疗器械
拓普：基因检测
沛嘉：医疗器械研发
瑞奇外科：微创外科
掌上糖医：血糖
微脉：医疗信息化
卓正医疗：连锁医疗机构
翼展：智慧医学影像
心诺普医疗：心脏电生理领域
安心医生：医生患者沟通平台
太美医疗：医疗信息化
星童医疗：生物检测仪器
希望组：基因检测
图玛深维：医疗影像诊断
友睦齿科：齿科连锁
未名企鹅：医药B2B
领健科技：口腔诊断
药品终端网：药品电子商务
禾柏生物：体外诊断
Nuance Biotech：药品研发
小雨伞：健康保险

泛娱乐生活

陌陌
上海恺英：游戏开发
宝宝树：育儿社区
36氪：创业资讯
果麦文化：出版+电影
me：直播平台
留白影业：影视制作
荔枝：荔枝FM
香蕉游戏：游戏赛事运营
五元文化：影视制作
爱拍原创：游戏视频分享
白鹭：HTML5游戏
果派：影视制作
橘子娱乐：原创新闻资讯
铁血网：军事社区
小年糕：有声影集
每日科技：科技资讯
美篇：图文编辑工具
开眼视频：小视频

The post 经纬中国投资了哪些项目？ appeared first on 标点符.

电商后台系统，到底是怎么回事儿？

Mon, 05 Dec 2016 11:20:54 CST

后台系统，也不能叫做一个系统，很多公司将其拆分为很多子系统，阿里更将其发展成了中台事业群（搜索事业部、共享业务平台、数据技术）。后端一系列系统支撑着公司各种业务的进行和发展，前端展示、业务处理（订单、优惠券）、库存变动等进行时，后端各系统间互相调用接口进行数据更新。

“双11”前后，新零售概念不断被阿里内部提及，马云预言纯电商时代已去，新零售时代已至。作为一名电商产品经理，身处如此时代，亦会觉得不负青春。

做产品以来，主要做后端支撑产品方向，目前对各模块系统都有所涉及。初次接触时，在网上找了很多资料，发现关于产品的相关文章，大部分都是关于产品体验、交互、APP等，提及后台的文章基本浅尝辄止，很少有文章来系统介绍后台各模块（商品、订单、营销、物流、支付、会员、评价、采购……），就计划写一系列关于后台各模块的产品设计文章，希望能够帮助在产品路上成长的PM。

后台系统，也不能叫做一个系统，很多公司将其拆分为很多子系统，阿里更将其发展成了中台事业群（搜索事业部、共享业务平台、数据技术）。后端一系列系统支撑着公司各种业务的进行和发展，前端展示、业务处理（订单、优惠券）、库存变动等进行时，后端各系统间互相调用接口进行数据更新。

由于商业性质决定了电商业务支撑系统必须具备稳定性、可扩展、安全性强等特点， PM在设计产品架构时，应充分考虑到业务发展需要，尽量将各模块隔离，商品模块建个商品中心，订单模块建个订单中心等等。只有在产品设计上有模块化思想，具有前瞻性，技术在开发时才会考虑业务隔离，当业务调整、功能新增时，开发可迅速进行，避免牵一发而动全身的事情反复发生。

针对一般电商业务，我简单画了一张产品模块示意图，基本一些中小型电商公司的产品架构大致如此。除了图中所示，现在很多电商公司开始转型社交电商，采用UGC模式或直播电商，在产品架构上会新增资讯系统，实现资讯与商品的高度融合，本文不过多涉及。

对电商公司来讲，最核心最难做的三部分：商品、订单、库存。商品与店铺、营销、评价等相关，订单与会员、营销、支付、库存、物流等相关，库存与订单、采购、WMS、营销等相关，系统之间业务逻辑和交互异常复杂，规则多样。

商品中心：

主要管理SKU(最小库存单位)、SPU（标准化产品单元）、属性（关键属性、非关键属性、销售属性）、类目品牌、价格等有关商品的数据；

订单中心：

管理订单类型、订单状态，落下关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据，进行库存更新、订单下发等一系列动作；

支付中心：

主要调用第三方支付平台接口，记录支付信息（对应订单号、支付金额等）；

会员中心：

主要管理用户等级、用户权益、积分、卡券等会员相关信息；调度中心主要将订单信息转化为发货通知单，调度仓库和物流进行发货；

客服中心：

主要管理退货退款、售后服务等操作，包括呼叫中心、在线客服等，与之对应的是工单系统，将客服任务进行队列管理，分配给相应的客服；

营销中心：

主要管理活动相关，优惠券、满减、专场活动、促销专区等，营销工具的开发对电商尤其重要，营销活动的滥用造成的用户疲劳，怎样推陈出新，给电商产品经理造成了很大挑战；

运营中心：

主要是对用户端进行页面配置（Banner、ICON、TAB）、价格管理等，一般会营销中心并入运营，作为其一部分；

评价中心：

管理商品评价和用户反馈，这并没有想象的那么简单，涉及到一些敏感词和敏感图片的筛选，以及回复内容管理；

店铺管理：

功能庞杂，相当于提供给B端用户一个Saas管理后台，提供管理商品、营销、订单一系列功能，主要针对一些有to B业务的电商开放平台；

采购中心：

管理SKU，当库存预警时，及时生成采购单进行入库，有供应商管理模块，主要进行供应商管理评级，发展新供应商等功能；

财务管理：

主要和订单、采购系统相关，数据准确性要求较高；

WMS系统（仓库管理系统）：

主要是入库、出库、盘点等模块，WMS主要和调度中心进行数据交互，反馈出入库状态和库存变动；

物流中心：

主要进行运费模板、运费管理（前端订单、真实物流成本）、物流状态保存查询（快递100、菜鸟等关联），如果是跨境电商，还涉及到和海关总署的对接，进行报关操作。

风控中心：

主要利用大数据进行用户信用建设、反欺诈，避免恶意评价、刷单退款等操作，构建安全的电商购物环境。

对电商后端支撑线各模块的业务功能有初步认知之后，可以看到的是，平常手机中的一个电商APP，背后是若干系统在支撑着，亦是许多技术和产品人员在辛苦付出。

以客户下订单为例来介绍业务信息在各系统之间的流转，涉及主要的信息交互如下图所示。从用户选择商品、生成订单到订单出库、物流配送、用户签收、退货退款，信息在多系统中流转更新数据。

从图中可以看出前台的一小步，后台的一大步。对于产品经理来讲，理清各系统之间的业务逻辑，特别是在商品类型多样（服务商品、实物商品、服务加实物商品等），业务复杂（预售、代销、代发等）时，各系统模块的隔离，设计时考虑扩展性非常必要。

粗略的介绍了一下后台支撑系统的各子系统，希望能够给你一定的参考性。如果想更深入了解各子系统，可以关注我，接下来打算写一系列文章介绍各子系统。

本文由 @Bouny_Yuan 原创发布于人人都是产品经理。未经许可，禁止转载。

问答网站StarOverflow的盈利之道

Tue, 22 Nov 2016 22:34:42 CST

昨天在小道消息上看到的这篇《Stack Overflow: 我们如何赚钱》，感触还是蛮深的。重点的内容我都进行了加粗处理。具体内容：

我是 Nick Craver，你可能还记得我。我之前写了三篇文章 How Stack Overflow does deployment、 How we do hardware 以及 How we built our architecture。

关于我们如何赚钱，我还一直没有谈及，对于大部分开发者来说这一直是一个迷。我现在决定来谈一谈我们是如何赚钱。更最要的是， 当我们的工作逐渐变得可敬，我们已经知道如何去做。我对我们的同事的日常行为有很高的要求，因为在用户眼里，我们代表了 Stack Overflow。我对我们的用户信息讳莫如深，你可以问问任何在 Stack Overflow工作的人是不是这样。我一直坚信我们正在和社区建立一种坚不可摧的信任。我希望能在看重这种信任的公司工作，而现在我就是。

尽管这是一个公开的理念，但是过去我们还是听到很多人对我们如何既能尊重用户同时又能赚钱表示担忧，因为我们毕竟要为我们的投资人挣钱同时还要保证公司运作下去。我们想纠正这种看法。诚然，钱对于公司持续发展是必须的，但是我们的存在的意义本来就是为了帮助我们的用户，我们存在是因为你们让我们存在。用户才是我们的初心。所以我们不断地把资金用在改进社区的工作上，而不是把我们的产品看成是一种从社区获利的工具。我们挣多少钱就表示我们对用户的帮助有多大。为了做成了不起的工作，我们专注在怎么样才能最大化地帮助用户。很少有公司能够成功做到这些，很荣幸也很骄傲，我们是少数中的一员。

我们怎么赚钱

招聘业务

我们通蚄，一是用来回答这个经常被问的问题，二是我和公司都相信对于社区坦诚布公是百利而无一害的。这涉及到现实中一些比较模糊不清的事情，比如财务，这也是为什么我们会创建一些项目，比如 Stack Overflow Salary Calculator，来使我们的工资流程透明化。

我们为什么要赚钱

在正式开始之前，我来交代一些背景：我负责 Stack Overflow 的架构组，就在我写这篇文章的时候我们刚结束了公司年度聚会( meetup )。聚会对于远程工作者来说非常地棒，比如我，因为终于可以面对面地认识之前和我一起远程工作而从没有见过的同事了。

年度聚会也提醒着我们为什么要做 Stack Overflow，我们都做了什么以及我们怎么样才能做的更好。在过去 6 年里， 我觉得我做的事情（注：指的就是 Stack Overflow ）给予开发者们不曾有过的资源，而且每一天我都在努力去让它变得更好。但是我不是一个人在孤军奋战，我非常幸运地能够和一些最棒的开发者、系统管理员、设计师、经理、营销人员、销售一起工作。Stack Overflow 不是我一个人的成果，而是我们大家一起努力的结果。

我上周一直在和我的同事们讨论我们是怎么发展成一个公司的，这些人中有的从来没有说过ory-is-the-new-technical-resume/”>Developer Story」。我做这件事情的初衷是我们可以通过简历极大地改善我们的生活。这以一种可维持的方式帮助开发者展示他们是谁，他们做了什么。当然这也可以帮助你找到工作。如果你在找工作，或者只是好奇，不妨完善你的 Developer Story，越完善机会越好。

如果你对上面提到的都不感兴趣，当然也没关系。除了帮助你找到最匹配的公司，我们还有「Jobs」和「Developer Story」这两个产品去支持我们的核心使命：帮助所有的开发者，包括那些暂时还不想找工作的。我们正努力地改变公司招聘开发者的方式，一是通过制定站内的招聘准则（比如，不容许垃圾邮件），二是通过我们的「 Developer Hiring Blog」（目的是培训招聘者如何招聘）。通过 Developer Story，我们希望改变这种观念：开发者只能通过他们过去的工作和职称来衡量。开发者应该是有故事要讲的创造者，他们的故事可以是他们写过的代码或者博客，也可以是他们以前工作过的团队，甚至是他们现在在读什么。这些产品的目的不是为了敲击招聘工作的底线，而是为了打破常规。

广告业务

我们是一个大型的网站，广告业务目前还是我们赖以生存%8商业产品「 Display Ads and Talent」去帮助一些公司做品牌宣传和招聘。 这种服务反过来帮助开发者找到更好的工作，同时 以一种用户体验良好的方式（没有垃圾邮件和动画广告，等等）宣传公司。我们做的每一件事都会考虑用户体验，这也使得我们的产品独一无二。

这很像问答产品。公司的问题是需要开发者，我们需要开发者去回答这些问题。为了让整个流程跑起来，我们需要两边的力量匹配。公司和开发者越多，我们就能为开发者提供更好和更快的理想工作匹配。对于公司，我们的目标是提供数量不多，但是精准匹配的开发者，而不是数量庞大但是匹配度很低的开发者。这就是我们体现价值的地方。我们一直在优化目前业界的招聘流程，我们不希望公司和开发者在招聘和求职上极大地浪费时间并且低效。

我们处在一个相对来说独特的位置，因为我们既可以帮助公司，又可以帮助开发者。这不是痴人妄语，我相信我们可以做到，并且比其他公司做的更好。我们已经为数以千计的开发者提供了工作，同时还有更多的职位虚位以待。改善这种状况的一种途径就是我们的「 Open Source Advertising – 2H 2016），我们就可以展示一个付费广告。但是我们没有这样做，因为如果我们不能给你们提供更好的东西，那么我们就不提供。

同时我们也不想用一个自动化系统去为我们选择广告。我们考虑过，但是它不能保证我们期望的广告质量。我们因此损失了一大笔钱。牺牲质量从来都不是我们的作风，我们相信有更好的方式。

值得提的很重要的一点是，我们的销售团队拒绝了一些我们可以卖的广告。通过卖广告确实可以赚钱，但是他们却拒绝这么做，因为相比赚钱来说，他们更关心我们要做什么以及用户如何看待我们。你现在能想象出来这群人是多么的奇葩吗？不仅如此，面对老板的时候，销售团队也是这么做的。 所有人都跟关心比我们自身利益更重要的事情，这也是我为什么要在这儿工作的原因。

我们有些广告加载的有点慢（多谢用户的反馈）。我们为广告主做了问题追踪，并在力所能及的范围能帮助他们。由于影响了不少人，这个问题是一个很复杂的问题，但是我们还是努力地去做了。Samo 和我会针对这些加载慢的广告做采样，并添加时间统计信息，这样以后后类似问题就可以进行自动报警了。我们认为广告加载慢或者价格不菲都是对用户体验的伤害。性能是一个特性，以及网页上的任何元素对我们都很重要。

我和我们的广告销售团队一起努力，保证在 2017 年 1 月，我们所有的广告都将支持 HTTPS。现在很多也都支持，但是并不全部保证，我们以后会加强这方面。我不希望这成为其他任何事情的阻碍。我们计划把我们的所有的 Imgur 图片地址迁移成 https://。同时我也打算把所有的网站 logo 和图标地址迁移到 https://。我们正努力地进行这项大工程，这里就不细说了。

企业版

我们将投入更多的精力去开发 Stack Overflow 企业版。这件事开始逐渐地需要更多精力，同时这也是帮助那些受困于公司防火墙的开发者和我们公司内部。我们现在有几个同事在全力做这件事儿。企业版的环境有一点特别，需要一些特别的热爱。

但是企业版也是基于 Stackoverflow.com 的代码，取自同一个代码分支。有时候企业版的特性正好也是大众版需要的特性。比如我们想针对 HTTPS 建一个图片代理%4主要手段。但是我们不希望你去点击你不关心的东西，我们只想给你想要的。

我们的目标是给你尽可能相关的东西。不管怎么样，我们会始终这么做。不管是为了生存而投放广告，还是广告要尽可能地和用户有着密切的相关性，都是我们的工作。实际上，我们有一些非常聪明的同事在做这方面的工作，同时这么做的终极目标都是：只有理解开发者，我们才能更好地服务他们。

我们怎么怎么看待广告屏蔽插件的呢？我们不在乎，原因在这儿： https://stackoverflow.blog/2016/02/why-stack-overflow-doesnt-care-about-ad-blockers/。

Stack Overflow 的广告现在是怎么样的呢？简而言之， 我们不会增加广告的数量，而是去改善现有广告的质量。相比与其他网站，我们能够更容易地挖掘( https://kevinmontrose.com/2015/01/27/providence-machine-learning-at-stack-exchange/)出来你作为一个开发者喜欢哪些技术。我们在研究利用什么才能让广告和用户相关性更高。当然这会耗时略长，但我们也希望广告加载也能够更快——那就是另一个大项目了。

我们一直没有做的是降低我们的广告质量。你们知道 Stack Overflow 每个月都有很多广告没有卖出去吗？只要我们展示一个「house ad」（注：根据 webopedia 的 house ad 务器，这正好也是受防火墙保护的企业版所需要的。还有我之前提到的用户停留时间，正好可以帮助我们用来估算带宽。企业版也是我们正在进行的一个大的方向。

信任

对于我们这种规模的公司，要赚钱，市场部是非常重要的。但是两年前，我并不信任我们的市场团队，因为他们没有名气，而且我没有听说过。我之前有过关于营销人员的糟糕经历，所以我潜意识里认为「所有的营销人员都是差劲的，他们只不过想利用用户的信任来赚钱罢了」。结果证明我错了。在我和团队共同做过几个项目之后，我逐渐改变了我的偏见，并且意识到：我们的市场营销人员都很厉害，并且我在意的东西，他们和我一样在意。特别是对 Kaitlin，感谢。我们的新团队已经对市场部做了很多妥协并且不会再因此而吵架。市场团队会用实践告诉我们为什么这些事情是一些非常棒的点子，他们在很多事情上说服了我们一些非常聪明的人。

我们团队的所有人都明白 Stack Overflow 社区以及他们的信任是我们最宝贵的资源。 我们希望和用户交流，而不是疏远。我们认为我们可以帮助我们的用户。如果我们做的正确了，这反过来又能帮助我们成为一个更好的公司。我并不认为这是一件坏事，如果我们可以壮大我们的公司，那么我们就可以为这个世界做更多有意义的事。对于你们，我有太多太多想要去做的事情。

Adrianna（我们的新 CMO）的演讲给我留下非常深刻的印象。在这个聚会之前我并没有见过她，但是却给我留下了深刻的第一印象。关于我们的品牌宣传他们有一些非常棒的方案。当我听她演讲的时候，我的脑海中就一直在想「我们十年前为什么没有做这些？」。

市场营销，就像开发一样，更多地是将一个个孤立的点连接起来。我已经从最初的恐惧市场人员到渴望和他们一起工作。我们现在有很多聪明和用心的员工，他们让我们每个人都参与到公司的建设当中来。我现在真的很激动。

案例研究：我们如何建立信任——邮件

互相信任和共享信息直接关系到我们如何构建内部工具。下面是一个最近的例子，体现了信任在我们的产品中是一个多么必需的特性。

我管理的架构团队是怎样的呢？我们团队编写了一个套新的邮件系统，用来以一种固定的方式和我们的用户进行沟通。这个项目困难重重，我为什么这么说呢？因为我最初对这件事情 100% 地反对，后来E4。这里我们想做一个好公民。每一封新邮件，除了需要处理的邮件比如「忘记密码？」，被发出的时候在底部都有三个链接：一键取消订阅、分类管理和反馈。

我们这么设计邮件系统（需要非常多的精力）的一个原因是如果我们的设定条件不满足的时候（我们现在使用的是 SendGrid，目前为止体验良好），我们非常肯定你对这类邮件不感兴趣，并且退订了。我们不想冒任何风险打扰对我们的产品明确表示不感兴趣的用户。

然而目前我们只有一个分类（「新特性」），我们计划增加更多的分类。但是我并不是说增加更多的邮件，而是把目前现存的邮件，比如 [ 社区简讯]，归入我们的新系统，这样你就可以用一种非常方便的方式来管理了，比如一键取消订阅。坦率地说，我们的邮件偏好度页面简直就是灾难。

邮件系统是任何网站发展过程中都需要去慢慢精雕细琢的。我们现在有员工现在在做这方面工作。我们的一个设计师，Donna，正在非常努力地去尝试简化它。我们的后端也需要做非常多的改变来支持这些统一和简化。我们希望我们每个用户有一个邮件地址和一个你可以管理所有来自 Stack Overflow 的邮件的地方。如果你感觉不悦，那么你最多需要点击一下到两下来退订所有邮件。

所有的沟通和互动都应该反映了我们对你的尊重，如果没有做到，那么我们让你失望了，同时也让我们自己失望了。我们的使命是提高开发者的生活品质，当我失眠的时候，我经常在担心这个。我们一定要值得你们的信任，幸运的是，我们做到了。

当我们之后为邮件做新的归类的时候（不仅仅是把我们现在发送的做个简单的分类），现存的用户不会被选择加入，只有新的用户会。我们不想被称人称为「那种网站」。我是认真的。我们会针对这个重新设置我们的 DB 结构。如果你读了我们的「Develop Story」邮件，而且不想收到，这是完全没问题的。我希望 Stack Overflow 能够用另外更好的方式来服务你，而且我们不会浪费你的时间。我希望其他项目，像「Documentation」和正在进行的「Q&A」，能够让你在 Stack Overflow 的生活更加地自在。这就是我们为什么存在的原因。也是我为什么在 Stack Overflow 的原因。

接下来的计划

关于未来我们有很多的事情可以做。我想在 SQL Server 中加入一个时间序列的数据库。我想验证我们在午夜想出的一个关于开发者新闻的消费的点子。我想做一些数据连接Ｒ手把它送上线。顺便说一下，所谓的架构团队只有我和 Samo Prelog。团队只是一个听起来的力量更强的词。或许我们应该叫做「伙伴」。或者说我们是一个由俩人组成的正义联盟。言归正传，我们继续说邮件。

关于邮件系统我设计的第一条准则是什么呢？可以选择退订。（注：原文是 opt out。维基百科的定义：The term opt-out refers to several methods by which individuals can avoid receiving unsolicited product or service information. ）。这是我们做的第一件事情，并且我们觉得这是对我们最重要的特性。我们设计了一键取消订阅以及一个对应页面，通过页面你可以退出任何不想继续看到的话题。这个特性的优先级为 1。(注：应该是优先级最高，如果他们没有优先级 0 )。多年以前我把 LindedIn 发来的邮件都放到了垃圾箱里。如果你不想再收到我们的信息，当然也没问题。我对我们的打扰表示非常抱歉，同时对用户的理解表示真诚的感谢。我最担心的是让社区的用户感到烦恼，这经常让我晚上睡不着。

现在我们正通过邮件将我们的 Developer Story 计划发送给我们的用户，希望这可以帮助一部分的开发者。如果邮件被拒绝，我们将不再发送给你；如果邮件没有回复，我们将不再发送给你；如果邮件被标记为垃圾邮件，我们也不会再发送给%这可以帮助团队之间工作节省很多时间。我还有很多事情想要去做。

对于未来我感到非常兴奋。我为 Documentatoin 感到兴奋，同时我也为 Developer Stories 感动兴奋。我已经等不及要出发了。我想从公司拿出一部分钱，那么我们就可以为社区做一些对社区有用的事情了。我知道我们能做到，并且能做的很好。我希望我的这些只言片语能够帮助你们了解 Stack Overflow 是什么样的，哪怕只是一点点了解。

本文译者陶克路英文原文： http://stackoverflow.blog/2016/11/How-We-Make-Money-at-Stack-Overflow-2016-Edition/

产品实例：某项目APP后台系统设计

Mon, 26 Dec 2016 16:47:30 CST

今年有幸参与了某度假屋项目从0到1的设计过程，展示给用户的是精致的APP，然而APP背后却是逻辑比较复杂的后台系统。APP的使用体验，很大程度上是由后台系统决定的，后台系统逻辑的合理性决定了APP的核心流程。

业务介绍

简要介绍一下此项目的业务流程如图1所示：

业主购买度假屋并由物业管理公司托管，业主购买度假屋有三种类型：全套、分权、分时，全套即业主购买整套度假屋，分权即业主购买度假屋部分产权，分时即业主购买某季的居住权。

业主每年可以获得一定数量的居住券，分权、分时业主每年获得28张居住券，全套业主每年获得365张优惠券。业主可以选择自住、换住、出租，其中换住是在平台进行，业主将一部分居住券储存在平台，平台返还用户一定数量的换游币，用户可以使用换游币在APP预定其他地区的度假屋并前往居住。所以，此平台是一种度假权益交换的共享度假平台。

图1

后台系统设计

了解业务以后，我们详细介绍后台系统的设计思路，后台的主要系统构成以及流程如图2所示：

图2

销控管理系统主要对度假屋的销售情况进行管理，以及线上的销售合同管理；物业管理系统对度假屋托管情况进行管理，以及线上的物业托管合同管理。

业主托管并签订合同后，业主信息将传递给会员中心和空间管理系统，空间系统根据淡旺平季以及度假屋类型，分发给业主相应的居住券。

业主可以用居住券在APP储存，储存成功后获得平台的换游币。居住券的储存，换游币的换算等动作都是通过super后台系统，同时，super系统还要对空间管理系统的房屋进行包装，最终在APP展示相应的房源。

super系统是APP的核心后台系统，分为运营、客服、超级管理员三种角色，运营主要对系统中的房源信息进行编辑；客服查看订单和会员相关信息，同时可以帮助业主储存居住券。

用户在APP下单后，订单中心生成入住订单，物业方在PMS系统确认订单，PMS系统主要是物业方进行排房、订单管理、房态房量管理、房价管理等操作。

有的物业方没有PMS系统，平台提供了PMS供物业方使用，如果物业方原来就有PMS，则平台提供E-Booking系统供物业方与平台对接，E-Booking系统是平台与物业方确认房源、房屋底价录入、房态房型管理、结算等操作的对接系统。

总结

作为项目的产品经理，首先需要对业务非常熟悉，要做到懂系统人群里最懂业务的，懂业务人群里最懂系统的，这样才能将业务逻辑很好的融合进系统，转换成系统流程。后台产品经理与前台产品经理，前者需要深刻理解业务，将现有的业务流程落实到系统，支撑前台的功能流程；而后者更需要对用户行为进行深入挖掘，对交互和体验有一种死磕精神。

本文只是粗略的说明了此项目后台的系统功能及流程，具体的每个系统还有比较复杂的内部功能逻辑，后续文章会做详细的说明，敬请期待~

本文由 @悠闲小生原创发布于人人都是产品经理。未经许可，禁止转载。

没数据积累和用户画像，我是这么做头条产品的……

Thu, 27 Apr 2017 14:51:04 CST

本文作者从0到1规划头条产品，在此想把自己的实操经验分享出来，值得一阅。

本来默默划船，在交流会上谈个性化推荐都不惹人注意的今日头条，毫无置疑现在已经被整个BAT围剿，内容领域的企业不自觉把今日头条当做竞争对手，非内容领域的互联网公司也都想来分一杯内容的羹，一夜间，互联网遍地都是feed流，不谈内容推荐算法都不好意思上桌了。

笔者近期有幸从0到1规划头条产品，想把自己的实操经验分享出来，如果对感兴趣的朋友有帮助自然开心，更希望得到业界大佬的批评和指正，毕竟一个人摸索前进，还是很危险的。

1. 明确定位

经常使用阅读产品很大的感受是大平台很容易出现资讯没深度，垂直的内容资讯只在某几个如科技，互联网等几个领域做的还不错，我当时的设想是有没有可能做行业内深度资讯，尤其是一开始切入那些并未互联网化过深的行业，通过一个行业的试点，形成行业头条，在沉淀优质行业知识的同时，以最低成本去复制到其他行业。

思考了挺久之后开始和老板汇报了，省去10000字具体说服过程，最终同意了，因为团队某公司与一个传统行业A有交集，所以一开始的切入行业就是行业A了，下面开始具体执行了，看着一共10多个技术人员，我陷入了深思……

劣势简直不要太明显：

没有数据积累；
没有用户画像；
团队没人从事过行业A。

我要开始作死地做头条产品了……

2. 头条产品整体设计

我开始从三个层面去搭建产品，底层类型标签层，中层数据抓取分析层，顶层业务应用层。

底层类型标签层

底层根据具体行业进行梳理，本来这个过程应该产品和具体行业从业人员配合梳理，但是碍于资源有限，那就我来吧，肯定不足够详尽，但是一开始可以先跑起来。

底层类型标签层分为类型和标签，类型有层级性，数据库预留到7级，实际梳理到3级就差不多了，如行业A，A公司是一个一级类型，A行业制造公司是二级分类，具体制造公司名称是3级类型，每个类型独立建表，每个表里关联海量标签到类型上，如行业A技术这个类型里我们找到行业A技术术语词典，删选后就作为标签关联到A技术这个类型下面，类型数最后梳理了600多，标签数量有10万多，数据库预留状态位，可以视情况进行启用关闭。

中层数据抓取分析层

数据抓取分析层分为爬虫部署，内容来源处理，数据归类。

1、爬虫部署

我以一个技术外行的角度把爬虫分为两类，一类是不定向爬虫，都是一个个单独网站，这种技术消耗较大，需挨个处理，如各个A行业公司的官网新闻中心和行业A平台网站，需单独处理，另一类定向爬虫，主要是有搜索功能的大资讯平台，如今日头条等，代码可复用，写好之后我直接建了一张表，专门放搜索爬虫的关键词，一堆关键词一套代码就可以实现，输入进去就把含有这些关键词的新闻抓取出来了，现在这张表关键词也有700多了，爬取来的内容量实在太大，建议用mongedb处理。

2、内容来源处理

数据过来后先进行来源梳理，划分优质来源和垃圾来源，提升优质来源内容的权重，优质来源主要是各公司官网，垃圾来源是指对具体行业而言，大量无意义的内容来自同一个来源，那么将他认定为垃圾来源，比如一个叫xx说车的来源在建筑行业被认定为垃圾来源，但是将来复制到汽车这个领域的时候，就不再是垃圾来源了，垃圾来源是一个长期的活，现在大概700多了，大部分垃圾来源是今日头条的头条号。

3、数据归类

过滤完垃圾源之后，就开始数据归类了，本质上是将新闻内容归到我们建立的一个个类型上，因为做行业资讯，希望一开始数据准度较高，我当时想了两种方案，第一种是将类型根据自己关联的海量标签按权重建立一个个模型，所有抓取来的文章做全文的分词处理，大量文章统计词频，每篇文章所有分词就有一个总的频率值，和类型模型比对，取相关性较高的，另一种就是把类型下面所属的标签和所有筛选过垃圾源的文章比对，含有标签的文章归到所属类型下面，含有同一类型标签越多，说明该文章相关性越高，为了快速上线就用第二种方案，但是相对，精度就差了一些，当然随着人工的介入，筛出一系列垃圾源，类型和标签维护工作的持续，内容准度好了一些。

顶层业务应用层

业务展现层主要是梳理目标用户感兴趣的关键词，将这些关键词关联到类型标签层的类型，这样，用户订阅关键词之后就可以看到这个关键词所属的内容，前台现在以及上线2个产品，一个订阅平台，行业头条，与之配套的是后台管理中心。

1、订阅平台

订阅平台半封闭，面向行业A企业用户和行业A自媒体从业者，释放出他们感兴趣的关键词，内容准度更高，企业用户订阅关键词，可以看到相关的资讯，看到平台具有的能力后，有欲望定制更多关键词，后台审核后继续部署爬虫，推送数据给用户，同时记录用户的所有行为数据。

2、行业头条

行业头条完全开放，面向准行业从业者以及泛行业爱好者，释放出更多关键词，但是较订阅平台，内容质量稍差，但是目标用户较广，所以寄希望记录用户的所有行为数据（如评论，阅读量，换一批事件，关注关键词等），得到用户反馈，建立用户画像，以达到根据不同用户画像推荐关键词的效果，为真正的推荐做准备。

3、后台管理中心

含有新闻管理，来源管理（优质来源，垃圾来源），类型/标签管理，用户行为管理，推送管理，关键词审核排期管理，评论搜索管理等，具体就不再详述了，有机会再详细介绍，简单的把产品框架梳理了一张图，和上面的论述结合起来，可能更方便理解。

（注：侵权必究）

3. 致同行

不要动不动就要再造个今日头条，如果你的体验和算法做不到比他强百分之五十以上，正面硬刚基本没戏，找准自己的切入点，认清自己的优势；

内容推荐从来都很危险，如果用户不需要的时候推荐，除非做到让用户惊喜，否则就是减分，用户一定要用的产品，用户只能忍着，可有可无的产品，极有可能被用户卸载，这点做公众号的朋友肯定深有感触，每次推送内容都怕掉粉。。

因为对搜索一直比较有兴趣，所以简单阐述一下自己对输入法产品想做内容的建议吧。

用户有自己了解资讯的需求：

主动获取：RSS抓取（google订阅），关注/订阅（即刻）
被打获取：平台推荐（传统门户，新闻网站），垂直类媒体资讯（36K，虎嗅等，最近冯大辉的readhub），个性化推荐（头条，一点资讯）

这一类需求竞争极其大，还有一类是基于特定场景下，对资讯的了解诉求。

比如找工作时，想了解某家公司；吃饭时，想了解附近餐馆的情况。

这一类诉求特别长尾，目前多是怎么被满足的呢？

主动搜索，到百度，知乎等平台搜索，但得到想要的资讯路径很长，比如你和朋友吃饭，你想知道附近有哪些好馆子，搜到的代价就就极高这种场景大量发生在哪里？聊天和查询的时候！这正是我觉得输入法切入资讯的机会，具体来讲：

当和别人聊天说要跳槽，谈的某家公司，输入法输入时有个提示（如颜色变化等）能方便的推送公司的最新资讯；
聊天约饭，方便推送出附近饭馆和评价；
和男朋友说要买赵丽颖同款，男朋友能方便看到这些商品的资讯；

这些诉求的背后数据，词汇出现的频率，输入法公司应该有足够的积累，大可根据词频做内容准备，当用户在输入东西的时候，给用户一个意外的惊喜，来达到资讯推荐的目的，希望有从事输入法这块的朋友能给予指导吧。

作者：小呆（公众号：小呆自留地），野路子出身的产品，非常诚恳的希望有同行能够给出批评和建议~谢谢

本文由 @小呆原创发布于人人都是产品经理。未经许可，禁止转载。

42 个移动端启动页面优化 Tips

Mon, 21 Sep 2015 11:11:44 CST

我们都听过这句话，“你只会有一次机会去打造第一印象”, 当涉及到移动端的启动页面时，这句话会更加令人信服. 在最基本的层面上，启动页面将会是消费者同你网站的第一次接触.

拥有好的第一印象是很重要的. 今年早些时候我们发布了这篇文章，《响应式设计不是一种移动端优化策略》，它专门讲为你的移动通信媒介打造专用移动端启动页面来将访问者转换成消费者的重要性.

移动端统计数据:

今年美国智能手机的移动商务收入为148亿美元. (Statista)
到 2016, 移动端本地搜索有望创造32亿美元的收入，相比之下，桌面端为102亿美元. (Kelsey 报告)
50%的智能手机用户曾通过他们的手机进行过消费(Prosper Mobile Insights).
73% 的智能手机用户声称他们曾使用移动端 web 而不是 app 来进行购买( JumpTap.com).

下面是42个移动端启动界面的优化建议，它们能帮助你将更多的移动端访问者转换成付费顾客，这些建议分为如下类别:

策略
基础
AB 测试

策略

1. 知道从哪里开始 —— 创建一个完整的移动端 web 是昂贵的，且会耽误许多的时间。所以起步的最好方式是通过跟踪分析，了解转型中的痛点和漏洞。一旦你了解了这些，你就会明白从哪里开始了。你所要在转型中关注的应该是流量，用户量和购买模式.

2. 了解你的顾客的目标 —— 确保你能了解移动端和桌面端用户的目标有何不同。你是不是想要他们拥有完全一样的体验呢？我们使用 web 和移动端相比有所不同，其体验是不同的，而且又是我们因为完全不同的原因同时使用两种或者三种设别.。要考虑到你的访问者会在你的移动端站点上做些什么，理解他们尝试要达成的目标是什么，并且创建一个用户导游来帮助他们更快跟敏捷的达成其目标。

3. 定义你的目标 —— 一旦你了解并且也定义好了访问者的目标，那你就要定义好启动页面的目标并在心里针对那个目标设计一种体验。扔掉那些不重要的信息、针对过个调用的动作按钮以及其它的噱头。要专注于启动页面最重要的元素，以及如何让它们帮助你的访问者完成你的目标。

4. 改变他们的生活：有无数的公司在做同样的事情。人们在移动端的站点上花费的时间很少，并且需要在几秒中之内理解你（页面上）最有价值的部分。记得要关注客户和他们的利益。至少要说明：“我们是世界上最好的”，多一些可以说：“这将会改变你的生活”。

5. 定义所需的操作 – 你希望访问者在你的移动登录页上，知道一个他所需要的操作，那就要制定一个清晰的行为召唤（call to action），最好是明显的，具有逻辑性的，这能让访问者明确地移动到下一步。

6. 在重要的位置表述 – 一个访问者应该能够很快就区分他们，而不是去阅读复杂的文本和故事。确保你有价值的位置是在页面的顶部。你的标题和行为召唤（call to action）应该在折页（fold）（当访问者登录到页面的时候就能看到的部分）之上，这样能更快速地让访问者取其所需。

7. 清晰地知道后果 – 重要地是让访问者能清晰地理解，如果他们提供信息，你将会如何使用收集到的信息。

基础

8. 忘记滚动 —— 要创建出适合一个移动端屏幕边界的页面，并且这样的页面不需要滚动。这一点同时适用于横屏和竖屏模式.

9. 同时为横向和纵向的屏幕做设计 —— 大多数人在设计移动端启动界面时都会考虑到纵向视图, 但是有赖于访问者会横着拿他们的手机，所以他们也可能会在横屏模式下浏览你的移动端网站。要确保你的移动端启动界面针对这两种情况都能进行缩放.

10. 使用本地化设置 —— 启用了 GPS 的设备可以运用特殊的本地化内容来减少文化差异的摩擦，提高转换率。在你的注册表单中你可以通过他们输入的邮编侦测到访问者的国别和城市。可以让“邮编”作为你的第一个地址信息输入项，并好好利用这一项信息来做点事情。

11. 移除外部链接 —— 通过移除连接到网站其它部分的外部链接，你可以控制访问者的浏览过程，使其更专注于你需要他们做出的动作。记住，移动端浏览器新的tab —— 打开立即就会是访问者原理你所设定的目标位置。要使其编程一次快速轻松的浏览过程，而别让他们跑到别的地方去了。

12. 去掉杂七杂八的东西 —— 集中在重点上，尽可能保持页面整洁，减少摩擦，保证按钮之间的间距足够大。杂七杂八的东西以及文字和颜色越少，访问者越愿意完成这项渠道。

13. 保持流程和设计的一致性——不要使访问者感到惊讶或被愚弄，在手机登录界面上使用他们在广告上看到的相同信息和设计。与信息保持一致，将有助于使页面的访问变现，同时提供广告品质。

14.别让用户缩放——登录页面的焦点由你决定。登录页面的设计方式将决定用户在网站上的操作。如果让用户缩放，他们将选择网站的焦点，而不是你。

15.点击呼叫——很多移动搜索用户的目标都是立刻获取联系。相比复制粘帖号码，直接使用“点击呼叫”按钮将更容易让用户快速开始对话。在开始前，设置好你的电话追踪器以便跟踪来电。

16. 调整键盘 — 确保在每个表格区域中使用合适的键盘。访问者可以不用改变键盘输出而快速的插入数字或者邮件。

17. 保持表格最小化 — 所有设备上的注册表单都让人沮丧，手机上的注册表单更是如此。由于在手机上输入非常费劲，所以在可能的情况下尽量避免打开文本域。确保表格够大够清楚，可使用全屏，并使字段和提交按钮大的可以用拇指点击（忽略右边区域，因为它太小不能拖拽）。

18. 简化搜索—让访问者可以很容易的快速找到他们需要的内容。将搜索元素放在核心位置，可以保证用户可以快速的找到他们所需要的。（记住，这并不是最重要的因素，所以不要让它反超其他元素）

20. 允许“稍后购买 ”—— 有时候我们没有足够的实际或精力来完成注册或购买流程。可以在其他设备上通过 email 或加到购物车的简单方式，让使用者可以很容易的在其他设备上稍后完成购买流程。

21. QA，QA，再QA —— 因为手机网站在你自己的手机上测试通过，并不意味着它可以在别人的手机上也可以。在开始前，在谷歌 Analytics上核查，以找出访问者最常使用的的手机屏幕。确保在多种设备上检查你的登录界面，并在一段时间内进行跟踪。

22. 要求少一些 —— 为了减少摩擦、提高转化率，可对访问者要求少一些。在开始时，只获取所需要的最重要的信息，稍后再获取额外的信息。手机屏幕很小、时间宝贵，如果难以操作，人们将不会逗留。

23.使副本最小化 —— 大多数访问者不想通读文章的好几个段落。将最重要的信息放在登录页面上，使访问者快速移动到下一步。

24. 强调你的行动引导 –
行动的引导是一个访问者在启动页面看到的第一样东西。提供一个快速的方式让用户跟着你的行动引导，完成整个流程。让你的行动引导按钮可视，并且容易通过触摸屏点击。

通过 Naked Wines 检验以下示例：

大量文本
行动引导按钮被切断

25. 优化你的表单 – 让的的表单尽可能的简单，让访问者快速完成你的表单，尝试着分离成多个简单的步骤。

26. 标题尽量短 – 标题长度不要超过 3-4 词，尽量一行显示。

27. 构建限制数据大小 – 移动数据连接会比家庭宽带连接慢，用户并没有那么多耐心等待移动网站的加载。确保符合移动用户的需求，更轻量级。

28. 远离 Flash –也许在 Web 上看着不错(无法转换)，但在移动端并不合适。使用 HTML5，GIFs 和 JPEGs 会更好一些。

29. 将导航位置考虑进来 – 我们使用智能手机来看电视，开车，购物和完成各种功能。应使移动端顺眼，并使用图标来进行快速导航（包括短文字说明）。

30. 拥抱第三方社交平台登录 – 第三方登录有着很高的转化率，对于鼓励访客和你的商品进行社交互动是个极佳的方式。

31. 提供移动独享 – 大多数人更喜欢使用 PC 屏幕来下单。为了提高转换率，可尝试提供移动端独享，以减少与 PC 端正面竞争，增加销售。

32. 为动作而设计 – 将所有的可点击元素设计为按钮(不仅仅是文本链接)，确保它们足够大，并留白以突出。

33. 少即是多——尽量使用少一点的文字，去除所有不必要的设计元素，只留下功能要素。

34. 消息个性化——智能手机提供了很多重要的用户信息。手机为用户提供了如 GPS 和基于位置服务的一体化特性，如：运往华盛顿！

35. 考虑字体因素——让文本更易读。使用更大的字体、行间距和字间距让文本容易阅读和略读。

36. 使 SEO 优化而不破坏转换策略——避免在手机登录页面使用大量文字，或者引入可伸展的 div 而引发混乱。这将缩短页面，使用户可以点击他们感兴趣的内容。

手机上的 AB 测试

37. 测试关键绩效指标（KPI）—— 开始测试前，确定你的商业目标，然后把它们转换为数字化的关键绩效指标（KPI）（例如注册数量、购买数量、下载次数）。一旦确定了关键绩效指标，就要确保建立正确的跟踪机制。

38.达到显著效果 —— 当你运行测试时，确保在达到显著效果前一直运行，你可以使用 Google Experiments 或者 A/B test calculator 来知道何时达到这个效果。达到显著效果可以确保你尽可能的从测试中了解更多，并知道它们的正确性。

39.避开特殊日期——在可以提供最真实的测试结果的环境下开展测试。避免在节假日、特殊活动或者结账日测试。

40.保持系统性——为了达到清晰并可理解的测试结果，确保在一段时间运行一个测试，或者如果你有足够的流量来同时运行多个测试组。

41. 测试策略，不是元素 –
当你处理好所有技术性问题和元素之后，可以增加用户转换率，但是要确保有测试策略，这样能更好的理解你的用户。测试按钮颜色或者标题只会让你关注某一个点。为了能获得最大的胜利，从你的测试中获取更多有价值的东西，你需要开启测试情绪化策略。

42. 使用一个清单 – 建议使用一个清单来记住以上讲述的所有启动页面优化的策略，确保没有漏掉任何重要的部分。一个清单也可以确保你和你的团队为每个项目都能按照这些策略去优化。

结束

响应式设计并不是一个移动优化策略。为了得到更多的移动访问者，创建专用的启动页面和启动页面的不同用户体验是成功的关键。

关于Uber机制的思考

Sun, 20 Sep 2015 00:08:27 CST

昨天写了一篇关于滴滴打车改版的文章（文章链接），引发了一些关于Uber和滴滴的对比讨论。

质疑明显歪了楼，大家主要讨论的是，Uber忽略目的地的问题和它的派单机制，而我在昨天文章中说的是Uber的首页设计的一些问题，具体来说，是它的出发地和开始用车的按钮不在一起的问题，以及出发地带搜索icon带来误解的问题。

不过既然大家讨论到了Uber的忽略目的地的机制和派单机制，我也就聊聊我的看法。

虽然现在Uber因为做出了拼车机制，开始要求输入目的地（许多喜欢Uber的人认为是一种倒退），但Uber此前的理念的确是会刻意忽略目的地的。身边许多朋友，也对这个理念表示认可。因为觉得它可以防止司机挑单。具体是，Uber的机制中，乘客一旦发出请求，附近的一位司机被自动被系统派单，必须前往接驾，否则将被惩罚。我奇怪的地方之一在于，这种派单机制中，即使乘客输入了目的地，不是一样派么？而就算乘客没输入目的地，司机也可以电话问乘客要去哪里，然后也可以根据自己的喜好取消单（这也是现在的现状，当然，有人要说了，他觉得这是在中国，在契约精神很强的国外，司机被派了单是不会被取消的，对于这种想法，我没有什么想说的），这不一样么。

话说回来，Uber首页的设计之差，与其机制和思想没什么关系，就是差。就算不想要输入目的地，不想派单，难道就不可以将出发地和发出请求的操作放置到一起么？显然这2个事情是有内在逻辑联系的，但Uber把它一个放在页面顶部，一个放在页面中间，令人费解。

关于目的地这件事，它对我个人的其中一个意义是掌控感。我不知道对于别人说是如何，但是对于我，一旦出行，一定是有一个想去的地方，打开出行软件，下意识会想到我肯定要告诉这个软件我要去哪里，这是一种我可以掌控自己去向的感觉，而不是第一次打开Uber，觉得无所适从，因为一开始预期想做的事情（告诉软件我要去哪里）无法做。当然，有人说线下招车也是招到再说目的地，那是因为你没法和还在很远的车里的司机说目的地，这样去招车，对于会挑单的司机，一样会拒单。

还有Uber的派单机制。派单机制的确让作为乘客的我觉得很有安全感，我作为乘客会继续使用Uber，我也非常清楚Uber的设计理念是希望它的叫车极快，但我仍旧不太认可它的机制设计，担心有一个比较严重的问题。就是，因为派单机制对于司机，显然体验是不太好的，或者至少对于滴滴那类可以让司机挑选单的平台来说相对差些。而对于这类资源平台，我认为保住司机比保住乘客更重要，我的这个倾向和我在UGC平台中强烈建议优先考虑内容生产者的体验，是一样的。Uber目前的做法，只能通过对司机的补贴比滴滴多，来决定，换句话说，同一个司机，在Uber中必须比在滴滴中赚得多，才会留在Uber。这个根本上的区别，导致对于乘客，不考虑短期的补贴，长远来看，滴滴一定比Uber便宜，也就是说，Uber会相比滴滴更加小众、高端。类似一个是大众，一个是宝马，不好说谁输谁赢，但从用户规模、估值规模的角度来说，Uber的模式未来会弱于滴滴的模式。

当然，我估计滴滴在一开始做抢单机制而不是派单机制的时候，也不一定想了这么多。我想的这些也不一定对，只是当前阶段我对派单和抢单两种机制的看法。我会继续两者都用，用滴滴是因为发票，以及觉得未来它会更便宜，用Uber是因为相对小众高端，和确定有车的安全感。

我都快好像变成Uber黑了，但是实际上我真的非常欣赏共享经济，因为共享经济是解决一个社会性的闲散资源分配不合理的问题，Uber（和Airbnb）算是共享经济的鼻祖。Uber做了许多创新，其中我印象最深刻的一条是在高峰期时通过某个区域内价格增加一个倍数，吸引更多车辆进入热门区域（也直观地让他们了解到哪里是此时的叫车需求多的区域），这对于车辆和乘客来说是双赢（加价会提醒用户），这个优秀的机制果然滴滴就仿照了，这是应该的。

关注我的公众号，阅读更多文章：

App设计者需要注意的21条禁忌

Sat, 19 Sep 2015 14:04:46 CST

我们通常在做APP设计的过程中，遇到很多看似很小，且很容易被忽略的问题，正是这些小问题，一次次的撩拨用户的耐心，让用户对你的APP心生怨念。现在WeX5君呕血为大家整理出APP设计的21条禁忌，希望与APP设计者的您共勉。

1. 不要在没有流程图之就前开始设计或者画线框图

即便一个简单的 APP 也要有一个思虑周全的流程图，以确保在 APP 有合乎逻辑的、合理的导航结构。另一点值得关注的是确保核心功能所在的屏幕位于上层而不是被埋没在多层导航元素之下。

跳过流程图直接进进入开发会让开发变得复杂、不可控，很容易让用户迷茫，最后选择关掉或者卸载你的 App。

2. 分工要明确不要忽略开发预算

设计师创建的每一个细节都要经过开发者才能变得活灵活现。花几个小时和几天时间做出的简单设计更改对 App 功能的影响是截然不同的。还有，设计不能命令功能。比如，一个计划好的 App 可能有一个搜索框，设计师预想的是一个产生实时结果的键入搜索，但设计师不能是做这个重大决定的唯一决策人。

3. 不要随意使用介绍动画

在用户首次打开 App 的时候，给用户一个动画的介绍是个不错的想法，但不能太过火了。事实上，这些介绍动画也延迟了用户接触 App 的时间。如果你打算使用介绍动画，那要让动画时间尽可能短，设计尽可能精细以及足够吸引人，值得用户花费时间等待。

App 加载过程中会先展现图片，再过渡至动画。要确保这个过度是平滑的，贴切自然的。有的 App 从加载图片过渡至介绍动画设计的非常蹩脚，这就很无趣了。

4. 别让用户空等

App 加载时间过长很容易让用户以为出现了什么故障，也会带来糟糕的用户体验。App 加载的时候不要让用户看到空白的屏幕，使用加载指示条或者小动画让用户知道 App 处于正常运行当中。如果能加入一个加载进度指示条就更好了。

5、没有不可点击的效果

一般按钮会有四态，不可点击效果、可点击效果、聚焦状态、按下状态。

如果你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导。

6、菜单层次太深

菜单项以5~7个为宜，如果有二级菜单，就要注意合理的菜单分类，不能有太多层级的菜单，否则很难预期，也很难找到，寻找和返回都会变得很麻烦。

7、文字长度不加以限制

APP界面很小，寸土寸金，一页只能显示下6~10个列表，一行只能显示下10~16个字，标题栏的字数以5个以内为宜，标签栏也以2~3个为宜，那么这时候出现文字过长的情况，一定要定义一下处理方式，如果是选择型的，一般是截断或者打点缩略;如果是内容阅读型的，可以折行。但最合理的方式还是精简文字内容，缩短文字长度。

8、文字表意不明

由于APP是碎片时间、片段式阅读，所以APP界面上的文字表意性要求的更高，更苛刻，一定要在用户瞟到的瞬间，准确的传达信息。除了表意清晰之外，还要求语言精简，避免啰嗦;使用用户的语言而不是程序的语言;产品文案体现产品性格。

9、交互流程分支太多

做交互的时候一定要有一个任务流程的概念贯穿始终，用户是为了完成某个任务而使用软件的，交互设计师除了关注界面元素、跳转逻辑和交互反馈之外，还要关注用户任务，分得清主要任务和次要人物，给主要任务一个畅通无阻的清晰流程，不要给予太多可能的分支，干扰主要流程。

10、相关的选项离的很远

相关选项一定要具有操作上的延续性，虽然APP屏幕看起来比电脑屏幕要小的多，但是APP在屏幕上移动的代价，却要比鼠标在电脑上移动的代价大的多，如果手机上相关选选离得很远的话，用户一是容易迷失，找不到下一步操作，二是需要移动手指，到屏幕另一端触发操作。

11、一次载入太多的数据

流量、电量、速度和稳定性是APP产品的四个硬指标，如果你的应用不能合理的帮助用户节约流量、电量，提升浏览速度和浏览体验，保证应用的稳定性能，就不要谈什么用户体验。你可以利用预加载缓存、批量载入、动态刷新、服务端数据压缩等方式来保证省、快、稳基础体验。

12、按钮可点击范围比看起来小

我们都知道移动端有个神奇的数字“44”，根据食指最小点触距离7mm、拇指最小点触距离9mm，可以推导出做设计的时候，最小的点触距离是44*32 px。你可以设计一个精美的小图标，但是在定义它的点触大小的时候，却可以做放大处理，但你千万不要设计一个傻大的图标，点触范围却比图标要小，这样会给用户带来明显的误操作挫败感。

13、标签页跟内容没有从属关系

标签页跟内容需要有很好的联动关系，一般一个界面内有二级标签就足够复杂了，千万不要再有三级标签、四级标签。每个标签页都有自己特有的内容，当切换标签的时候，内容跟着切换。标签页如果是点击切换，内容部分可以整体刷新，标签页如果是滑动切换，内容页也要跟着滑动切换，千万不要一个点、一个滑。

14、把所有的操作都暴露出来

APP产品交互设计要经历缩减、隐藏、附加、组织的过程，千万不要妄图把什么功能、什么操作都暴露出来，以彰显强大。你需要把自己应用的所有功能所有操作做个优先级设定，那些常用的20%的功能，放在界面的主要位置上，其他80%的操作，放在次要位置或合理归类组织后，隐藏起来就可以了。

15、没有空数据界面设计

我们在做设计的时候，往往是提供理想化的场景，用户都已经进来了，我们怎么玩。但是，往往应用刚推出的时候，是没有用户的，甚至当应用有了一定用户基础的时候，新进来的用户打开应用的时候，应用仍然可能是一种没有数据的状态，再或者当用户清楚了全部数据，这三种情况下，用户都可能遇到空数据的界面。新手设计师往往不加设计，这时候用户就会看到一个空白界面，茫然失措。有经验的做法就是，提供一个情感化的界面，告诉用户当前没有内容;更具引导性的做法，就是引导用户去执行操作。

16、用户引导的滥用

去年就预言用户引导将要泛滥，很明显设计部门都喜欢用漂亮的引导界面告诉用户新增的功能或隐藏的应用，但不是所有的应用、所有的功能都需要花哨的引导的。如果是通用的功能、非重点的模块，根本就不需要引导;如果是功能告知，只需呀轻量级的引导;如果是版本更新说明，说明书式的引导可以采用，但是要言简意赅。

17、无加载中状态

APP产品只要是需要联网，需要交换数据，都需要提供一个加载中状态的，无论是菊花转还是Toast还是对话框，你需要给开发人员一个全局的定义，并且要告知加载中是模态(前台加载)的还是非模态的(后台加载)。且要考虑到加载时间过长、网络开关没有打开、网络不通等情况分别怎么去处理。

18、未定义Back的逻辑

在为Android做设计的时候，会涉及到硬件交互，其中Back键的使用，是一门学问，Android官方有一些指导原则可以借鉴，但是具体开发的时候，还是会有很多特殊情况，比如单一实例的替换、键盘及一些中间状态，这种情况下，Back可能需要被定义一下，该回到前一个实例(那就需要变成多实例了)还是该回到初始状态(清空输入内容或恢复初始状态)。

19、无横屏模式的设计

由于横屏模式下，纵向空间变得格外宝贵，导航栏、标签栏、键盘都需要被压扁，横盘模式一定要考虑是简单拉伸适配还是重新设计，如果你的应用不适合在横屏模式下使用，就屏蔽横盘，如果你的应用包括应用widget都需要支持横盘模式(甚至是带侧滑键盘的横屏机器)，就需要提供设计方案。

20. 不要忘记手势但不要滥用

不是每个元素都是可视化的，比如 iPhone Mail app 的删除进程。在收件箱内，用户可以猛击屏幕显示删除按钮，用户就不用点击“编辑”，选择信息然后再删除信息。不过，也不能说“编辑”菜单一点用处都没有，不知道快捷操作的用户还是需要的，而用户还可以通过“编辑”菜单一次性标注多条信息/邮件。

21. 不要觉得每个用户有着跟你一样的 App 使用方式

可用性测试是必须的，不管你的 App 看起来多么好。找值得信任的人(或者有经验的设计师)进行小范围封闭测试，在公开发布之前更新下界面。另一个简单易行的获得用户反馈的方法是在分类网站张贴广告招募合适的人进行焦点小组测试。

22.怎么才21条？

App江湖上传言多年的关于多屏、多分辨率、多端、多操作系统支持的若干注意呢？

在WeX5君的世界观里，移动开发者不需要、不应该操心这个问题。

作者：WeX5君

微信公众号：起步软件