背景说明：这是之前带课的时候给产品新人布置的作业，当时看到很多同学一筹莫展，所以做了一个简单的案例分享，手段不局限于策略或者交互。最近很多之前的同学跟我提到案例很有帮助，所以公开出来给大家围观吧。
- 原始题目：
以下是你们的产品背景
假设你们运营的匿名社交产品已经火了，每天积累了相当大量的中长篇优质资源，这些八卦信息原始数据包括了：消息文本、tag（关于公司、行业、职位、话题）、发布人的随机昵称、时间、照片（可选，最多一张）、点赞人数、评论人数
假设你们有一定的推荐引擎的经验和技术实力，可以利用；
-
假设你们具备足够的运营人员筛选出优质的爆料信息，每天只能保证审核出来40100条优质长爆料发出来；假设重要事件时，可以整理若干条成专题，预期每周产出12个专题
理论上，你们的目标是通过这款产品，满足所有用户没有门槛也看得到这些，另外也希望让用户参与匿名社交产品里贡献更多八卦和参与。
所以，你们需要完成如下任务
a.一个app，平台任选（欢迎全平台兼容），如果选择某一个平台（Android、IOS、H5），设计时请务必标注清楚选择哪款平台
b.这个app有如下基本功能
1）列表模块
列表功能将满足用户概览爆料摘要或专题摘要的需求，参考你的爆料条数和背景，提取合理长度和样式的摘要，注意爆料可能纯文本也可能图文结合，合理制定列表功能；
2）订阅模块
订阅模块将满足用户订阅某个分类下爆料的功能，你的用户可能特别关注某类公司、职业、行业、话题的爆料，利用已有的tag数据，合理设计一个完整的订阅功能；
3）阅读模块
最最重要的功能，需要保证好用户阅读长爆料的体验；
4）其他
考虑你们的任务初衷，做好用户互动模块；
- 任务细节需要注意
1.参考一般新闻客户端竞品，取长补短；
2.参考自己产品本身的定位（匿名、爆料），注意利用自己的特长做出差异点；
3.尤其注意：自己信息渠道可能存在不严谨、料存在争议的问题，需要想办法解决；
4.给你们的产品起个好名字吧。
任务要求：
文档输出：
产品原型文档，输出为一个 PDF 格式的原型＋产品需求文档。建议：
除了一般新闻客户端，还可以参考导购类app（例如什么值得买）、UGC贡献日报类app（例如知乎日报）-
解题思路：
首先，审题。
呃，自己出的题还聊审题有点没诚意，但是我需要坦白的是，出题的时候其实我也没有完全明确自己要做个什么样子的产品出来，所以题目坑爹也算是意料之中。
那么重新审题是为了什么捏？
1.明确任务；
2.明确任务；
3.还是明确任务；回到题目来说，几个大前提还算是交代清楚了，重点如下：
1.有原App输出内容，且由运营团队把关；
2.原匿名社交App部分输出精华有些用户看不到，因为“社交关系未抵达”；
3.UGC贡献内容有风险；以上。
好，开始分析~~
1.产品定位。
产品定位最简单的方法其实就是和各种市面上的典型产品做同异比，一方面要取长以求找到可以借鉴的模式和形态，另一方面也要寻找差异点作为突破口。
开工，首先我们需要拿出一套神器工具——纸和笔。
嗯，我知道你们想象中的使用方法是这样的，
但其实真相是这样的……
乱涂乱画完了，大概收敛一下，基本点就是这样。
懒得敲了，大概就是这么个意思。
这一步的主要意义其实是想搞清楚哪些东西可以借鉴，哪些东西要避免没做到位，举个例子就是比如跟原App的差异在：筛选过、不是熟人的也能看、重点是看，那么我设计功能的时候自然就可以大刀阔府的干掉几个元素：1.屏蔽or拉黑之类的功能可以不需要了；2.社交因素搞走；3.发布去掉。
借鉴元素则可以拿来匿名信息的基本元素使用，比如匿名头像和昵称、评论之类的。
同理可获得其他产品的分析和对比，那么，咳咳结合（假装）做过的用户调研和市场分析（按题设的来）：
用户需求=有集中看全行业猛料的地方（靠不靠谱其次，够猛最重要）
来，继续鬼画符一番…… （我已经不忍心拍照上传丑字了……）
（假装）分析满足用户基本需求的流程，拆解出功能需求的描述和强弱
以上，获得了咱们的功能列表。
根据各种功能点，然后结合使用流程排列组合一番，形成功能模块，再根据合理的使用流程区分层级和从属关系。
总之大概是这么个意思，产出功能列表和使用流程描述，还是意思意思，反正又不是给老板交稿，大家将就看看吧。
<br />
我大概描述一下，实现框的是主流程，虚线是非主流程（直白点说就是没有也不会死），点线的是还不完全确认的流程，至于网格后面的确认环节，咱们稍后再议。
<br />
功能超级简单的对吧~其实第一版本嘛，本来就不需要很复杂，因为咱们要挑重点，经营好一两个点就足够了，要知道产品做加法容易做减法难，起手产品要求精求简求一击必中，不要繁杂的抄一堆，搞的开发团队和用户都压力山大，最后搞黄了也不知道问题到底出在哪里。
<br />
罗嗦完了，back。
功能明确之后，开始搞原型，几个技巧。
<br />
首先，咱们功能层级已经搞的比较清楚了对吧，然后原型要先把框架拆出来单独画，既然说好了是Android的话就不客气直接拿material design里给的标准框架了，那么随便海选两轮
<br />
继续现在纸上随便找找手感（其实……真相是我已经倾向第一个图了，其他的意思意思）
<br />
一般来说我们不建议层级超过三层，除非是某个犄角旮旯死活无所谓的功能，否则对于正常用户来说都太深了，于是我们两层打住，有新需求下个版本再说。基本框架尽可能保证交互一致，这样一方面开发设计成本都可以压缩，另一方面用户的可预期性高很多。
基本框架的海选结果出炉：
基本框架搞定，我们来拆每个层级的内部内容。
重点功能一：概览页，又名列表页。
开画前我们先上柱香，跟我默念一遍：“列表页的价值是为了用户快速浏览，浏览用户进到真正感兴趣的内容里。”
好，动手。
如果你的记忆力好过金鱼的话应该还记得，列表承载的内容是让用户快速概览的，这一点事实上有很多成型案例可以借鉴，所需要注意的只不过是内容不同导致的形态差异。
好滴，梳理下我们要搞哪些形态。
<br />
如题设所说，我们有专题、纯文本八卦、图文八卦三种可选，图文八卦和纯文本八卦属性高度一致，所以索性采用类似的形态，一个加图一个不加图即可，但是这里需要考虑的是我们添加的附属信息，来理一下好了：
时间：必需
日期：必需
评论数：待定
靠谱程度标识：待定
标签/栏目：待确定形态
<br />
于是，我们先把鸡毛蒜皮的排序问题扔到一边，来讨论两个比较迫在眉睫的问题：
1.用什么标记靠谱程度？
2.怎么分类？
<br />
这两个问题显然需要需求分析方法来帮助判定的，当然了，你们知道我比较懒，而且火影都完结了我还没补……不跑题了，用个比较取巧的方式好了。
<br />
逻辑推理！
<br />
骗你们的……其实就是排除法+算算合不合适
先说问题1：匿名社交信息来源不够靠谱的是必然的，别说匿名了，想想微博上谣言四起就知道不管不顾的把消息铺出来最后的下场一定是比CCAV还不靠谱，所以说……咦，我好像有快递到了，双11的物流真是越来越快了，我先去收下快递~
<br />
十年后……
<br /><br /><br /><br />
不闹了，回归正题，编辑审核控制质量的事情是可以做的，但一定不靠谱，因为我干过一件很邪恶的事情就是在知乎上注册了一串马甲，把其中一个捧成某冷门学科专家，然后“学科专家”在某热门题目下发表了一篇很犀利的文章，拽了一堆谷出来的名词和东拼西凑的论文作为论据，其实我对这个学科一窍不通，但是这篇神奇的钓鱼文还是华丽丽的上了知乎日报还骗了好几百个赞（不要找了，为了避免误导大众我已经删掉了）。
<br />
这个故事告诉我们：
1.钓鱼还是挺容易的；
2.每个UGC产品都有可能混进来一些无聊的用户（咦，怎么觉得脸有点痛）。
<br />
所以结论就是：纯编辑控制不可能。
产品层面需要想办法弥补，至少一定能够程度上提供对用户有参考性的功能。
好了我们来脑暴一下。
1.显示赞成数
一般匿名社交都会有，可以作为参考，反正数据是现成的，只是有可能大部分人只是从众，或者赞的是“料猛”而非“真料”。
2.赞成+反对
类似quora和知乎模式，不过quora和知乎都没有提供反对人数，反对数只是作为rank因子和折叠策略影响因素存在，某种程度上，赞成数可以作为一定的参考，毕竟大家都说对的话……不对也快接近对了；只是日报的话rank大概率是纯时间流，这部分的rank因子用不上，而且折叠这种一刀切的事情……标准卡太狠的话容易误伤，卡太松的话没用。
3.辟谣提醒？“有XX个人认为这是假的？”
好像没人这么做过……可以试试……
4.综合以上？搞个“XX人表示我信了，XX人表示这是虾扯蛋”之类的……
<br />
以上分析pk一番（扔了两次硬币），选项4幸存，就这么办了。
逻辑比较简单，就是信&不信比例显示，因为考虑到恶意刷（虽然实际上拦不住）的因素，所以干脆显示比例。
<br />
好，问题一解决，说到哪了……
<br />
问题二，分类。
严格来说其实是做内容归纳，目前普遍的方式有两种
1.分类别；2.打tag。
具体差异很简单，分类别的话基本上是保持一对多，即一个分类下有多个内容，一个内容必然归在某个类别下面；tag则是多对多，一个内容有各种tag，一个tag下也有各种内容；
相比较起来，传统新闻多数是采用分类别的，原因很简单，传统沿袭，有个小伙伴跟我讨论起这个问题的时候说起来：“你绝不觉得，所有的新闻网站骨子里其实还是在学报纸的形态，一版一版。”我脑补了一下，貌似还真是。
当然不只是传统新闻这个调调，传统论坛也是这个形态，一个一个独立板块，想在哪里发帖先得找到对应的版块。
<br />
但是现今比较时髦的UGC平台已经越来越流行打tag的方式，因为tag灵活度高，粒度更细，也更能与时俱进，一篇“怒爆双11首单15分钟送货内幕”的帖子如果用归类目的方式要么粒度太粗，要么不够准确，（想了一圈最多也就是扔互联网=>电子商务什么的），但是打tag的话就自由多了，什么“双11”啦、“天猫”啦、“物流”啦，打个马云都不过分。
<br />
综上，作为一个不赶时髦会死星人我当然毫不犹豫的用tag，这需要理由吗？
当然基本的限制条件还是有的，那就长度限制4~10字符之间，每条最多3个tag好了。话说回来相比较运营需求来说原型需求简直不值得一提，但是因为火影……哦不，篇幅所限，运营需求我先不写了。
<br />
两个功能问题解决，回来继续画原型图。
<br />
基本元素确定好了：时间、评论数、赞成|反对比例、tag
有点需要注意的是，列表页的基本元素排序和形态应该和阅读页高度一致，一样的道理，UI和RD省事，用户好理解，自己也不容易丢三落四。至于排序怎么合适……
排列组合考虑一下边界条件，怎么美观怎么来。
1.时间边界条件： 最短格式XX:XX，最长格式YYYY-MM-DD XX:XX
2.评论数：最短 0 最长4位数字，超过4位截断加单位w，再多的话……再说吧
3.信/不信：走icon显示，既然是比例，可以用定宽icon。
4.tag，输出源可以做长度控制，最短4字符（2个汉字），最长10字符（5个汉字），最多3个tag
<br />
本着
“对齐是美观的第一要素，对不齐的不要凑在一起的原则 ——逗比的chong“这个名言警句
2、3这种定宽的可以和1放在一起做右对齐，4自己单独做左对齐好了
<br />
妥（鬼画符我就不发了哈……直接给结论），两个最简单列表的基本样式敲定，来不要忘记边界条件，最长两行，最少一行，字数超了做截断~
至于“信/不信”为什么这么丑……
交给UI去解决好了。
<br />
看了一下……时间占这么大一坨有这个必要么，万一用户都是神经病，tag全搞成5个字的话岂不是挂了……陷入沉思，其实也是有其他交互形态可以借鉴的，反正框架的延展性还不错，随便做个备选好了。
<br />
看，兼容性好多了，如果还是觉得有点担心“日报”里对天数的区分不够鲜明的话可以学evernote（有高上大的案例不用白不用，他要是告我的话我就又多一条料可以报了）。
<br />
几个方案都比较有意思，留待评审会挑毛病吧。
下面开始考虑专题怎么搞。
<br />
先讨论下专题这个产品形态是什么？
首先，我们透彻思考一下：为什么要有专题？
做了新闻竞品调研的话，应该都知道，专题是为了将一系列时间聚集起来，方便用户持续关注进展的。（我不确定有没有误解啊，但是网易头部那个不是专题，只是头条而已）
<br />
ok，那我们来找一个真实的案例来回顾一下，正常的专题一般是什么生命周期呢。
选一个前几天略火的“腾讯收购盛大”的事件回顾一下在微博（社交非匿名）的timeline。
此话题其实在8月26日已经传过一次了，但是并没有下文
11月6日早上，话题重新传了出来，能找到的比较早的一条信息是“腾讯敲定收购盛大文学”
隔了大约半天，又传出了“百度投资部的人曾出现在盛大总部”
隔天新消息“盛大否认腾讯或百度的收购”
还曝出了新CEO
但是！半天还没过去，神转折出现了
各种爆内幕的文也开始外放了
猛料基本差不多了，后面还有陆陆续续的内幕文和作家声讨文放出。
<br />
以这个case来说，事件的焦点时间大约也就是2~3天，可以绵延到5天甚至一周，但是前两天这种神转折的事情，对于没跟上第一时间讯息的读者来说，专题的意义可见一斑，那么怎么为读者呈现最好的专题效果就很关键了。
<br />
这里我们提几个方案，然后随便推测一下（实际工作可不能光靠想的，要充分调研才行）。
方案一：不搞专门的专题页，只做猛料和猛料阅读页里的相关新闻，出一条新的就放一条。
好处是逻辑简单，方便处理；
坏处是，个人觉得没有挠到痛点，普通新闻+阅读页里的相关阅读的设计强度不够，显然不够挠到痛点，尤其是相关阅读如果门槛偏低的话，很容易被人忽略，如果读者不小心忽略了，错过了类似前面案例里这种神转折的精彩回顾那真的是太遗憾了；
方案二，顶部常驻专题头条，点进去以后形成专题列表页
好处是够强够重点，类似很多传统新闻站的做法
坏处是貌似过强，万一没更新的话一直挂着也很烦，比如当初8月26日其实盛大就第一次爆出来过收购的事儿，然后真的是立刻沉寂了，但问题是谁知道你刚撤下来会不会就突然有新消息了……
另外常驻区可扩展性相对差一点，基本少了得2条多了也就是5条比较合适，但是爆料往往很难说是多是少，有时候突发事件特别多挤不下，有时候又天下太平没东西可发。当然如果结合商业模式的话倒是可以考虑卖一下广告什么的……
方案三：列表页混杂专题列表，专题以“专题名+最新讯息+强调形态”的形态穿插在正常列表里面，点击去以后是专题列表页
好处是有更新才飘出来，不更新就不影响，如果哪天猛料特别多，凑个十几条也一样装得下；
坏处是可能列表部分形态过于复杂，但是由于这个形态我比较喜欢，于是我们就这么定了吧~
<br />
专题的产品形态确定，原型就是分分钟的事情~
<br />
以上问题解决，列表页完工，弄几个真实一点的数据看下效果，大体来说过得去，专题和一般列表的区分度不够大，可能会形成误解的，交给UI了。
剩下的事情就还是打点运营，嘱咐需求了。
下面开搞阅读页。
老规矩，跟我虔诚的默念一遍：“阅读体验最重要；佐证比较重要，表态的地方需要露出，其他都是浮云”
阅读页其实有两种设计思路：
1.简单的，因为列表页想的比较周全就简单得多了，毕竟前面已经思考清楚了很多东西，比如基本元素，比如基本框架和层级，阅读页的设计简直是顺顺畅畅的就出来了，最简单的思路就是， 按照列表页的基本元素显示在相对固定的问题，阅读页专属功能单独开辟小区域放置，比如举报、分享可以单独拎出来放在右上角开辟好的区域。评论、投票、tag换成可点模式。
剩下的只不过是锦上添花的考虑下阅读的姿势怎么样会比较好，这里就随意发挥就好了，怎么炫酷怎么来，只要不怕你的RD揍你就行了。
走起~
两分钟都不需要~
2.精益求精的。
上面简单版的好处在于逻辑简单，设计和用户理解都够简单，但是严格来说体验不算特别好 ，有几个毛病是显而易见的。
a.万一文章特别长怎么破？用户可能看到一小半就愤而投票或者愤而评论了；
b.页面内的评论、投票、tag实际上交互表现不算很友好，需要一定的用户教育成本，用户才知道要参与。
c.评论直接平铺显示某种程度上会干扰正常阅读，可以考虑精简。
没事，别忘了我们的框架，稍微优化一下，将部分可触摸功能采用底部可收起工具栏处理即可。
还是两分钟都不需要~
订阅功能
嗯，这是个难点，因为我前面很飘逸的把内容划分搞成tag了，于是我现在很忧愁的发现订阅模块从新闻app里的可借鉴经验不多了。没辙，还是脑暴几个方案吧。
一种方案，沿袭传统做法，tag分tab显示，问题在于可控程度很低，tag和分类不同之处就在于粒度细数量多不确定性高，分tab的话切换成本有可能会非常高，尾部tab相当于是订了白订；除了tag本身的不确定性外，因为粒度过细，tag下内容的不确定性也很高，有可能切过去以后发现压根没更新；
还有一种，类似flipboard，起手宫格，对有更新的宫格做时效性rank，用户知道哪些tag下有更新的内容，自然会点进去看，没更新的话放在尾部也没什么太大损失，当然宫格的切近切出成本不低，即使是material design指导手册都不是很推荐了，一般都是比较强调bigger的app会热衷这种“类似还原杂志的感觉”的交互。
除此之外，有个更简洁的做法是，类似quora或者知乎里关注人、问题的策略，可以通过搜索或者在广场内容下看到tag，点击进tag可以看到本tag历史内容，同时点击关注，以后这个tag下的所有内容都更新到主页的timeline里，取消这个订阅也采用原样的方式回去再操作一遍，无订阅的话只能看到广场内容，有订阅的话看到订阅内容+广场内容，列表仍然按照时间排序。好处是对用户来说认知订阅效果简单（比起一个类目名，点进去瞅瞅历史更能明确自己是不是需要这块内容），也省的翻来翻去。当然了，整体订阅管理会神麻烦，但是我想了一下，这种猛料定位本来就是一浪淘一浪，没新鲜事儿的tag自然慢慢沉寂，沉寂了反正也不骚扰用户，不去管理也无所谓，添加tag的话也应该是看见一出是一出，看见火了的就立马关注一把其实效率也挺高的。本来设置啦、管理啦之类的功能就应该是用户少用为妙，我们给用户最好的就行了，ok，那就这么着。
原型图更简单了，套列表页的大框架，加个小功能即可，原列表和阅读页的tag改成可点的好了，误触发的事情交给UI（反正也不存在）考虑就好了。
喏，点击tag后的效果，你看搭好框架就是这么方便，右上角随便玩，而且因为选择了方案三，我连边界条件都省了（不需要判断tag下是否有内容）
。
<br />
基本功能差不多齐活了，可以边边角角修一修，比如想点办法给原App或者h5站导导量……
设置功能搞点什么清缓存啦之类的
<br />
搞妥，润色一下，补充好边边角角的需求，好好捋一捋加上各种策略，就可以产出PRD了。
<br />
最重要的一步来了！买把雨伞（防喷），开始准备评审会咯~
