中文名称：简书
产品类型：写作软件、阅读社区
这是百度百科对简书的描述，为一个内容导向的UGC应用。按描述和看到的来讲，目的应是是通过文字分享交流构建社交。
信息架构
总图
简书信息架构
主任务流
发表文章的步骤
发表文章的步骤
从最直观的信息架构看起，简书首页采用的是传统的是自然架构与层级架构相结合的方式，无限加载的列表流很好的适应了用户“闲逛，漫无目的”的场景，图文结合的列表加大了单纯文章的吸引力，但是：
1.注意力从标题到图片再回到标题，视觉流并不流畅（看下面那张图）
2.长时间浏览单一列表，易产生阅读疲劳，且对于列表来讲，没有图片的部 分，在布局上看并不整齐。
3.评论与喜欢放在标题下的作用应是：1.判断文章热度 2.让用户有参与感 3.感到社区的活力。这里评论与喜欢表现出来的感觉相近，而评论比喜欢更能反映出其他人对文章的参与度，且作为一个鼓励交流的社区来讲，评论应比喜欢功能层级更高。所以完全可以只留评论在这里。
4. 列表也不是按时间线排序的，时间无规律的变化也会让用户产生迷茫感，所以这里把时间去掉更好些。
首页列表
交互细节
评论
左边是简书右边是其他软件
文章阅读页的回复，如果用左边这种需要点一下进去评论的表达方式，对于用户的直观问题是，是否评论，但如果用图二的方式显示，直观就是，评论些什么。显然，直接把输入框摆在那里的效果更好些。
首页瀑布流列表中时间的表示
首页列表
1.日期与时间本身字体很小，颜色与背景色对比度也低，可以看出是出于弱化信息层级的角度考虑，但日期与时间之间间距过小导致看起来像是一串数字符。
2.无规律的时间线，很容易让用户产生迷茫感。
3.一个鼓励通过内容交流的社区，文章应是最主要的，而文章与新闻的区别在于文章的价值在于其内容，而新闻则多了个时效性，新鲜的才最好。对于文章来讲时间并没有那么重要。
综上，首页瀑布流标题上的时间是可以去掉的。
发布后的反馈
关于反馈的问题，无论是发布了文章后，还是保存为私密文章，都没有足够的提示，缺乏操作反馈的情况下，用户怎么知道是否操作成功了呢？还是失败了？
用户应该能够清楚了解系统的状态 ---- Norman
文章私密性设置
保存私密文章流程
当发布不想让人看到的东西时，下意识的反应是寻找不公开发布的设置，再点保存，或者是直接保存，是不会是下意识去点关闭的。
一致性
三个点点，两处长一样，咋用法还不一样捏~
点进去前是通用设置，进去后咋成设置了呢。。。。说好的通用设置呢~~~~看下面的小字。。。
这个就不说了，太明显了
系统在其结构和指令设计上应保持一致的风格，从而尽量减少用户因记错或者记不起如何操作而引发的问题 ---- Norman
专题分类
当用户点到专题页面时，有可能是随机浏览，也有可能是有目的根据兴趣内容分类筛选。用户对于文章的认知是单篇文章组成的集合体，而专题则是有目的的，按逻辑划分的一些集合体。对于有一定心理预期，但不确定具体目标的用户，在分散随机的文章页面是不易得到满足的，这个时候就会转到专题页面，按心理预期分类查找。例：用户进入阅读软件，可能的一种使用方式是，用户心里已经有一个明确的思路，找某类文章看看，所以用户进入专题页面，选择某类专题，然后进行浏览。
表现层
移动应用的主要特点有使用场景复杂，用户注意力差，时间碎片化，屏幕尺寸小，胖胖的手指和不大的屏幕，这些都导致了对移动端应用极高的要求。
而首页导双导航的灰底色和深灰色的字并没有形成足够的对比度。从认知角度来讲，越小的字辨识度越低，对比度越差辨识度越低，这里作为主要场景下重点功能的导航显然表现是不够的。导航的视觉层级明显低于下面的列表流和中央硕大的写作按钮，更不用提闪烁的BANNER了。
当然，如果设计者的角度是目前简书内容并不完善，不鼓励按类搜索，那就当最后三段没说╮(╯_╰)╭。
交互初学者的一点小看法，大家有不同意见欢迎多多交流O(∩_∩)O哈！
网友评论