「后台列表页设计原则和技巧」

**摘要:** 本文详述了管理后台列表页的设计原则和技巧,对于新手有很大的学习价值。

无论是什么类型的产品,几乎都会出现「列表页」,前台部分的列表页设计技巧已经有很多的介绍了,下面我以「电商系统」为例,谈谈业务后台的列表页设计原则和技巧。

1 什么是「列表页」

1.1 「列表页」的概念

列表页是一些具有同种属性的内容的聚合。简单讲,在电商系统里面,展示所有商品或订单信息的或相似页面就是列表页。列表页的简单特征就是一行一条数据,和数据库或Excel表格的概念都很像。商品列表页就是一行一条商品信息,订单列表页就是一行一条订单信息。

1.2 「列表页」的类型

根据列表行数据的生成方式,可分为「主动型列表」和「被动型列表」,在阐述这两个概念之前,我们先来区分两种用户的身份,一种是「**使用后台的管理员用户**」,另一种是「**使用前台的终端用户**」,这两类人常常不是同一群人,我们都称之为「用户」,读者需要根据不同场景注意区分。

**主动型列表**:指的是列表中的数据是由管理员生成的,而非终端用户生成。例如「商品列表页」中的数据就是由管理员生成,与终端用户无关,用户在前台看到的商品信息均由后台编辑生成,用户无法变更商品信息。

**被动型列表**:指的是列表中的数据均是由终端用户生成的,而非管理员生成。例如「订单列表页」中的数据就是由终端用户生成,用户选择商品,提交订单,形成订单信息。

主动型列表和被动型列表虽然都是列表页,但是由于其内容的来源不同,所以在设定其产品逻辑方面有很大不同。

2 列表页设计原则

列表页有以下几条设计原则。实际上说原则也并不准确,因为产品设计并没有一个既定的标准,而是这些方法论是由行业前驱提出,并且经过了相关产品、市场的重重考验,被证明了是行之有效的。

第一条:**根据场景提供展示的业务列。**

第二条:**产品新数据行能够便捷地看到。**

第三条:**操作宜少不宜多。**

上面的几条原则可能比较抽象,难以理解,下面我来详细讲解。

3 列表页设计技巧

3.1 列表页构成元素

我们先来看看一个完整的列表页有哪些元素,主体是列表,包含一些对列表的操作,以及搜索。我们重点说明「列表」部分。

第一行为字段名,不出意外一般是:序号、业务列、操作。序号没什么好说的,就是一个1、2、3…的展示,用途只是用于辅助「行」的显示,无任何的业务逻辑和附加含义。业务列是列表的主要部分,操作指的是对该一行的数据的操作,常见的有:编辑、删除等等。

主动型列表还有「新增行」操作(对应不同业务名称都不同,例如商品列表页就是「新增商品」),一般被动型列表无「新增行」操作。

3.2 业务列

业务列中需要展示哪些元素呢?单行记录可能包含多个数据,哪些需要放上去,哪些不需要放上去,哪些需要显示但是只需要再深一层显示,怎么判定?

依据就是上述设计原则的第一条——根据场景提供展示的业务列。首先你需要定义这个页面的用途是什么,根据设定的用途去展示相应的元素,同时更重要的是,要了解用户真正需要的是什么。需要展示什么内容,不是看我们有什么,而是看用户需要什么。还是以「商品列表页」为例,这个页面的用途就是管理商品的(实际上这个页面本身就叫「商品管理」页),后台新增、编辑商品,前台展示,供用户购买。一个商品包含以下元素:商品名称、商品描述、库存、价格、展示图、规格、详情介绍等,显示这些内容是很难全部都放到列表页的「业务列」中的,那如何取舍呢?我们将这个列表页的用途定位为:辅助用户快速找到对应的商品,进行编辑或其他操作。如果是这个定位的话,那么只要一个商品名称就可以了。

实际上,在业务列中呈现的元素不仅仅是「商品名称」,我们这里再引入一个新的概念:主要元素和补充元素(辅助元素)。在这里「商品名称」就是主要元素,主要元素和补充元素的区别是即使只保留主要元素,也不影响这个页面功能的实现。在「商品管理页」中常见的补充元素还有:封面图——辅助通过看图直接找到对应商品,价格,销量(被动产生数据),库存等。

我们在设计页面时,一定要确定「主」和「次」,不要一锅粥的全往上挤。一定要克服一种「代码思维」,这种思维的典型想法就是「这个数据我的数据库有存,可能也有用户想要看,为什么不放上去?」,回答还是「定位」!

我们再来讲讲「订单列表页」,一般名称也叫「订单管理页」。(可能很多读者会疑惑,这些列表页为什么在取名的时候都不带列表的,关于后台功能菜单的取名,可以看我的这篇文章《后台菜单命名小技巧》)在设置业务列的时候,第一步还是明确这个页面的定义和用途,想想用户在什么时候会用到这个页面,再简单讲,思考「在什么情况下,用户出于什么目的会主动打开这个页面」,这个就是找准「用途」的技巧。用途无非就是下面这些:

(1)和买家协商一致,去后台改价。

(2)看看有什么新订单,然后去操作发货。

(3)退款操作

明确了用途,之后再把对应的业务列往上放就可以了。

关于「页面用途」,这里再讲几句,说说很多新手很容易犯的错误,就是「想太多」。会去思考「万一用户不小心点到这个页面,突然想看某个数据,看不到怎么办?」又或者是「如果我们把这个数据也放上去,这样如果有用户想看,就可以看了」。错误太多,很多很有趣,后面再整一期讲讲这些常见的「想当然」的想法吧。

还需要特别注意的是,我们将「用户需要什么」的时候,这里的「用户」不是指具体的某个人,而是一群人,准确的讲,是带「占比数」的一群人,例如90%的用户倾向于A方案,10%的用户倾向于B方案,而A和B方案只能二选一的情况下,我们只能选择A方案,而不是说只要存在一个用户需要某个功能,我们就必须往上做。

3.3 默认列表顺序

默认排列顺序算是一个不算重点的重点,一是因为它重要,非常重要,二是这个技巧特别简单,几乎不需要深入思考。原则中第二条:「产品新数据行能够便捷地看到。」讲的就是这里的默认列表顺序。那么什么是列表顺序呢?

列表一行一条数据,总是需要一个明确的规则去确定它的排列顺序,而不是随机的,哪条记录排在前面,哪条记录排在后面,都是需要制定一定的规则的。那么怎样才能让「产品新数据能够便捷地看到」呢?技巧就是根据所在列表的新数据放在第一,越新的数据排在越前面。再结合「主动型列表」和「被动型列表」的特征这个技巧还需要一定的优化升级。我们结合具体例子讲解。

商品列表页,这是典型的主动型列表,所有的数据行都是用管理员用户主动生成的。首先第一条是毫无争议的,新增的商品默认排在第一行。还有一个方面是,编辑保存的商品,也是需要从后往前拉的。否则排在后几页的商品,编辑后就没有任何变化。所以将两者组合,默认列表排序规则就是「商品保存时间降序排列」(保存不区分新增还是编辑)。

很多人可能会想到,商品在前台的展示顺序问题,所以引入「手动排序的序号」概念,这其实是完全多余的,前台商品的排序最好和后台排序脱轨,遵循一套排序规则后期维护会非常麻烦。(这一点之后的文章会细讲)

订单列表页,这是典型的被动型列表,所有的数据都是由终端用户生成的。所以默认排序规则很简单,就是「生成订单的时间降序」排列。

还有一个算是小难点,还是以「订单列表页」举例,订单有多种状态,我们会在订单列表页设立标签栏快捷查询,那么如何制定各标签栏的默认排列顺序呢?其实还是遵循一样的道理,就是进入该标签栏的时间降序。例如订单的状态有「未支付」、「已支付」、「已发货」、「已完成」等等。未支付状态指的是,订单已生成,但是用户未付款,那么该标签栏下列表的默认排列顺序就是「生成订单的时间降序」。已支付状态指的是,用户已经付款,但是商家还没有发货,那么该标签栏下列表的默认排列顺序就是「付款时间降序」。已发货状态指的是商家完成发货,那么该标签栏下列表的默认排列顺序就是「发货时间降序」。已完成状态指的是用户手动确认收货或者系统自动确认收货,那么该标签栏下列表的默认排列顺序就是「确认收货时间降序」。

简单来说,只要记住一点就没问题了,先进来的排后面,后进来的排前面。

3.4 辅助排列顺序

默认排列顺序和辅助排列顺序的区别是,默认就是直接进入该页面,不需要进行任何操作就直接展示的,辅助排列顺序是需要用户手动操作,变更排列顺序,辅助排列顺序一般设定在特定业务列上,点击可变更按此规则降序或升序排列。设定辅助排列顺序的技巧和前面提到的「业务列」一样,还是明确页面定义和用途,这里不赘述了。例如商品列表页常见的辅助排列顺序有按销量、库存、价格排列等。

3.5 操作

常见的操作有:编辑、排序、删除等等。根据不同业务功能的列表页,操作区按钮区别很大。下面讲讲几个常见的功能。

3.5.1 编辑

对于主动型列表,很多人会不由自主地加上「编辑」操作,很大程度上这是没错的,但是仔细思考,这里真的需要「编辑」吗?

编辑操作实际上一条便捷操作,除了保留原有数据外,相当于删除原有记录,再新增内容和原来一样,再修改内容,省去了前两步。多数列表存在编辑是没问题的,但是一些会产生很多跟该条记录强绑定关系的列表,最好编辑和删除两个功能都不要有。还是以电商为例,遇到节日或者其他活动,一般会进行促销打折活动,后台「活动列表页」会新增一条活动信息,如果这个活动关联很多数据,那么就需要保证这条记录是不动的,一旦编辑或删除,原纪录不在了,牵一发而动全身,会引发太多麻烦。这时候就不要问「用户只是想把上次那个活动再改一下弄个新活动,还要新增多麻烦啊,编辑改一下多方便啊,这样不行吗?有个用户就强烈需要。」这种傻问题了。

3.5.2 排序

有些业务逻辑非常简单的内容,前后台的展示顺序是一致的,这时候就需要排序功能,前后台同步变动。

3.5.3 删除

删除操作是一个比较敏感的操作,如果不是特别必要,尽量不要放删除功能。

3.5.4 搜索

是否需要搜索功能,是根据预期产生的数据行数决定了,如果在30条以内,则尽量别上,30条以上酌情上。

4 总结

列表页知识点就讲到这里了,基本只要掌握了这些技巧,设计一些常规的列表页已经是没有问题了,如果遇到业务逻辑更加复杂的情况,再根据情况判定,但是万变不离其宗,规则就是那么几条。这里再总结一下:

业务列:要克服「代码思维」,放什么内容,不是看我们有什么,而是用户需要什么。

默认排列顺序:先来的排后面,后来的排前面。

操作:宜少不宜多,有需要才往上放。

其实,你只需用好这六个字,就可以在微信中称王

本文转载自公众号见实

裂变带来的低成本、快速获客这件事,可以说是小程序及背后的微信生态最吸引创业者的能力。随着创业者不断地尝试、微信不断地调整,越来越多东西被逐渐明确,是时候做第一层的梳理了。

比如,想要大裂变,理解和用好这“六”个字就好,**它们是:拼、帮、砍、送、比、换,见实称之为“裂变六字诀”**。

这些字背后是什么意思?为什么它们能带来大裂变?我们可以详细展开看看。

第一个字是**“拼”,拼单的拼**,拼多多的拼。用户可以呼朋引伴,一起拼一件更低价格的商品。

关于拼多多的事情大家听了很多,其实还有很多创业团队用这个字取得很好的效果。如见实前段时间和连咖啡CMO聊,他说连咖啡在做的过程中,和用好“拼”字有很大的关联。

前不久上市的猫眼,他们的增长团队也花了很长时间把拼多多所有的裂变策略全部梳理下来,做成一张非常完整的表格,发现拼多多在每一个环节都设计有裂变的能力,做了很多借鉴,他们的用户增长也很快。过去这段时间,“拼”这个字已经在行业中爆发了巨大的威力。

第二个字是**“帮”。帮忙的帮,帮助的帮,用户在体验产品的过程中需要帮助随时向好友求助。**

游戏早期运用这个字很多。如全球最大社交游戏公司Zynga,入华时与腾讯谈判,正好是我带着团队在对接、测试、运营,上了大量的案例。Zynga做的一切事情都在围绕一个点,即鼓励用户和他的好友发生关系,比如求助,当玩家在一个游戏中进行不下去或希望提速,可以请好友帮忙,让自己快速过关。

**“帮”这个字背后是互惠**,也可以增进双方的友谊。在小程序的很多产品中,同样对这一点有着大量的应用。

第三个字是**“砍”。砍价的砍。这个字细琢磨和“帮”有些类似,常见场景是大家帮我砍个价格。**

这个字用得好的也是拼多多,砍价这个动作天生有很强的利益驱动,并且更易在好友间形成扩散。前段时间流传着一个笑话,说一对情侣分手了,男孩放狠话说我下次来找你的时候,一定是出人头地、让你后悔的;结果三天不到,男孩就给女孩发来消息说:**“亲你在吗?帮我砍一下拼多多”。**

第四个字**是“送”。送礼的送。用户送给好友一些继续或者利益。**

刚刚提到连咖啡,最近一直两杯咖啡很火,另一杯就是瑞幸咖啡,他们将“送”这个字用到了极致。用户进来之后,只要邀请一个朋友进来就会得到一杯咖啡,而如果送新人一杯咖啡,用户自己也会免费得到一杯——**买一赠一,赠一得一**。帮助他们发展很快,前不久腾讯还主动和他们达成了战略合作。

这个字背后另一个有名的产品是微信读书,读书市场非常难做,微信读书能够在高端人群中迅速拉升,凭借的就是“送”这个字。一本书用户可以送给某个好友,对方免费得一本,自己也可以免费得一本,依旧是买一赠一,赠一得一。

第五个字是**“比”,比较的比,比拼的比。**

腾讯大部分产品都有排行榜功能,**或者引导用户之间进行PK**,如曾经风靡微信的打飞机,和刚提到的微信读书,还有微信运动,都有比较和PK功能,引起小程序高潮的跳一跳也是如此。

第六个字是**“换”。交换的换,互换的换。**

今年二手市场的崛起非常快,见实之前也连续报道了很多做二手换物的公司,“换”的需求非常强烈。现在估值最贵的小程序团队享物说,实际上就是“换”,名片类小程序同样是在用“换”的力量,人与人之间互换名片、互换信息等,能够很快将人们关系向前推进一步。因此名片这条赛道,曾有一千多家团队竞争,有一家拿到了高达1.68亿的投资,就是加推。

之前业界梳理出了前五个字。**前几天鉴锋群发了一篇文章,也梳理了几个字,大部分相同,不一样的是三个“换”、“积”、“赚”。**后面两个字也拉动了步数换礼品之类的小程序,也非常火。不过,“见实”不认为“积”和“赚”在裂变的字之中。

我们回顾整个互联网发展时,会发现所有今天成熟的巨头,都可以找到一个字来形容他们。比如百度是“找”,寻找的找,因为他是搜索;阿里是“抢”,即抢购。双11许多商品需要抢购才能买到。腾讯则就是这个“比”字,好友之间互相比较比拼。

当世界从PC时代进入移动和社交时代后,其他两个字都没能进入,唯独“比”字,这不仅仅是因为腾讯,而是因为上述的“拼”“帮”“砍”“送”“换”,加上“比”,都是基于关系,他们的特点是:

**1、都是基于好友之间的关系;**

**2、都是动词,用以增强好友间互动和关系亲密度;**

这是为什么“积”和“赚”不在其中的原因,因为他们可以独立完成,不需要关系,也就没有裂变性。

**还会有哪些字能够发挥巨大作用?**

顺着刚才特点去看,发现会有更多。一是在微博尚未崛起之前,当年开心农场、QQ农场风靡一时的偷菜游戏,就是好友之间互相“偷”、抢车位和朋友买卖也是类似,都是通过好友之间戏谑在增强互动。因此,在这些字之外,关于如何推进关系互动仍然有巨大的潜力可挖。因此,围绕关系的增强,我们还能发现个提炼更多的字,每一个新的字的提炼和运用,都有可能带来巨大的裂变风暴,成就新的独角兽。

**但怎么提炼,会找到最有价值的新的字?**

在畅销书《小群效应》中,我们会看到推动大扩散大裂变的六大驱动力,也就是社交的六大驱动:利益驱动、事件驱动、兴趣驱动、荣誉驱动、关系驱动,地域驱动。

刚才提及的裂变六字诀,其实仅仅用到了三个驱动。分别是:利益驱动、荣誉驱动、关系驱动。这些驱动互相组合成就了这六个带有裂变能力的字。还有三大驱动还在沉默,没有被提炼出来。

我们可以断言:

**如果能找到每一个新驱动力或他们之间的组合背后对应的新“字”,就会形成新的大爆发。成就新的独角兽。**

然而,**用好“裂变六字诀”,就可以安枕无忧?答案还不是**。大部分团队都会碰到一个问题:分享疲倦。简单说,用户不爱分享了。这对依赖分享才能实现裂变、增长的微信生态中创业者来说,几乎意味着增长消失,甚至可能在快速下降。

怎么办?这就涉及到接下来要聊的话题。近期约聊“见实”的创业团队中,大都在关心留存和变现。也就是“新三级火箭”。

首先,“三级火箭”不是新词。例如360曾用免费杀毒软件、浏览器等获得大量用户,用大量服务巩固,最后导引到电商和游戏等高收入的产品中去变现。这就是三级火箭。

但过去的三级火箭的背景实际上建立在漏斗运营模型下,一层层实现转化,大家做的都是优化工作,而社交中是扩散模型,很少的用户就可以带来巨大裂变效果,本质上不同。**今天的新三级火箭中,裂变、留存、变现,三个实际上是一体的,他们构成了最稳固的社交基础模型。**

在这个模型中,做好裂变才仅仅完成了新三级火箭的其中一级,即病毒性。还需要借助工具性来实际解决刚需问题,借助长连接来促进持续的复购活跃。

只是,讨论这些问题的基础都不一样了。在社交环境中,几乎大部分需求都被充沛供应,用户想要的东西,随便一搜都有几百上千一模一样的小程序或账号在提供。因此,在用户什么都不缺的环境下,他的痛点和刚需会是什么?还是很受考验的。

不过,让我们略过那些专业而拗口的分析——如果你有兴趣,“见实”可以后续深度撰文展开或在演讲中展开,其实今天这篇文章,就是近期在几个演讲中深度展开过好几次。如在昨天的36氪大会上,见实围绕这个主题进行了50分钟重度分享。现在只说思考吧:

**能够帮助用户增强关系的玩法,实际上就是强刚需。**

这和裂变六字诀成立的背景实际上是一致的,当我们了解这些,再去看游戏会有一些启发。之前我们去拜访《征途》团队,他们后台的数据非常震撼,几乎每一个部门都说到一点:他们在网游最没落的2015、2016年,上了家族制、小组制、夫妻制等亲密关系玩法,结果大部分忠实玩家自己买飞机票,跑到各个城市,把原来的玩家叫回来,收入迅速回升,从低迷时的几亿上升到十几亿,就是亲密关系带来的变现和增长。这些游戏厂商非常坚定,不单单是在做网络游戏,而是在做亲密关系。

回到前面说到的新三级火箭模型,最早是各种病毒性的玩法打穿了互联网,但随着这部分需求被满足,变得不稀奇的时候,亲密关系缔结下的目标任务会打穿下一个红利时代。要么缔结更好的关系,要么用好已有的关系,通过你的产品和服务,让他觉得和你休戚相关。

因此,当前环境对创业团队的考验是,能否利用好已有的裂变方式,甚至寻找到新的裂变力量。与此同时,还要借助社群运营的理念,不断在用户、产品之间缔结社交关系,去维系持续稳定的留存,才能将增长落到实处。

**顺便说一句,今天下午,见实在组一个沙龙,主题就是“裂变六字诀”,邀请了几个团队分别围绕其中一个字展开深度分享。**

你要考虑下沉用户啊!3个月获600万用户的小心得

本文转载自公众号见实
小影是一款短视频制作神器,也是知名的短视频社区,在全球拥有 5.5 亿用户。在传统印象里,制作视频是一个非常复杂的过程,借助APP,小影已经将这个过程压缩得非常简单。现在他们更进一步,用小程序进一步将视频制作的门槛拉低,并在短短 3 个月内吸引到近 600 万新用户。

与见实报道过的她Face+、黑咔等团队类似,小影在小程序端提供的功能也走了极简路线,以匹配平台特征和增量用户的实际需求。不太一样的是,小影是已在 App端取得过巨大成功的产品,拥有初创团队不具备的先验优势,尽管他们切入小程序的时间点相对晚,但谋定后动的结果是增速稳定,产品路径也十分清晰。**(小编注:本周四见实大神局沙龙,要不要一起?)**

现在,小影在小程序端的用户新增每天超 10 万,主要以三四线城市、超过40岁的用户为主。这个用户画像和原有用户有着巨大差异,也体现出了微信小程序的特点。新增用户的来源仍是分享本身,在小影,每2个用户中就会有1人分享,分享率达到50%。这是很多产品不具备的超高特性。是工具本身带来的优点?还是怎么做到的?

见实和小影创始人韩晟长聊了下这个问题。一起:

 

**如下,****Enjoy****:**

小影

**见实:****小程序在你们的产品布局中,处于一个什么样的位置?**

**韩晟:**小程序的用户生命周期和 App不一样, App更偏重留存,而小程序获取用户主要是靠微信群,传播才是核心指标。小程序是我们通过微信生态触达下沉用户一个很好的产品形态。

**见实:****考虑到产品特性,你们的分享数据应该非常不错,有多好?**

**韩晟:**目前制作完的用户分享率在50%左右,也就是每 2 个制作,就会有用户把内容分享给好友。

**见实:****小影的总用户量有多大,小程序现在有多少用户?**

**韩晟:**小影App有5.5亿全球用户,截至 2018 年年初,小影 APP 在 35 个国家 App store 的 图片、视频分类榜排名第一,在 60 个国家 Google Play 的传媒、视频分类榜排名第一。

小影小程序累计用户已经突破500万接近600万。

**见实:****目前的增长怎么样?怎么做到的?**

**韩晟:**小程序每天新增用户超10万,我们每天的视频制作量最近也超过了10万。视频制作量和新增用户是相辅相成的,目前的视频制作量由于我们丰富的模版数量、优质的质量,用户喜欢做, 而且做完愿意分享,而分享又为我们带来了新的用户、新的制作、新的分享。

**见实:****怎么理解微信生态中的传播?**

**韩晟:**小程序在微信生态里,微信提供了很好的传播渠道,我们获取用户主要是靠微信群,传播是核心指标。但是传播我们不是靠红包刺激或者其他和产品核心无关的,我们关注产品本身,让产品有传播属性,根据这个目标去做产品迭代和运营。

**见实:****小影在小程序端的主要人群画像是什么?你们针对这些洞察做了哪些工作?**

**韩晟:**以三四线城市、超过40岁的用户为主,女性偏多。而小影App在国内的用户则大多都是25岁以下的年轻人。

在app端我们提供了专业的视频剪辑工具,而在小程序端我们要降低用户的使用门槛,增加他们的乐趣。更多是提供视频模版的形式,让用户可以快速生成视频,且这个视频是好玩的,可以给用户提供乐趣的。

**见实:****小影的小程序是什么时候上线的,负责这个产品的团队是什么结构?**

**韩晟:**8月底上线,团队基本控制在10人以内,主要以技术为主。

**见实:****你们在小程序端核心提供什么功能?现有的模板中,哪一类是最受欢迎的?**

**韩晟:**我们希望帮助用户产生表达自己或者值得分享的视频,现有模板中以场景类的早安,晚安最受欢迎,点击率和制作率都是一般素材的3倍以上,还有就是祈福、祝福类、提醒类的模版,比如天冷加衣、问候群友等。一个好的模版,可能会有上万人使用,这上万人又会给带来数万新用户。

图:祝福类模板在这里更受欢迎

**见实:****从上线到现在,你们在小程序端进行了哪些重要迭代,这个过程是怎样的?**

**韩晟:**做了两个大的迭代,第一次是设计思维迭代,从 App设计思维到小程序设计思维,像 App关注更多的是留存,所以小程序刚做时我们也关注留存,但是这个生态又不可能达到 App那样的留存,后面会更多关注分享,产品和运营也会跟着相应做转变。

第二次是用户思维迭代,向下沉用户思维靠拢,简化视频的制作流程。我们的团队会做调研、分析数据,越来越了解下沉用户,发现他们更需要的是简单直接,连文案都要直白。这是两次大的转变吧,转变好思维,事情做起来就比较顺。

**见实:****经历过哪些试错的过程,给你们带来哪些新的理解?**

**韩晟:**整个团队对小程序的理解和对我们用户的理解也是不断变化的。我们的试错大到理念,例如注重视频质量还是简化生成方法的讨论,小到文案的简化纠正都是有的。

举个例子,我们在制作流程中,做过一次相对失败的改版,将制作流程复杂化相应出来的效果也有提升,但是导致了数据的下降。后来在调研中,我们了解到,对于复杂的流程,下沉用户反馈用不懂,他们更关注的是,如何快速看到效果。所以我们需要做平衡,而不是从自己的角度出发,要多熟悉下沉用户的使用习惯。

**见实:****现阶段你们如何做增长?**

**韩晟:**我们的驱动增长是多元化的,运营驱动支持用户喜欢的素材类型,去找更多素材的场景,比如节日场景的素材。

产品驱动增加分享动力和支持更多素材玩法。数据上我们会做a/b Test和详细的数据监控、分析,为增长做服务,比如我们在用户制作后的分享标题已经做了几十版的测试,刺激新用户的点击。

**见实:****如何获取收入?**

**韩晟:**目前还不焦虑做变现,更多的还是先把产品做好,服务好用户,几年前 App也很难变现,但是现在大家都不疑虑 App的变现了。App时代的经验在小程序也不一定有用,先做好产品吧,变现是水到渠成的一件事。

**见实:****小程序端上线后,对你们 App 的增长有什么影响?**

**韩晟:**对 App的增长不是我们做小程序的初衷,我们更多的还是希望服务好下沉用户,前面也提到了用户画像差别较大,没有必要让微信生态的用户一定要转到 App端,这个迁移成本还是很高的。

**见实:****你们还做了一些其他的矩阵产品,出于什么考虑,之间有什么样的联系?**

**韩晟:**主要是基于垂直场景做下沉用户的尝试,小程序的开发成本相对来说较低,试错成本较小,在 App时代,「小影音乐相册」和「天天拍一拍」可能会做在一个App里。

但在小程序时代,还是适合做成多个独立的小程序。每个小程序去解决一个特定的需求。毕竟用户打开这个小程序是为了满足特定场景的需求。如果在一个小程序里面做太多其它功能没有意义。矩阵小程序之间可以通过互相跳转来导流。

当然,我们是社区团购第一!月流水早已过亿

本文转载自公众号见实

现在如火如荼的社区团购大战,最早起自长沙,最火时一度达到200多家。到现在,一个小区内有7、8个创业团队在拼抢都很常见。这股热潮最终卷入资本,不完全统计,仅今年11月就至少有5家团购宣告完成新融资,金额全部在千万美元级别,有的甚至过亿。

如果资本不是问题,那么竞争的核心会在哪里?或者说,左右胜局的关键点会在哪里?这些社区拼团团队会像过去的“千团大战”那样,最后只剩下美团一家独大吗?

这些问题都在不断撩拨着我们的好奇。其实还有更多好玩的问题,比如,为什么所有的社区团购都以水果切入?

正好,见实约到“你我您”联合创始人刘振洋深聊——这个团队也是发源于长沙,今天在社区拼团这个市场中是必然提及的对象之一。早在2011年,“你我您”早期团队就开始在QQ群卖水果,2017年3月,年净利润达到1000万,目前已在全国布局20多个城市,1万多个小区,月销售额过亿,其中单月突破1000万的城市就有5个。他认为,“你我您”是行业第一。

刘振洋之前就职腾讯、京东,并在腾讯系投资机构微光创投投过每日优鲜、每日一淘、有好东西等。因此,我们的话题侧重在社区团购下一步跃升空间,及真正的核心壁垒是什么?刘振洋认为,伴随着资本的入场加持,明年行业会有一个大洗牌。这意味着,对核心壁垒理解越透,未来成就的空间越大。

那么,他们是怎么看待这个市场的?

如下,Enjoy:

图:你我您联合创始人 刘振洋

社区团购为什么是今天爆发

从2011年开始,“你我您”就围绕水果直采在QQ群、天涯论坛、微博等等渠道做团购,直到2016年才正式确立了现在社区团购的运作模式。

后来很多同行开始借鉴我们的模式,坦白说这个行业的进入门槛比较低,几十个群加上一批供应链资源,就可能区域性地把小区服务做的非常好。这也是为什么长沙曾经有200多家社区团购公司,全国最多。

 

社区团购的集中爆发我觉得有几个原因。

 

首先,集团化的管理解决了最后一公里的成本,中间所有可能去掉的成本都去掉了,没有店租,没有太多人工,整个商业模型的成本结构允许低毛利和高性价比的商品进入,同时高周转的形式也帮助社区团购在水果生鲜品类上可以很快做大做强。

 

第二,小程序的出现,确实进一步推动了社区团购的进程。

 

之前因为没有系统支撑,每天推送的商品比较少,只有一两款,多了很难做到信息有效处理。而且团长也需要花大量时间解答用户各种各样的问题,经常要24小时维护群。

 

小程序带来了标准高效的解决方式,可以承载商品信息、下单购买、物流进展包括售后体验等等功能。团长从大量的基础工作中释放,花更多精力维护客群,推荐商品,最终为规模化奠定了基础。

 

第三,优秀的团队开始全国性拓展,资本的涌入也助推了赛道的成长。

 

这里面小程序只是其中一个基础设施的技术因素,还有很多其它的宏观因素。

 

可能从有小区开始,就有了在小区做团购这件事。比如某个业主刚好有一批家乡特产,在小区群里招呼团购,大家也都知道一起买东西会便宜。只不过以前社区团购的路径过于分散,过于非标准。每个人能够接触的供应链非常有限,能够支撑的服务也非常有限,所以一直是一个小而分散的市场。

 

随着你我您和其他同行一起发现了社区团购的流量价值之后,大家开始小规模集约化的管理,分散的市场出现了整合的机会。所以从宏观上来讲有一个发展的历程,从分散到小规模集约化,再到资本进入出现全国性的整合机会。

 

再往深度想,以生鲜为例,最近几年农业种植的标准化一直在提升,干线物流、储存方式、相关配套基础设施也非常成熟,供应链响应速度提升了好几倍。同时配合消费升级,大家也希望买到一些高品质、差异化的好水果。几个因素叠加,让生鲜在全国范围内得以高效率、高周转的调配,最终出现一个明显的爆发。

 

社区团购真正的门槛在哪

社区团购行业准入门槛低,核心壁垒在于规模化之后的管理运作。

 

首先,如果是一个或者几个城市,供应链的组织方式是点到点,从基地直接运到城市仓库,相对比较简单。规模化之后,全国可能有几万、几十万个小区,这时候就近采购和跨区域调拨的逻辑变得非常复杂,需要强大的供应链搭建和管理调配能力。

 

第二,城市密度足够高了,不同模式之间的效率也会不一样。小区少单量不大,无论怎么配送时间都可以保障。但如果有上千个小区,每个点位都有几百单,分检和配送的难度就非常大。

 

第三,规模起来后供货商越来越多,货端管理要求也会越来越难。如果一天卖1吨水果,用人检的方式就能解决品控,但今天有10吨、100吨的水果要在你的渠道销售,怎么做好品控是一个很难逾越的障碍。

 

第四,在团长端,每个人都是非标准化。全国有几十万个团长需要管理,不可能完全通过人力手段搭建好。

 

所有这些门槛都非常关键。

 

无论是区域性的还是全国性的对手,很多时候都是自己做死的。比如商品出现假货或者严重次品,就可能导致一个企业瞬间坍塌。

 

所以我们一直很关注后端的投入,供应链、品控体系、仓储物流,包括对团长的管理培训方式也在不断升级,如果把问题放在最后的交货环节解决,出现的问题就会非常大,而且规模越大,问题就会越多。

 

保证商品品质和平台服务的稳定,这样用户长时间跟你我您建立起来的购买关系,可以进而形成很强的信任和依赖,这才是真正安身立命的一点。

 

所以这几年我们每天都是如履薄冰,细心做好每一个细节,细节就是竞争力。甚至,水果采购已经分散在全国各个生产基地的源头,我们能知道每个月份什么水果更好卖,哪一个基地哪一片果园甚至哪一棵树的果子最好。采摘和抽检都有严格标准。

 

而且为了能够最短时间内把商品从基地送到用户手上,我们会提前开卖。货品还在途中,商品已经开卖,这样既可以保证时效,也可以规避我们自己想冲订单对品质上的影响。

 

即便售卖出去的产品,只要用户觉得不满意想退货,我们随时给他退掉,保证用户售后不会出现任何障碍。对一些品牌性的商品或者标品,我们甚至打出假一赔十的承诺。

社区团购的跃升空间

跃升空间包括横向市场、纵向产品两个维度。开拓新市场最大的挑战,在于不同省份的用户购买习惯会有较大差异。

 

比如广东吃东西喜好清淡,而在成都、重庆、长沙可能是另外一种商品纬度,所以口味本身就有很明显的差异。

 

不同区域用户的可支配收入也不太一样,沿海消费升级比较明显,主要是高单价高品质的商品。西北、西南经济相对欠发达,商品就要多打折。就连品牌偏好,不同的省份也有非常大差异,同样是纸巾,广东用维达,四川就喜欢别的。

 

所以,覆盖跨省份市场,既要有标准化的流程支撑,又要同时具备本地团队的本地化运作能力,只有这样才能真正把一个市场打下来。

 

具体到一个小区时,我们是和团长共同去开拓用户,毕竟团长在小区里认识的人有限,不能保证一定把群拉满。小区根本上还是一种弱社交,大家并没有真正熟到彼此都有微信。

 

一般我们会先发传单、发信息,吸引有意向团长。再邀请大家到公司试吃试用,快速了解商品服务,让大家尽放心签约。

 

签约之后,我们会配合团长举办试吃试用的小型活动,做引流物料,在小区里做传播和裂变。一般1个群到100个人才会开团,之后团长会有一个考核,三个月之内销售额要达到一个量级,否则会被新团长替换。

 

所以,我们是公司控群,群不是团长私有的。团长跟用户建立关系,提高用户的购买转化,这是肯定的。但对用户而言,他真正的需求是买到高性价比、高品质的商品,关心自己的购买体验,这才是最核心的因素。

 

团长其实也会纠结这个群是由谁来建,但归根结底还是收入的考量。所以我们在运转过程中,非常关心团长层级的利益价值,尽可能标准化、流程化支撑他,让他的生意变得简单。

 

社区团购本质上是一个流量生意,以前聚焦卖水果,是因为水果是一个高频、收益足够高、试错成本非常低的品类。通过水果,可以低成本让用户完成首单,培育大家的长期购买行为和信任,这时候再扩张品类就会更顺理成章。

 

现在你我您的用户以女性为主,30岁到49岁占到60%,宝妈群体居多,用户复购率非常高。行业水平大概一个老用户月购买频次不低于6次,新用户半个月1、2次,像你我您新用户大约是3次,老用户是9次。

 

从长远来看,社区团购未来的可持续性和响应速度非常大。无论是货架式的品类还是虚拟服务类的商品都可以有很好的转化。比如我们曾经1个小时卖出100万金额的体检卡。同样教育类、家政服务、空调、抽油烟机清洗服务等产品的转化率也非常高。

 

所以只要把流量获取和管理的能力建立,后续什么都可以做。但早期在战略选择上一定是即兴的,先从水果切入,逐渐做商超场景品类扩张,再到百货公司和线上电商场景,逐渐覆盖全部需求。

 

明年会大洗牌 

有些团长已经开始自发线下建门店,我们负责输出统一的装修标准,目前有100多家,马上官方也要开几个更标准的样板店。

 

团长带着客流开店,所以从开店第一天,他就有足够的收入把握,这样开店的动力非常强。基于销售预期,未来可能逐渐演变出自己囤货卖货的模式。

 

实体店反向做线上团购的逻辑本质上和我们不同。他首先需要把店开到周边区域,把区域的渗透率做起来。但传统零售有一个最大的问题,就是门店需要相应的服务落地,涉及选址、装修、请人,开门店的效率没有纯线上的方式快。

反向做线上团购可能在核心城市比较强,但从全国来看没有哪家公司能覆盖这么大的市场,做不到每个区县都有自己的门店,这个负重太重。

 

另外传统零售其实存在一个左右手互搏的矛盾,因为实体店的价格体系相对固定,如果社区团购的价格比本地还低,这个店就开不下去。

 

到家业务虽然会降低库存,提高单店周转率和流量渗透率,但并不会降低成本,因为到家业务及时性强,人工成本费用会很大。而二三四线城市用户的时间成本非常低,所以在下沉市场打“快”这个点,不一定能真的切中要害。

其实我们有很多机会可以跟传统零售合作,比如说切割生鲜猪肉常常因人而异,需要和行业里优秀的人员合作,把他的商品和服务嫁接到你我您 的程序上,再通过我们落地服务。

 

未来的竞争态势应该是一个两极分化的格局,短期看,又会出现两三个寡头,同时在当地又存在一些小团队运作。寡头规模越来越大,会把小团队慢慢收编。

现在,整个行业布局的人已经很多了,资本也在不断涌入站队,我觉得今年都加持好之后,明年会有一个明显洗牌。

产品设计的多和少:如何找到灵活性和易用性之间的平衡点

本文转载自公众号一鸣说 作者一鸣 十二赞产品经理
摘要:本文阐述了什么是产品的「灵活性」和「易用性」以及相关的产品设计原则。

1 前言

在设计功能模块的时候,产品经理经常需要思考的一个问题是:「这个功能是否需要有用户自定义的部分,以及哪些内容开放给用户进行自定义。」这是什么意思呢?一般来讲,我们确定了功能及流程之后,很多内容都会「固化」,而有些内容会开放给用户进行「自定义」。哪些内容进行固化,哪些可以进行自定义,这是一个很大的命题,也是本文探讨的重点。

2 用户满意度

在开始讨论这个命题之前,我们先引入一个概念,即「用户满意度」。为什么先要提到用户满意度呢,因为这是后面判断那种方案更可行的依据。产品无论是新增功能还是减少功能,无非都是为了「取悦用户」,让用户「用得爽」。能够解决用户的问题,让用户用得爽的产品就是好产品,而不是功能多的才叫好产品。

2.1 什么是「用户满意度」

我们在互联网产品中提到的提升「用户满意度」和服务业中提到的提升「顾客满意度」的策略并不相同,在服务业中,我们可以因人而异,给每个人提供不同的服务,让所有人都满意。但是互联网产品却很难做到,一旦确定了产品的方案,必然有一部分满意,一部分人不满意,我们没有办法做到给每一个用户设计一款单独的产品,因此我们能做的是,确定的产品形态能够让尽可能多的用户满意。用户满意度中的「用户」,不是确定的某一个用户,而是所有用户的总和,这是一个泛概念。

2.2 如何计算用户满意度

尽管「用户」并不是明确的某个人,但是实际上这里说的「用户满意度」是一个所有用户「满意度」的一个平均数。例如可以采取十分制的策略(0分为很不满意,10分为很满意。)或百分制,所有用户给产品或产品中的某个功能打个分,计算得分的平均数,就是我们所说的「用户满意度」。

上面提到的计算策略是一个比较直观的办法,但是实际上,这几乎不可能做到,原因是:(1)邀请所有的用户打分几乎是一个不可能完成的大工程。(2)每设计一个新功能就让用户打分,过于频繁,会引起用户反感。

因此,我们需要一个策略来估算「用户满意度」,用户之间有共性和个性,我们可以对用户进行分类,用类别来表示具有同一个特征某一类用户。

3 用户分类

我们在产品设计之初,就会制定「产品定位」,以及与之相伴的「用户定位」,在toB类产品中,根据与「用户定位」的契合度,我们将用户分类为:头部用户、中部用户和长尾用户。

3.1 头部用户

「头部用户」是最与用户定位最为契合的一部分用户,他们有明确的产品使用目标,清楚地明白他们使用产品是为了解决他们存在的什么问题,他们是产品使用的「熟手」,使用产品过程中几乎不会遇到障碍。其中部分用户可能还会积极反馈使用中遇到的问题以及改进建议,是对产品良性发展具有比较大价值的一类用户。一般头部用户所占用户比例大概在总用户数的10%左右。

3.2 中部用户

「中部用户」是所占比例最大的一类用户,一般占比在80%左右。中部用户一般基本符合产品的用户定位,基本会使用产品,偶尔会遇到障碍,有些能够自己解决,有些需要在帮助下解决。

3.3 长尾用户

「长尾用户」是最让产品经理头疼的一类用户。前两类的头部用户、中部用户都有自己的共同点,长尾用户指的是剩下的几乎找不到共同点的10%的用户的集合。如果不加注意,产品的节奏很容易被长尾用户带偏。他们可能不是我们的目标用户,但是由于某些原因发现产品的某一个功能,刚好能够解决他们的某一个问题,于是着手使用产品。这一类用户的特点就是经常会说:「如果你们的产品再加个XX功能,我就会用你们的产品了。」比如说找到一个博客系统,告诉产品经理,如果你们的博客系统支持多个用户发言,我就用了。实际上,他是需要一个论坛系统。遇到这种情况,如果不加以区分,真的很容易被带偏节奏,需要产品经理拥有老到的需求挖掘能力,才能分析其中的伪需求。

3.4 补充说明

实际上,用户分类远没有上面说的这么简单,这里只是粗略地进行了分类,目的是辅助文章进行说明。由于用户分类不是本文的重点,所以仅做简单介绍,如需详细了解用户分类的知识,请关注后续文章。

4 什么是产品的「灵活性」?

产品的「多」,指的是产品具有对用户具有更高的灵活性,用户具有更高的「自由度」,能够满足更加复杂多变的需求场景。我举一个例子,依然以「商城系统」为例。

4.1 需求场景的多样化

以商城系统最为基础的「商品模块」中的商品展示策略为例,我们知道商品有个「上架」和「下架」功能,简单讲,上架就是可以买,下架了就是不能买,但是你知道这个功能背后对应的需求场景吗?实际上,涉及的环节包含了以下三个环节:

(1)商品列表页是否展示该商品。

(2)能否进入商品详情页。

(3)能否对该商品加入购物车或购买(下单)操作。

经过一定的用户调研,会发现仅仅就这个环节就存在以下需求:

(1)商品在列表页展示,图标显示不能买,无法点击进入商品详情页。(相当于商品预告)

(2)商品在列表页展示,可以进入商品详情页,可以加入购物车,但是不能下单。

(3)商品不在列表页展示,只能通过分享链接进入商品详情页。

(4)有的商品要去掉「立即购买」按钮,只能加入购物车再进行结算。

(5)有的商品不能「加入购物车」,只能立即购买。

(6)商品详情页只能通过列表页进入,通过分享链接进入商品详情页无效。

…………

4.2 场景剖析

仅仅这最常见、最普通的三个环节,就存在着几乎数不清的用户需求,我们经过分析,如果要满足以上用户需求,至少要设立以下几个开关:

(1)商品是否在商品列表页展示。(Y/N)

(2)能否通过通过商品列表页跳转商品详情页。(Y/N)

(3)能否进入商品详情页。(Y/N)

(4)能否通过分享方式进入商品详情页。(Y/N)

(5)是否存在「立即购买」按钮(功能)。(Y/N)

(6)是否存在「加入购物车」按钮(功能)。(Y/N)

(7)商品能否被下单。(Y/N)

4.3 灵活性

只要我们在产品逻辑中加入这7个开关,并且开放给用户设置,就可以满足所有的用户需求,支持他们特定的需求场景。功能的灵活性指的是能够满足尽可能多的需求场景。很显然,如果我们需要这个功能模块具备最大的灵活性,这7个开关一个都不能少,少了任何一个便会使其中的某些需求场景得不到支持。增强产品的灵活性很简答,就是「加开关」,增加用户可自定义的内容。

5 什么是产品的「易用性」?

「易用性」指的是尽可能大地降低用户实现特定产品目标的「操作成本」,这里的操作成本不仅包含手动去点击鼠标和敲打键盘等真实操作,还包含了用户的思考和理解成本。易用性的极致是用户不需要进行任何操作,我们直接提供用户想要的东西。用户体验原则中有一条很重要的原则就是:「不要让用户思考」,一个需要用户深思熟虑做出决策的功能,就是一个易用性、用户体验极差的功能。

提升易用性的办法是减少用户的思考和操作。最佳策略就是产品经理摸透用户心理,直接给他想要的。当然这是不可能的,理由上面已经给出了,用户是一群人,不是一个人。

5.1 用户期望

我们考虑一个功能设计的易用性的标杆是「用户期望」。达到甚至超出用户期望,这是易用性的标准。我们在进行某项操作前,心里都会做出一个简单的预估,「我需要进行怎么样的操作,最后达到什么样的结果」,这就是「期望」。我们举一个简单的例子,来阐述用户期望。

我们去吃火锅,我们的期望是「跟服务员点单,然后服务员把指定的产品呈递上来」,超出期望指的是「服务员告诉你,是不是照老样子来一份,你回答可以。」或者告诉你「今天做活动,所有餐品只要5折」等等。

在产品中,要超出用户的期望,方法无非是根据用户的期望,要么减少操作成本,要么增强操作结果。也就是上面举的那两个情况。

6 灵活性和易用性的平衡点

根据以上的定义,「灵活性」和「易用性」是天然的对立。如果用户是一个人,那么就很好做到这两者的统一,因为一个人的需求是明确的,即使会变,变化完之后也是一个确定的结果。一群人的需求也是明确的,一半人喜欢按钮是方的,一半人喜欢按钮是圆的。但是以上的两种「明确」并不是一回事。

面对需求以及需求场景的多样性,让用户自行自定义是一个很好的策略,但是我们为什么不这么做呢?

6.1 高「灵活性」的缺陷

我们继续使用「吃火锅」这个例子,你的期望是「点个菜,然后服务员把菜送上来」,结果服务员告诉您,你必须先告知你的星座、年龄、性别、家庭住址、工作才能点餐,你会骂这家店神经病,我就吃个火锅,还要这么麻烦,即便火锅店的用意是通过这些信息给你提供个性化的服务。

高灵活性的缺陷在于增加不需要特定需求场景的用户的思考和理解成本,造成用户体验的低下。这是不可避免的,用户心理:「我不想搞这么复杂的东西,你非要我弄,你说我烦不烦?」

6.2 找到平衡点的策略

为了便于讨论,我们将这个模型简单化处理,用户的选择进行两极化处理。

先来看一个极端情况,我们在无法满足所有用户的情况下,采取A方案会让99%的用户满意,但是剩下的1%的用户会不满意同时会放弃使用产品。采取B方案会让1%的用户满意,但是剩余的99%的用户会很不满意,同时放弃使用产品。如果你作为产品经理,你会选择采取A方案还是B方案?答案很明显,我就不赘述了。

然而以上这个例子太极端了,我们一般会遇见的问题是以下这个:采取A方案会让99%的用户满意,但是剩下的1%的用户会不满意同时会放弃使用产品。采取B方案会让1%的用户满意,但是剩余的99%的用户会不满意(仅仅感觉不爽,但是不会放弃使用产品)。我们再把这个比例网中间移,最后你会发现,很难得到这么果断的答案,但是确定的一点是,作为产品经理,你必须选择其中一个方案。

前面提到了,加开关(增加可自定义部分)会让产品能够满足更加复杂多变的需求场景,但是增加了不需要这部分需求场景的用户的思考和理解成本;不加这些开关,则会让产品无法支持这部分需求场景。我们如何取舍呢?我们可以使用「用户满意度」作为判断标准,去判定哪种策略更为合适。

6.3 计算用户满意度

计算用户满意度的初始策略是:所有的用户打个分,然后求平均数。我们也提到了这种做法不可行。那我们有什么更好的办法吗?那就是前面提到的,将用户进行分类,方便分析用户特点,去模拟用户进行打分。

例如某个功能当前三类用户均打分80分,因此用户满意度为80分。一些用户提到了想加一个A功能,这些用户分类为长尾用户,人数并不多,功能也非通用性功能,只是加个开关,提升产品的灵活性,此时我们就需要评估是否需要加这个功能?

头部用户不需要这个开关,但是加上开关不影响头部用户使用,只是觉得加个无关因素显得产品不专业,因此打分由80分变为79分。

中部用户因为这个功能加了个新开关,需要更多的思考和操作成本,增加了出错几率,觉得很不爽,因此打分由80分变更为70分。

长尾用户由于加了新的开关,满足了他的个性化需求,匹配了新的需求场景,因此很开心,因此打分由80分变更为90分。

我们统计新的用户满意度 = 79 x 10% + 70 x 80% + 90 x 10% = 72.9 分,加上这个新功能会降低用户满意度,因此这个功能属于负分项,属于「做了白做且不讨好」的功能。一般通过对用户满意度的核算,产品经理就可以对一个新功能做一个简单的判断,这个功能对于用户来说是加分项还是减分项。

当然以上是一个简化模型的案例,真是场景会更为复杂,但是基本思路是一致的。

我们进行总结,无论一个产品还是功能,评估用户满意度,一般有以下几个步骤:

(1)将用户进行分类,明确各类用户的特征。

(2)按照用户特征站在用户角度思考,做出各类用户的评分。

(3)对评分求平均值。

7 产品设计原则和技巧

实际上,我们如果对每一个新功能都做一次评估,这将会成为一个很大的工程。这里我总结了一些产品设计的原则和技巧,按照这些思路进行设计,一般可以直接到达灵活性和易用性之间的平衡点。

7.1 抓住主场景,放弃个性化场景

对于商城系统来说,买东西卖东西才是主场景。当然对于说在买家买东西的时候,听首歌,促进交易,这个需求场景也是存在的,但是我们要不要给商家做这个功能呢?按照「抓住主场景」的原则进行设计,可以很方便地避开很多烦恼,作为产品经理一定要记住一句话:「既然无法满足所有用户,那就去满足绝大多数的用户,如果为了满足小部分用户而去得罪大部分的用户,这就得不偿失了。」

7.2 如无必要,勿增实体

这句话来源于奥卡姆剃刀原则,这句话的意思是:「不要用更多的东西去做较少东西就能做到的事情」。每增加一个元素,就会增加用户的思考成本。缩短用户操作流程的路径,如果用户问某个东西要怎么操作,最好是「这个地方点一下就好了」而不是「先这样,再那样,最后再这样就可以了」。

一个没有用的按钮,为什么还要放在页面上呢?

转载自公众号:1鸣说。作者:一鸣十二赞产品经理。

我们知道,在做页面设计的时候,最重要的就是确定「页面元素」。哪些元素需要放在页面上,哪些元素不需要放在页面上,这些都是需要深思熟虑的。这一节我们来讲讲页面元素中比较特殊的一类元素——无效元素。

那么什么是「无效元素」呢?一般来说,对于推进页面流程没有任何帮助的元素,均属于无效元素。比如说有一个按钮,点击之后发现其实是无效的,或者说该展示内容的地方实际上是空的等,都属于本文定义的「无效」情况。「无效」指的是不产生作用,对推进页面流程没有任何帮助,即将这个元素完全地去除,也并不会影响页面的正常使用。

「无效」并不是「无用」,很多新人在刚开始做页面设计的时候,很容易想当然地把一些页面中的无效元素删除,简单的思考就是「既然没用,干嘛还把它放上面?」或者是为了页面看起来简洁,而直接把无效元素给去除了。

我们先来看看「无效按钮」。

什么是「无效按钮」呢?例如在点保存的时候,提示不能保存,并告知不能保存的原因。这里的保存按钮就是上述定义中的无效按钮,因为点击保存并没有起到「保存」的作用,并没有使流程往前推进。再例如在点击「选择」的时候,正常的操作是弹窗列表页,从中进行选择,如果如果这个列表页是空的,那么显然无法选择,这个时候这里的「选择」按钮便是无效按钮。简单来讲,所有不能达到「预期效果」的按钮均为无效按钮。

一般情况下,我们应对「无效按钮」有以下4种策略:

(1)策略一:直接隐藏按钮。

(2)策略二:显示按钮但禁用。鼠标悬停提示禁用的原因。

(3)策略三:显示按钮并可操作,点击后弹窗提示不可用的原因。

(4)策略四:显示按钮并可操作,进入新页面(包含弹窗页)提示不可用。

这4种策略的适用场景分别是什么?我们针对电商系统常见的前后台页面逐一说明各自的应对策略。

列表页内容

当列表页的内容为空时,该页面就是「无效页面」,通常来讲,列表页为空属于特殊情形,一般不隐藏,而是在列表页展示内容的区域告知暂无内容。后台部分列表页很常见,采取这种策略的原因是列表页内容为空仅为临时性的特殊情况,非大概率事件,无须对该种情况增加额外判断,同时也可以让用户知晓存在这么一个页面。另外主动性列表页(由用户自行主动产生内容的列表页)一旦隐藏入口将无法进行内容新增。

更准确的讲,实际上列表页内容为空情形属于以上的策略四。一般都是通过点击事件后进入列表页,承载点击事件的按钮便属于以上的策略四,采取策略四的原因一般是:通过点击按钮的下一步操作通常是可用的,便不在这一个环节进行拦截了,用户的预期是这个按钮是可操作的,即便禁用还是会习惯性的去进行点击。

列表页操作按钮

列表页除了展示内容的「业务区」,一般会在行尾放置「操作区」,对每一行的内容进行操作。列表页的操作按钮的主要特点是,按钮都基本一致,因此对于一个不可用按钮直接隐藏会导致按钮区的错位,因此对于每一行的按钮都一样的操作区,采取策略二是不错的选择。实际上策略二和策略三并无区别,除非是需要提醒的内容过多,无法在按钮区承载,则使用消息框提示,否则一般都建议使用策略二。

上面这种是普遍情况,还有一种特殊情况是,对于同一行的元素存在多种状态,每种状态的操作有明显不一样的地方,很难做到统一,如果将所有按钮都进行摆放,都会造成操作区大大冗余,得不偿失。在这种情况下,就采取策略一。将其他状态的按钮进行隐藏。常见的例如订单列表页就采取了这种策略。

编辑页

在编辑页中,我们知道,如果用户填写的内容未达到要求的话,我们是不允许用户进行保存的。这个时候如果用户点击保存,很显然是无效的,这种情况怎么处理呢?一般来说,有两个策略:一是用户没完成一个输入,就对输入区进行检测和判断,如果填写错误,则标红提示错误信息,在用户未完成所有的必填项之前,保存按钮均保持禁用,仅当所有内容均正确输入后才将保存按钮变更为可用。二是在用户输入时不检测,保存按钮始终保持可用,但是点击保存时,提示无法保存的原因。以上两种策略均可用,不过策略一的用户体验会高于策略二。

总归一点,所有的策略都是围绕着「用户预期」来的,都是为了让用户能够少思考,更好地使用,少出错。而不是为了使页面看起来「简洁」而强行「简洁」,否则就是本末倒置了。上面的二三四策略区别并不明显,主要区别在于是否需要隐藏一个不可用的按钮,一个简单的方法就是,如果这个按钮是这个页面是主要元素,那就绝对不要隐藏,否则会造成用户操作中断。一个按钮虽然不能点,但是却给用户提供的明确且有效的信息,而如果直接隐藏了,则这个时候很容易产生困惑,会一直去寻找这个按钮,找不到只会认为是遗漏了而不会认为产品贴心地帮他过滤了无效信息。

基于websocket的简单广播系统

在年初的时候,我们有点儿小迷茫,于是也跟风去做了一些轻娱乐类的小游戏。
那时为了实战对战,想到需要一个实时性很强的技术实现,于是我去实现了一个websocket server,没想到后来这些小程序没有成,但是我们的这个web socket server 演化得无处不在。下面介绍一下这个技术实现。

看理论肯定会有点拗口是不是,我们直接上代码就得了。我们现在假设有这么一个用户付款的逻辑,在写用户付款事件时,我们事先并不知道以后还需要加什么逻辑,于是我们先把这个行为广播出去。以下是伪代码:

    req := httplib.Post("https://ws.app.12zan.net/eventcast/user/5905e89db43fec42e3055df05ff72afe")
    text, er := zanjson.Encode(order)
    if er != nil {  
        log.Println(ev)
        return
    }
    req.Param("data", string(text))
    resp,_ = req.Response()

好了,现在,每当有用户付款时,这个用户系统都会往/eventcast/user/5905e89db43fec42e3055df05ff72afe这个频道广播一条消息。但是很遗憾,目前没有客户端订阅这类消息,所有的消息都被丢弃了。

有一天,我们英明神武的老板决定要加一个通知,每当有一个新的用户付款时,都给公司的同胞们发一个邮件通知一下,我们获得了新的付费用户,好让大家小开心一把,尤其是第一个试用客户付费的时候,我们肯定都要开心地跳起来。这时我们如果去改线上运行好的付款系统,还是有点儿风险的,一旦有修改,我们就得走一下测试流程,不然万一有问题不是影响公司发财了吗。没关系,我们之前不是已经把付款事件广播出来了吗,我们现在用起来。写这么一段js,线上运行起来,就好了。

const webSocket = require('ws');
let ws = new webSocket("wss://ws.app.12zan.net/eventcast/user/5905e89db43fec42e3055df05ff72afe");
ws.on('open', function open() {
    console.log("connected");
});
ws.on('message', function incoming(data) {
    let user = JSON.parse(data);
    Mail.send("一个叫"+user.name+"的好心人支付了"+user.amount+"元,让主赞美他!");
});

好了,现在一旦有人付款,我们全公司都能收到一个邮件,及时得到这一好消息了。让我们小小地庆祝一下吧。

接下来又过了几天,我们想改进一下体验,用户一旦付款成功,就发送一条短信,告知用户他的有效期和我们的24小时客服电话;只需要这么一段代码部署起来运行就好了, 之前的任何代码都不用动:

const webSocket = require('ws');
let ws = new webSocket("wss://ws.app.12zan.net/eventcast/user/5905e89db43fec42e3055df05ff72afe");
ws.on('open', function open() {
    console.log("connected");
});
ws.on('message', function incoming(data) {
    let user = JSON.parse(data);
    let expiresAt = (zan.Date.now().add("+365 day").format("YYYY-mm-dd"));
    SMS.send(user.Mobile,"尊敬的"+user.name+",您成功购买了十二赞旗舰版,有效期至"+expiresAt+",请登陆:https://www.12zan.cn 查看,如有任何疑问,欢迎致电4006681102");
});

发送通知邮件和发送告知短信,都基于用户付款动作,但是发邮件和发短信的代码完全隔离,相互之间出完全不知道对方的存在。

是不是很赞?那我们接下来梳理一下逻辑。

概念及主要逻辑

也许我们来不及去翻看websocket的定义,但是我们可以简单地理解,Websocket是对HTTP协议的一个扩展升级,在发起连接时,HTTP部分都是有效的,只是连接成功以后,服务端和客户端的连接不断,双方可以双向数据传输,且服务端可以主动向客户端推送数据。

我们看一次Websocket发起连接的过程(来自维基百科):

客户端向服务端发起连接:

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
Sec-WebSocket-Version: 13

服务端的返回:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Location: ws://example.com/

在HTTP协议中常见的字段,如Cookies,Host等,依然有效。

但是具体到我们的应用上,十二赞的这个websocket server实现了两个小目标【多遗憾了,并没有赚到两个亿】:
1. 我们实现的是一个广播系统,一个广播系统意味着一个地方去发送数据,n多个接受端来接受数据。要支持非常多的客户端同时连上数据来实时接受数据。我们最终的server端的实现,全内存实现,没有用redis或是MySQL类似的数据库,就是为了实现超多客户端的支持。
2. 我们希望采用最简单、最通用的文案,并且,非常高效,支持非常多的客户端同时连接,我们认为http协议更简单,所以在发送的时候,我们是走http协议来发送数据的。并且,没有任何安全上的设计,如果数据很重要,请自行加密之后发送。

当然我们也有一些遗憾:
1. 允许数据丢失。有得必有失,我们允许一个比例的信息丢失。产生数据丢失时,不影响主逻辑。就像刚才的例子,发送邮件通知我们有新付款的这个事件没有触发并没有关系,我们到下午才发现有新用户付款,这时再去开香槟也不迟:(。
2. 容忍时序错乱。像刚才的例子,有新用户付款时,是先告诉我们全体同事有新付款,还是先给用户发送一条短信,并不那么重要。

好了,回到我们的系统,我们给一点点总结。

我们定义,每个websocket的入口,都是一个URL;去掉协议和HOST部分,剩下的PATH部分代表了不同的频道。比如,发起websocket时连接到ws://ws.app.12zan.net/channel/hello,那么这个频道地址就是/channel/hello;所有连接到ws.app.12zan.net/channel/hello的websocket客户端,他们会收到一模一样的消息,我们称之为订阅。

同时,为了简化发起数据的过程,我们还在websocket server中定义:当一个http 的客户端,以POST方式请求某一个地址时,我们截取URL中的PATH部分,得到频道名,并取POST的数据中的data域,作为要广播的数据,将之广播到相应的频道。

在十二赞的应用:

这个广播系统,在十二赞的整个技术架构中,后来应用的特别广。
比如,我们的部署系统zeus,在网页端实现了一个客户端,当服务端有应用重启、关闭、启动时,都会弹出消息通知。任何在打开了这个系统的网页的人都能看到。比如我和同事小王都正在zeus的网页上,我新建了一个search系统的一个节点,启动完毕的时候,我和小王会收到通知,在第三号服务器上新启了一个search系统的节点。我在操作,很关心这个,所心这时我可以放心去继续我的工作。小王正要在三号机器上新部署一个系统,他收到这个通知后,觉得这个机器可能会很忙,于是把自己的新实例部署在了四号机器上。

再比如,我们的日志服务器,担负着收集所有服务器上日志的使命。但是如果它挂掉了呢?于是我们在这个日志服务器上跑了一个定时器,每5秒钟向某个频道广播一条心跳消息,告诉世界自己还活着。然后另行跑了一个进程,收听这个频道的广播,如果连续30秒没有收到这个心跳包,证明这个日志服务器挂掉了,就发一条报警短信,通知同学去看看这个服务。

再比如,我们在日志服务上的应用,参见这里:十二赞日志系统简介

十二赞的商品搜索实现

其实要说很惭愧,虽然我是搜索出身人士,但是十二赞的搜索功能其实在目前是做得非常弱鸡的。不过还是介绍一下这个弱鸡的系统。

十二赞的搜索是基于elasticsearch的。因为业务量较小,所以,到目前为止,还没有用上elasticsearch强大可怕的集群功能。之所以觉得可以拿出来分享一下,是因为这个文案的投入是比较小的,效果尚可接受。

对于在小程序上开店的商家来说,一般商品数不多,很少于超过200的,所以在召加回率和精度上,我们只需要满足召回率就行了。即便搜索结果不够精准,因为商品少,用户一眼扫一下也能找到他想要的商品,搜索只是帮他从原有的上百个商品中把范围缩小到十分之一,就已经很有效了。
另外,也是因为团队小,我们的方案也特别注重精简,能不自己去写代码实现的,就不自己去写代码实现。

好了,上方案。
我们的商品数据是存在MySQL数据库中的,就用的阿里云的RDS。我们运行了一个go-mysql-elasticsearch,这个程序启动时会运行一次mysql_dump,把数据导出进入elasticsearch,然后接下来就会作为MySQL的一个slave,不断地读取MySQL的binlog,同步进elastichsearch。跟我们其他的服务一样,我们把这个elasticsearch和go-mysql-elasticsearch也封装进了一个docker 之中,只对外暴露9200端口来提供服务。

我们之前的ppt介绍过,十二赞的各种内部业务都已经微服务化,这个elasticsearch的服务,也不例外,它工作在es-sec.z.12zan.net:3000上,后端的实例可以有多个es的实例,通过http接口来请求elastichsearch的http接口时,网关 server会自动定向到负载最低的elasticsearch实例来提供服务。

这个方案运行不久,我们就发现一个问题,当我们的MySQL数据库的商品表新增了字段时,所有的后续的数据更新都无法同步的elasticsearch中去了。因为MySQL表的字段比elasticsearch中的字段多了(字段减少啊变更什么的都会导致这个问题)。

谢天谢地,因为Docker化,我们可以轻而易举地解决这个问题。我们的方案,当MySQL的数据表schema变化时,老的elasticsearch实例不变,继续提供服务,但是有缺陷,因为新增的数据没有同步进来;同时,我们新启一个Docker实例,这个实例启动约1分钟之后就同步进来了所有的商品数据,这时是两个elasticsearch的实例都在es-sec.z.12zan.net:3000上对外提供http接口服务,其中一个的数据是老的,一个实例的数据是全的。这时候我们关掉老的Docker上的实例就好了,就实现了索引的切换。用户可能会感受到新商品没有马上在搜索结果里体现,感觉搜索里的商品更新有延迟,但是基本上发现这个延迟的概率很小。

其实,淘宝的搜索的索引切换也有这么一个过程,不过要复杂的多,每天夜里要生成一个全量的索引,切换掉前一天的索引;然后另外有一个实时的搜索引擎,数据全放在内存里,只同步当天的数据变更,对外提供服务的接口将两份数据合并。

十二赞日志收集与报警系统简介

先快速介绍一下十二赞的日志收集系统:十二赞的日志收集系统,分为两块,一块是线上系统的各种报错、异常的日志收集,主要是各种线上代码运行期间产生,我们称之为log-collect,一块是用户行为操作的日志收集,主要是由各个业务系统根据用户的行为来上报,比如用户A访问了xx页面,用户B收藏了某某商品等,我们称之为eventdb。

基于这两块的日志收集,我们实现了一些自己非常自豪的特性。比如,基于log-collect,我们做到了能够主动去发现问题,抢在大多数客户发现异常之前,就把问题处理掉,从而做到不断地提高Saas系统的可用率和稳定性;基于eventdb,我们能做到非常完善的行为收集,将我们的返利模块、分销模块的准确度、实时性大幅度提高。

下面我们介绍一下系统的架构。

从需求上,我们认为log-collect是为了及时发现问题,并马上解决掉。但是这些日志,在我们解决掉问题之后,是不需要再保留这个日志的。比如,举个例子,用户注册的时候,可能输了一个12012345678的号码,这个号码是不对的,导致我们的验证短信发不出去,短信模块就会报错。我们的log-collect会收集到这条报错日志,马上告警。开发同学收到告警通知时,就马上去处理这个问题,用户输入120这个号段时,提示用户该号段是不被支持的,以后就再也不需要处理这个了,因为这条告警日志,我们是不存的,只存档15天就丢弃掉。

但是对于eventdb,我们的目标是为了对这些数据做分析,这些行为一般会跟财务相关,比如用户A通过用户B分享的链接进到了系统,5分钟之后有户A购买了商品付款了200元,2天后用户A退掉了其中的80元。这些数据,会影响到商家给用户B结算cps款项。类似这些数据,我们是永久存储的,不会抛弃。同时,这类数据,我们是要在保证准确性的基础上不断提高实时性的。所以对这类数据,我们有两条线来处理,一条是在线实时,一条是离线的一个小时跑一次数据的。

log-Collect

基于这种差异,我们在架构上也有不同。下面是log-collect的架构图:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/48370500.8048.png

我们每一台服务端机器上都有一个live tail,实时监控日志文件,一旦日志文件有新的写入,就立刻发送到http的一个日志网关。这个网关就立刻把这条件日志推送给一个广播服务器,并写入到一个数据库(数据库会清掉7天之前的数据。)这个数据丢给广播服务器了之后,会在特定的频道进行广播。我写了一些客户端,订阅广播,根据日志内容的不同,将日志发给倍洽上不同的告警频道。(关于bearychat/中文名倍洽,大家可以自行去其官网上了解)。手机上装了倍洽,就可以随时接受告警通知了:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/82177300.jpeg

eventDB

下图是eventDB的架构图:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/87788400.6795.png

与log-collect相同的,收到新的行为事件后,网关也会在一个特定的频道进行广播。不同的有两点,一点是另一条链路先把行为事件写入到阿里云的oss存储起来,然后写了crontab每小时、每天定期从oss文件里导入到eventDB这个数据库;另一点是广播客户端工作的事情也变成了实时写入到eventDB这个数据库。

在事件收集上,也不一样,log-collect是在所有的服务器上部署了LiveTail来从日志文件中读取,而eventDB是需要各个业务系统自己向日志网关来汇报事件的。

存入数据库之后,后续就是再对这些数据进行分析,查找用户的来源渠道,计算佣金等等操作了。

 

由「根据用户手机壳颜色变换APP皮肤主题」说起

转载自公众号:1鸣说。作者:一鸣十二赞产品经理。

前几天的某互联网公司产品经理和程序员打架事件引起热议,据传原因是产品经理提了需求,要求APP程序员可以做到根据用户的手机壳颜色来改变软件主题颜色。这个原因当然是假的,只是用老梗来增加趣味。同时网上了引起了一轮新的讨论,程序员吐槽遇到的「奇葩需求」。

实际上,就这个需求本身,并不是十分荒诞。

我先把结论放在前面:这个过程中,最大的问题是产品经理和程序员之间的沟通不畅。

在这个需求真实存在的情况下,我们可以大致来模拟一下整个需求的流程。

第一步:用户反馈提出,APP的主题颜色太单一了,像QQ有那么多的主题皮肤,希望这款APP也能多弄点好看的皮肤,最好能弄一款和自己手机壳颜色一样的的皮肤就更好了。

第二步:产品经理经过一定范围的用户调研,确认了需求确实存在,有非常多的用户确实希望能够让APP皮肤颜色和自己的手机壳一致。

第三步:产品经理确认了该需求,同时出于为了方便用户的考虑(让用户少操作的角度),提出需求「根据用户手机壳颜色变换APP皮肤主题」

第四步:程序员只关注到需求的前半句,「根据手机壳颜色」,认为自动识别手机壳颜色做不到,直接驳回需求。

第五步:产品经理认为「变更APP皮肤主题」是一件非常容易的事情,两者引发争议。

你能看出问题出在哪里吗?这个问题在绝大多数的互联网公司中经常出现,就是产品经理和开发团队之间的沟通不畅导致的信息不对称。这个需求的核心是,也就是产品需求的最终结果是什么?是「皮肤颜色和手机壳颜色一致」。整个需求流程有两步,第一步:获取手机壳颜色。第二步:将皮肤颜色变更为该颜色。在这个过程中,程序员认为第一步是重点,而实际上,重点是第二步。程序员认为自动识别手机壳颜色做不到,所以一直纠结在这个点。然而第一步的这个过程,换个方式完全不影响整个需求本身。

在传递需求过程中,最忌讳的双方不愿意沟通了。以下是我希望的沟通流程:

产品经理:这里有个需求,是「根据用户手机壳颜色变换APP皮肤主题」。

程序员:我总结这个需求可以分成两步,第一步:我们的APP自动识别手机壳颜色。第二步:将皮肤颜色设置为这个颜色。是吗?

产品经理:是滴。

程序员:这个需求第二步比较容易做到,至于第一步,有点困难……

产品经理:哪里困难?

程序员:自动识别手机壳颜色做不到,这个技术我们不具备。

产品经理:没事,这个是小问题,我们换个方式获取手机壳颜色就好了。

程序员:怎么获取手机壳颜色?这个无论怎么想,都是很困难啊。

产品经理:哈哈,你想复杂了,我们让用户自动输入就好了呀。

程序员:还能这样,我真没想到。

产品经理:所以在第一步获取用户手机壳颜色的环节,最好的方案当然是自动获取啦,这个做不到换个方案,让用户输入也是不错滴。这个需求核心是让皮肤颜色和手机壳颜色一致,至于怎么获取手机壳颜色,这是个小问题,关系不大。

程序员:明白了,那我们怎么做。

产品经理:这个简单,在用户打开APP的时候,让用户输入自己的手机壳颜色,然后确认后自动变换皮肤颜色。

程序员:明白了,这就开始做。

最差的沟通方式就是:

产品经理:这里有个需求,是「根据用户手机壳颜色变换APP皮肤主题」。

程序员:SB,滚粗。

这个问题在知乎上讨论的热火朝天,实际上打错了靶子。一方面是产品经理不够专业,另一方面是程序员关注错了重点,不具备产品思维同时拒绝沟通导致的误解。

一般比较有经验的程序员面对需求时,会问明白,这个需求的「产品目标」是什么?产品目标才是核心,不要纠结于产品经理的提出的怎么实现这个产品目标的过程,这个过程是完全可以协商的,对于产品目标而言是次要的。

这一次讨论就到这里了,晚安。