抛开抄袭和八卦，我从「立知」学习到的产品思路

从产品体验来看，避免了资讯聚合类产品的软肋——请求外链时，体验会相对较差。上文中也提到，因为涉及到鉴权、请求三方服务器、页面布局和渲染等问题，这种类型的内容聚合方式，会一定程度的产品体验劣势。立知的产品结构层，尽量让用户停留在第二层，让其能在第二层就完成对资讯内容的基本了解。

而即刻的规则，是让用户在尽量短的路径阅读到原文，所以基本上时从列表点击就可以跳转外链，有些内容，甚至只有一个标题，用户仅是想个大概，却要忍受请求外链时较长的耗时。

5. 更新频率

在持续使用即刻一年之后，发现即刻的更新量并不能满足我(这种情况持续半年了但我仍然在叹气的同时死忠??)：我订阅了 88 个主题，粗略估算本周，每日的主题总更新量大概是 18 条，更新率20%;这样来看下拉 4 到 5 屏就可以拉完当日内容，而我平均每日要打开即刻2～ 3 次，这样的更新量远不能满足。

为了补充阅读，我会在推荐和发现中，去发现新的主题和有趣的用户，但由于用户的主动关注特性、即刻的主题颗粒度特性，并不能将订阅-更新-阅读带入优良的循环中，反而会迷失在找主题、吃瓜看即友评论这样比较脱离资讯阅读路径的方向。

所以持续用下来，我还是不得不搭配 1 个新闻客户端和即刻一起使用。大家是否和我有相同的体验?

另外，由于即刻的社交方向，资讯内容中参杂着不少广场的信息和吃瓜评论，无形中对用户是一种干扰——获取信息场景是需要高效的、目的性强的，但切换到社交的场景却是低效、无目的的，甚至是打发时间的一种方式。两种场景的切换无非对用户是一种压力。

6. 以 24 小时作为时间节点，注重新闻的时效性

每个类目下的内容推荐不超过 30 条;这样设计的目的，的确降低了大量同质性资讯、时效性较低的资讯的出现，依然是让人感觉轻松+高效的。

可以说这是作为一种推荐方式存在，只是以日为单位的阅读习惯，对应的就是跨日、跨月、甚至跨年的信息流，随着时间的累积，整个内容信息框架和交互要如何设计，也是下一步需要思考的。

另外，主题和内容是否容易重复，让用户减少订阅的动机;内容的更新频率是否跟得上这些都是值得考虑的。

都说c端产品看的是产品灵魂，的确不同的产品会聚集不同类型的用户，推荐算法的逻辑也是可以根据用户的喜好度进行调整的。没有永远的头条，也没有不变的即刻，总的来说，我对立知还是存有一点小期待的。

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

题图来源于网络

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!