【闲扯】最近变成即刻的重度用户了，每天都会在上面看东西。细想了一下为什么会用，应该有以下几个原因：

1、产品形态：即刻的目标应该是做成一个内容聚合平台，收罗了网络上各式各样的内容组成专题让用户在同一个地方就能看到不同平台的内容，算是RSS的2.0版本。十分符合现在碎片化的阅读习惯。这样的内容聚合平台其实豌豆荚也在做，但是为什么做不起来，还是要说到下一点：产品设计上。

2、产品设计：其实即刻和豌豆荚一览一样，都是只给摘要和链接，通过内置了浏览器直接打开一个H5页面把内容展示出来的。但是为什么我会更喜欢即刻，是因为即刻的设计布局留白大，整体信息流看起来很清爽，图片也是像微信一样附在文字内容下方，显得信息质量轻盈，让人看起来没有心理负担。反观豌豆荚的设计，因为前置的内容过多，加上产品模块多，显得整个产品非常拥挤，信息量看起来也大，加上H5的转码排版没有做特别好，让人看到内容就有心理负担，觉得要花长时间看。

3、push：push绝对是门学问，即刻的push我觉得是非常准，比微博准多了，基本上推送给我的我大部分会点。等我下次研究一下再表。

4、内容：内容部分采用的是专题的形式，很好地满足长尾效应，也不过分追求内容的量。好奇的是内容团队的压力会不会很大。感觉有空要好好写一写即刻的用户体验报告。

【闲扯】去年下半年，微信的某个版本取消了下拉拍小视频的功能，我是使用这个功能比较高频的用户，一开始不知道他们为什么这么做，15年最后一天下班回家忽然茅塞顿开。

先从微信为什么要做小视频开始说起，其实本质上都是给使用者之间增加话题性的。我拍了小视频，无外乎是分享到朋友圈，或者是发送给朋友，目的都是产生互动性。

下拉这个手势，有利有弊。利处在于降低了启动小视频的门槛，我只要在客户端首页就可以进入了，非常方便。但是有一个很大的问题是，我下拉拍的小视频，是没有目的性的。很可能我只是看到一个非常好笑的狗跑路的样子，拍下来了，暂时保存在微信上，但是我因为流量、时间、思想限制，当时没有发出去，后面我就忘记了我有拍这个视频。

简单来说，下拉启动小视频之后，我可以随时想拍就拍，但是拍了我却不会分享，因为我一开始拍的时候目的就不是分享。

这样非常浪费。

如果微信有打点的话，我相信他打了这几个点：下拉小视频入口、朋友圈小视频入口、聊天界面小视频入口，再配合每天小视屏的发送量，转化率是不高的。

所以他们取消了这个功能。现在要发小视屏，不然就是在聊天界面直接拍完都不需要你确认就发了，或者是通过朋友圈发布按钮进入，这两者都会提高从拍摄到发送的转化率。

我相信微信团队开始做小视频的时候，是希望能够做成语音一样的东西的，如果它的表现不错的话，他们是会把这个功能再放出来的，毕竟带宽和流量以后肯定会越来越好。但是看现在表现来看，藏深了是一点，这个功能没达到他们预期的效果也是一点。

【产品】最近在思考关于社交的内容，有个很武断的概念：社交，尤其是图片社交，本质上都是以“我”为中心的。人们在图片社交APP上会做的事情无外乎是发“我”的照片，回复给“我”的评论，关心“我”的朋友，找和“我”相似的人。所以如果有一款社交APP是完全围绕着“我”来做的，最大地放大“我”的存在感，是不是会有生存空间？

【产品】 在整理之前写的客户端打点统计文档，把数据后台对应的ID补上去，方便以后查看数据。但是坑爹地发现RD打点的功能名称和需求文档的差别太大，导致现在要一个一个去猜或者去确认每个功能对应的是不是这个统计ID。以后在做统计需求的文档的时候，最好还是和RD统一口径，确认一下每个模块叫什么。

【产品】在google play上架前，一定要研究好google的条款政策。google对存储用户邮箱地址这个行为很敏感的，查出来就会被下架。需要在存储用户隐私之前，告知用户，并且让用户可以选择接受或者拒绝。

【产品感受】其实很多时候提到产品就会说用户定位、使用情景。但是我个人很多时候写案子画原型完全是从需求出发，拿到个新的需求，先把满足这个需求的方案写完了，再倒回头来拿着解决方案去对号入座找用户，找产品定位。导致很多时候用户群体大而泛，抓到的需求并不是痛点。虽然说在拿到需求之前，就应该先把目标用户和使用场景想明白了，但是很多现有的产品，自身的目标用户定位都是比较模糊的，这种时候就非常考验产品的sense和说服力了，因为在目标定位模糊的用户群体中圈定的某一部分人作为目标用户，可能因为量级不够，投入产出比太低而被砍掉方案。届时只有两个解决方法，一为说服领导和RD去做这个功能，把故事讲圆，二为接受自己的失败，另寻他法。

【产品】今天一直在纠结用户和需求是哪个先行的问题。虽然说纠结这个就像在纠结先有鸡还是先有蛋，但是总归还是有个先后顺序。我觉得用户比需求更难抓住，因为需求是具象的，但是用户是模糊的，在两个都没有的情况下，需求要比目标用户来得好找。以instagram为例，应该也是先有这个需求『让照片变得漂亮』，然后再来定位用户，如果目标用户是摄影师，那就可以用各种现成的技术手段处理照片，并不需要一款这样的APP，但是对『对摄影不擅长但希望照片好看的普通人』来说，拥有一个一键处理照片的APP是非常需要的。而针对目标用户而言，最好的解决方法就是滤镜。

【产品】今天在写新的产品的各种提示文字，发现其实对待一个产品的文案风格就像写小说要进行人物设定一样，确定好人设，后续的一举一动一字一句才会更加顺理成章。ps，颜文字对拯救平淡无奇的文案有奇效，但是慎用。

【产品】今天和同事讨论到图片社区环境建立的问题，如果以图片处理工具为切入点发展社区的话，其实社区的环境并不太好。一方面对于用户来说，处理图片的目的是在于发布到SNS上，对于工具类的应用只要是功能完成了，并不会做太多的停留。另一方面，即使用户停留在社区了，每个人发的图片关联度并不大，很难产生共同话题，互相之间的沟通大部分只局限于点赞回粉，很难有什么好的关系链沉淀。

所以我觉得，社区还是要从最根本的兴趣起家，让用户之间有更多的共同点可以长时间维系关系并且沉淀下来。

【产品】个人觉得做产品，对一款产品的熟悉程度会影响到你提出的方案的可行性和可复用性。发展到一定规模的产品，本身就会有很多模块化可以复用的东西，对产品熟悉到每一个模块都知其原委和功能，提出的方案的开发成本会小得多，实现起来的困难也就小得多。对一款新产品亦然，对同质的竞品了解够多，才能够知道对方不完善的痛点在哪里，有哪些地方是有机可乘可以被改善发展的。但同样，经验可能会让创新被已知问题捆绑住，如果对需求不够有信心，可能就会因为开发成本过高而否定了需求。

ps:最近感受，抄也是一门学问啊，就算对着一款竞品照抄，也会因为各种无法绕过的槛而抄得四不像，最后摔倒坑里去。

【产品】总结了一下提示文案的写法，能表述清楚问题的格式大概是『表现』+『原因』+『解决方式』，但是因为展示问题，很多时候需要控制文案长度，这个时候就需要调整表述形式，例如：由于『原因』导致『表现』，你可以『解决方式』，这种写法是比较容易控制文案长度的。

【经验】之前APP被Google play下架两次，被封了包名。现在想来已经尝试出了结果。如果在APP里做应用分发，有带第三方分发链接的必须要加上AD的标签，否则对Google来说属于违规。

【产品】刚刚和朋友讨论小说里长篇和短篇的区别，说到短篇对整体的控制力度和逻辑要求比较高，而长篇对直觉、细节把控要求更高。忽然觉得短篇和长篇可以适当对应到一个产品的前期和后期里。产品在前期，更多的是需要有取舍，能够在最短的时间内花最低的代价来达到目的，什么要，什么不要，哪里一语带过即可，哪里需要侧面描写，哪里要花笔墨，都是需要斟酌推敲的。而长期迭代之后，更多的还是需要有对产品的细节把控，哪里需要渲染，哪里需要承启回转，哪里需要有关联，都是要在后期打磨出来的。这样对应一下，还蛮有意思。果然每个领域都有一定程度上的互通，不擅长的，还是不擅长啊。

【感悟】对于一个新的app来说，到底要不要新手引导，新手引导以什么形式展现实在是一个很纠结的事情。曾经做过一个非常复杂的新手引导，复杂到开发葛格都在吐槽，最后索性统统砍掉。后面想说，好的设计应该是不需要引导用户就可以直接上手去用的。但是从教爸妈用电子产品的经历来看，年龄越大，对某些东西越不了解，就越畏惧试错，不敢轻易去尝试，害怕点到什么地方会出现很大的问题。所以我觉得吧，新手引导应该是在不得已的情况下再使用，譬如说针对某些手势做引导，至多出现2个左右是比较友好的，更为重要的是通过突出重点的界面设计和优化提示文案来做余下的核心功能引导。

【碎碎念】整理简历中，想找自己简书的主页url，发现简书的个人主页地址构成非常诡异，http://www.jianshu.com/users/字符ID/latest_articles。

虽然一般的用户不会去看地址是怎么构成的，但是简书网页版的设计，让人在想分享个人主页的时候会一时间不大确定到底哪个才是正确的地址。

比较好的处理方式一是参考新浪微博，用户的主页统一用了http://weibo.com/用户ID，这样的好处在于地址构成非常清晰，用户能够很好地找到规律，也便于日后地址的拓展管理（虽然技术渣不知道现在这种模式以后会有什么问题，但是经验来说，这样的url有优化空间）。

还有一种处理方法是，明确地列出用户的个人主页地址，这样也省去了用户在使用网页版四处找地址的麻烦。