在移动端互联网为主战场上的现在,PC端的产品发现越来越被用户忘记、与企业所看重。由于正在负责的产品是web端形态的社区产品,发现优秀的互联网社区社区好案例越来越少。
在国内,内容聚集顶部的产品:知乎是今天剖析的主角。围绕自己在设计社区产品中,发现有一些社区产品还真的不是只把内容做好就可以赢。面向用户C端的产品,你必须要考虑好交互体验与内容效率问题。
社区产品最重要的是打造一个舒服、有效率、流程的阅读体验与内容产生体验。社区产品核心的变现方式:大多以广告营收占比大部分,许多社区70%甚至是更高。因此产品经理既要考虑广告的转化数据、又要考虑广告是否干扰用户的浏览视线、社区内容广告占比等问题。
总之如果是产品新人面对社区产品第一眼可能认为社区产品就是要靠内容! 内容为王,产品什么的都见鬼去吧!实际上真正在落地期间,其实并不容易。
社区产品核心的用户停留时间页面之一,内容详情页。我把整个详情页的布局拆解如下
可以看到内容区域是内容详情页的用户阅读目标。但上面几个区域的整体结构组合后,是用户对社区体验认知的核心几要素。
不同位置的操作区域代表了用户不同的目的。比如底部通常是评论、回答等内容输入口。操作区域1、操作区域2是针对本次内容的操作。
关联内容1、关联内容2 一定会尽可能的减少影响用户的主视觉。当用户对内容的产生感到兴趣后,会自然的去浏览关联内容。让用户路径停留在【内容区域】中。
首先在社区中存在的button,围绕数据类型会有不同的文案。比如话题、用户的关注、广告或入口button的点击、评论、分享的入口。
关注问题回答后,直接以按钮区分状态(深色、浅色)。并且鼠标在按钮上的hover也要给予对应的相应。在CSS上针对交互分类可以识别:未访问的链接、 已访问的链接、 鼠标移动到链接上、 选定的链接4类效果。
对内容载入的等待时间,选择合适的交互动画过渡是有效的方式。如知乎中点击评论因为内容在折叠中,拉出需要载入时间。通过这类交互避免了用户体验差
还要考虑到页面扩展后的连接性。比如点击评论后,知乎会有下拉弹出,输入框应该默认聚焦在评论框。评论框在失去聚焦后,取消表情包的输入结构。
对于点赞后、评论后按钮中的文案、数字、按钮本身也有对应的变化。可见每一次点击都是触发了其他控件甚至是页面的联动。
在知乎中,随着用户的浏览行为(滑动鼠标滚轮或页面下移)标题会自动的展开,方便用户聚焦在内容本质。提问描述、标题与内容关联起来,用户可以时刻知道自己在看什么。对该内容产生了兴趣,可以直接通过新的交互按钮点击【关注问题】、【写回答】。
在社区中因为内容不同会希望用户聚焦在不同内容的层级上。比如知乎中问题描述、用户的描述都是采取单独的字体和排版。通过这样让内容有层次感,用户也能清楚的知道操作区域。
相比看到知乎的UI规划,我认为一定是在版本中逐渐演化而来的。很难想象一个社区产品在刚开始如何考虑到这每一步的细节。尤其是在屏幕放大后的web端,想办法做到极致的体验需要产品经理人员操作每一个功能入口、按钮、浏览每一种数据类型在各种状态下的结果。
没有内容场景
知乎采取的是以问答内容为沉淀的社区。因此在社区提问没有被回答的时候,如何尽可能的产生回答的欲望、或回答编写的效率。就成了边界值考虑的一环。
在知乎回答场景中,存在的角色分3个。提问者、回答者、游客,3个角色的需求肯定是不同的。围绕这3个角色产品经理从下面考虑
对于提问者应该加入邀请回答的机制、对于回答者应该提供高校的输入编辑器能够支持微信黏贴复制等、对于游客我可以知道相关类似问题。方便解决我的疑惑
有足够的内容场景
社区问答存在过多用户内容后,需要通过算法进行排序。比如评论、点赞等纬度来筛选出优质内容。把低质量内容进行降权,但知乎却还通过交互的方式结合。如下图
知乎通过折叠其他回答(非排名第一),将排名第一的内容展开。当用户浏览后认为内容足够有趣味,用户也会展开查看其他的回答。一个巧妙的折叠交互设计,让回答的优质内容得到足够曝光。
在社区中,用户的每个操作除了用按钮来表示,用toast 也是一种有效的方式。但要注意区分的是什么状态用户toast,什么用按钮。产品经理在梳理toast的时候建议以状态来区分。而不是以场景来区分
状态区分为:
普通提示 、 成功提示 、失败提示、超时提示、异常提示.....
场景区分为:
回答成功、发布成功、评论成功....
以状态区分设计不同的UI后,在落地到场景进行文案的修改即可。这也是一个小技巧。如知乎对于账户的异常提示
好啦,今天的原创就在这里。在社区产品搭建中还有许多坑,我会在后面更新
推荐阅读:
我的原创课程,产品经理8次训练