目录：
1.话题
2.广场
3.通知
4.评论
5.结语
话题
市面上很多APP，在第一次登录注册的时候，都会推荐话题，强绑4，5个话题。之前对于初次登录注册强绑话题不太理解。现在考虑以下几点。1.若是广场以关注为导航栏中的一项（许多APP会以推荐或者关注展开为首页），强绑的话会使用户进去不会那么空旷，有内容可以看。2.增强话题这一特性，到了后期数据反馈这一块，能够生成许多用户标签，再根据用户标签调整话题和内容。
如果首页进去就是关注话题的话，首先产品可以考虑强绑定话题模式，其次在页面设计中，在第一个板块也可以增加推荐话题的一些展示。
广场
现在做的这款APP，nav分别为关注、热门、附近。在微博的逻辑中，发布动态会在关注看见。而我们的关注功能首先不关注用户，只关注话题。而我们发的动态是可以不选择话题或者说关联话题的。除非是用户关注了这个话题并且自己关联了这个话题。热门的话就更不可能，就放在了附近里。放在附近的好处是让他有一种在附近的临时感和参与感。
虽然这些逻辑是在测试阶段才领悟到，但也发现在产品初创阶段，应该多费些时间考虑产品层面的一些东西。这样后面才会收拾的比较快，出现的问题也会比较少。
通知
由于产品初期是借鉴一个匿名APP，消息页面，由于交互冲突，把通知放在了第一页，而消息却放在了第二页。这是我很后悔事情。
首先在微博中，通知也是在第一页，而消息在第二页。但是微博点开消息页面中，是跳转到了消息这个页面，而且消息页面中也包含着与我相关、评论、点赞等功能。
在soul和Uki中，广场的动态直接放在了广场页面中，而关注等行为则在消息内容里，我觉得这样的好处是，使人留在广场的页面时间多一些，而且当有新的通知时，也不容易打断操作。返回广场的操作只需要四步，而且连贯性很强。1.同一页面中点开通知2.选择查看内容3.返回查看内容4.再次返回到广场。
微博则（1.点击消息2.点击评论3.点击详细内容4.返回到评论5.返回到消息6.点击首页）
评论
评论这一层我没有具体分析过，但是在社交属性中，评论也是相当重要的一部分，也很考验整个产品的逻辑性。
结语
当拿到原型图的时候，千万不要直接入手去设计。一定要把整个过一遍之后，对比是现在主流社交产品再根据你产品的特性，然后一直抓着产品问为什么，并且要列举出多于两个点以上。
并且，在设计中，一定要有延续性，比如说话题有几个，多的时候是否考虑安置展开按钮。以及我在设计动态的时候，并没有真正考虑到信息栏（评论，点点赞，转发）在上，动态文字在下有什么不妥。
当产品经理设计产品的时候要考虑后期的迭代和增加功能的一些扩展性，而我做的也是这样，如果在开发不大改页面的情况下能塞进更多的东西并且更加完善。也不要因为第一版不是自己想象中的效果而气馁，产品都是经过千锤百炼和一次次迭代中更更加完善的。
另外告诫自己，多想。并且这么做的时候多问自己，为什么？为什么要这样做，只有一个理由能说服自己的肯定不是最好的结果。
