Lofter信息架构设计改版说明

Lofter信息架构设计改版

leadwhite

1、竞品分析

我选择了Lofter现版本（5.2.1）、In、Nice三款图片社交类的应用进行竞品分析.

需要指出的是，这三款竞品在产品定位上有些许不同，这进而导致了信息架构的差异.例如Lofter兼

备了轻博客的功能，因此在信息架构上有一些方便长文章搜索和阅读的设计；In的用户更为年轻化强调

张扬自我，因此"个人主页”有很高的层级；Nice的重心在于通过分享图片结交好友，因此特别突L1即时

性聊天界面。

下面我列出这三款软件的信息架构树状图：

Lofter

In

Nice

（如链接失效请在"竞品树形图”文件夹中打开）

对比三款App的信息架构树状图，我们可以总结出一些图片社交应用在信息架构上的共性。同时，我

们发现这三个应用并不是同质性非常强,有许多差异值得我们讨论和借鉴。

共性

首先,在一级导航上，图片社交应用TS必须具备“首页"一朋友们的更新内容、"发现"一^分

类索引和高质量内容推荐、‘我的"——包括个人信息、个人动态、设置等功能的；口总'页面。同时，"发

布"按钮也通常以最高层级的视翡婢展示在Tab栏中央，以鼓励用户发布图片内容。另外，个人博客页、

文章（图片）详情页、标签（话题）详情页是图片社交应用的关键部分，任何app都会具备这些页面并在

首页、发现、搜索等多个页面和流程中提供这三个基础页面的入口。

另一个值得注意的共性是“发现”页面内的页面布局，这个页面通常有非常多的内容，并且最能展现

出app的风格与气质.三款产品在“发现"页面都常注重2方面：

其一，在信息架构设计上配合业务与运营，在"发现”页面的首要位置放置主打业务入口或运营

banner0

Lofter和In都在线现"页面的突出位置放置运营banner。而Lofter的banner位置既是广告人口，

又是"专题"、"活动"等优质内容的入口，这种做法留住了用户对banner信息的关注，非常高明。

Lofter（左）与【n（右）的发现更

Nice则用非常鲜明的颜色表明"直播"入口，可见通过"直播"功能抓住用户是该团队近期非常重

要的业务目标

―上

O

Nice的发现页

其二，遵循层和度维持平衡的原则。

"发现"页面通常需要盛放稍为繁琐的标签分类，帮助用户层层递进地发现内容.然而，如果仅有分

类索引，则信息的层级过深，不利于用户在碎片化的时间中随意浏览。因此，大多数app都会选择局平化

地呈现部分推荐或热门内容。当然，不同app实行"扁平化”的度不同，在这一点上，我认为1。他「在标

签推荐这一环节上层有值得改进之处，我会在下文继续论述这一点。

差异性

Lofter.In.Nice三款应用在信息架构上的差异还是很多的，不过这主要与产品定位、目标用户的差

异有关，我在文章开头已经提及.这些差异未见得有明显的优劣，我会简单地概括一些有趣的点，还有一

些设计细节可能对Lofter的改版有所启发，我会尽量详细说明。

（1）、Tab的第三个一级导航

■■—«rLofter

aeQs6

In

d'•-X

Lofter"的第三个Tab标签为"消息"，下面的二级导航为"消息"（新粉丝、喜欢、评论等提醒），

“聊天"（即时聊天）、"动态"（关注人的动态），比较中规中矩，符合一般社区类app的设计规范。

In的第三个Tab标签为"in记"，即用户个人主页,该页面用时间轴+大幅照片的方式展现用户的个

人博客，很有鳏力，但妨碍信息展示的效率。把个人主页的信息层级提得如此之前，是一种创新的尝试，

也是针对相对低龄化用户张扬自我这种需求的回应。但是这种设计不是很符合用户的使用习惯（在卡片分

类法中得到证明），而且直接导致大量功能堆积在"我的中心"，使其变得很重。Lofter不需要盲目模仿

这种设计。

Nice的第三个Tab标签为“私聊".值得注意的是"私聊”指的是典型的“即时聊天页面”，不包

含评论、点赞等其他通知.领"社交媒体”这个概念来说，Lofter和In更偏向"媒体"，而Nice更希

望做“社交"，这导致他将即时聊天当作非常重要的功能来做。然而用户是否乐意在Nice上频繁聊天，

而不在熟识之后流向微信等产品，还非常值得考量。

（2）首页

Lofter的首页相对其他两款产品略有特殊，分为"关注"和"订阅"两个主要子二级导航。这里的“订

阅"这的是订阅的标签。在In和Nice中，首页的内容尽管有些微差异，但都是以展现订阅人为核心的，

订阅标签则被认为是一个不重要、甚至可有可无的功能。这背后的原因是什么呢？

我认为，这是由于Lofter同时具备轻博客功能导致的。对于以看图为目的的用户，他们并不需要频

繁使用“订阅标签"功能，因为查看所有人在同一标签下发表的照片不能保证质量，更会导致信息过载（例

如只愿意看女神的自拍，而不是所有人的自拍）.而把Lofter作为轻博客社区使用的用户，却非常依赖这

个功能，他们可能关注着某位作家的连载，甚至多为网络写手针对同一题材的创作与再创作。通过订阅书

名标签，这些用户可以获取小说更新信息。

因此，尽管Lofter给予"订阅”这个功能很高的层级，这一点与大多数叩p的信息架构不符甚至

在用户调研中不符合部分用户（以逛图片社区为主）的使用习惯，我们仍不能简单地将它撤下.除非后续

的辘证明以阅读为目的的用户占比下降到很低.

但是这一点上有没有值得改进的地方呢？我认为还是有的。在所有app首页都追求有感染效具的大

图展示时,Lofter订阅页这种垂直列表导航的罗列显得枯燥乏味，不太能引起用户的兴趣。我认为可以在

这个模块中适当地插入一些扁平化的推荐信息，让用户更接近高质量内容。

（3）发现

上文已经提及，三种App在发现页面都试图平衡"内容分类的导航明确、入口清晰一既层"，与

"推荐信息的外显一既度.，但在具体表现上仍有很多不同。Lofter在这一点的表现上可圈可点.但在

一些小细节上我认为仍然有一些进步空间。

In和Nice在展示图片分类时，都使用小图罗列的轮播面板，而Lofter则使用了一种有创意的展示方

优雅的布局方式

除了“分类"，推荐标签同样是"发现"页的重要内容。Lofter在这部分的表现依然可圈可点.

2--.BM♦H•••

-X

Nice的推荐信息显得杂乱,而Lofter的推荐标签则给人一种.以质・取拄”的印象

Lofter在标签推荐这一环节上既有层（清晰的标签入口）又有度（适量的扁平化信息展示）然而，我

认为它在扁平化上做的还不够好，它现在的扁平化呈现接近一种"伪扁平"。

哪里不好？当用户点击标签推荐下的一张图片的时候，他可能期望进入图片页面，然而导航仍然引向

标签页，这会导致用户的疑惑。

当然，细心的用户会发现，他寻找的图片就在标签专题页面写片组中的左手第一个，但这种使月习惯

献时期音养。

点击发现推荐图片直接跳入图片也不是完美方案，用户可能迷失在无序的图片海洋中，失去浏览专题

图片的有趣体验。

我在这里给出一个可供参考的解决方案：点击图片，依然进入标签专题页面，然而这一页的封面图采

用点击图片平铺成为背景。再次点击这张封面图可以查看图片页。

2、卡片分类法

为了验证Lofter.In.Nice三款软件在信息架构上是否符合用户的心智模型，我使用卡片分类法进行

了简单的用户调研。我将Lofter的全部二级导航制作成卡片,请一位目标用户（Sofia:应届毕业生，热

爱在微博分享照片，未使用过这三款应用）对这些卡片进行整理和分类，来分析用户的习惯。

一下是我制作的第一版功能卡片：

关注订阅标签评论通知

图片分类标签推荐专题（推送文章）聊天

达人推荐添加关注个人主页我的喜欢

搜索动态我的粉丝我的关注

新丝喜欢定制打印照片积分商城

摄影课堂iSS

在制作卡片时，我对卡片名称进行了一些调整，例如将"乐乎印品"改为"定制打印照片"，防止App

信息对调查用户思维上的干扰；将"订阅"改为"订阅标签"，让卡片表意更清晰。在进行卡片分类时，

我发现还有一些卡片名称很容易给人误导，在设计卡片时最好用其他名称替代，例如"添加关注”容易让

人联想到个人博客详情页的“follow"按钮，最好用〃寻找好友〃替代。

卡片分类过程和最终结果

将得到的结果进行整理和微调,我得到了下面的树状图：

IMt

■■■

AM

88Kd交APPMQOW:

luma

KK

・■me•片

可以看出，在一级导研口大部分二级导航上，Lofter的信息架构与用户的心智模型还是吻合的。因此

尽管与其他竞品存在差异，Lofter完全可以保持对自身的自信，在改版中也无需为新而新、为改而改。

图中高亮的亮点表示Lofter与用户心智模型不一致的地方，我会对这两处进行简要说明。

订阅标签：前文已5指出，大多数的图片社交应用将"订阅标签"视作T重要性很彳解）功能（Nice:

我。设置。我关注的标签；In:我的-＞我的话题），这一点得至打用户心智模型的验证。然而我也已经分

析过了Lofter在订阅这一功能上的特殊性，因此我认为Lofter不需要改动这里的信息架构。

通知：我仔细询问了调研对象，为什么不将"通知"放入包含"聊天"、"评论”的【消息】模块，

"通知”给她的印象是一组控件面板，用小是否接收各种;总息、是否产生提示音等。而Lofter

App中的“通知"感觉非常鸡肋:它似乎承载了T系统推送功能，然而同一时间有许多系统通知是在“聊

天”界面以对话框的形式展现的，而“通知”的使用频次之低，让我认为没有必要为它单独开设入匚。

网页版lofter的“通知”是包括好友动念.评论等的消息按笆，而手机端的“通知"藁义不明

在解决方法上，我认为可以考虑将"通知"并入"聊天"界面里，通过对话形式推送系统通知。如果

在产品设计上“通知"与