全面易懂!写给新手的信息架构设计指南

移动开发 Android
信息架构作为一个产品的骨架,是产品非常重要的一部分,它决定了一个产品的布局和未来的发展方向以及用户对一个产品的最初印象和整体体验。毫不夸张的说,好的产品信息架构是产品成功的一半。那么到底什么是产品的信息架构呢?该如何设计产品的信息架构?

很多产品设计师,在画原型或者设计 UI 的时候痴迷于工具的使用,拿到需求文档之后急于动手画图,忽略了信息架构设计对于产品的作用。

信息架构作为一个产品的骨架,是产品非常重要的一部分,它决定了一个产品的布局和未来的发展方向以及用户对一个产品的最初印象和整体体验。毫不夸张的说,好的产品信息架构是产品成功的一半。

那么到底什么是产品的信息架构呢?该如何设计产品的信息架构?如何评判一个产品信息架构的好坏?我们接着往下看:

一、信息架构的概念

让我们来看一个例子:

 

一个饭店需要有哪些设施,如果你是饭店的老板如何合理的排布这些设施,可以让客户感觉很舒服的用餐,这个过程就是一个信息架构的过程。他可以让客户对你的饭店产生好感,从而下次用餐的时候还会想到来你这里吃饭。

在排布饭店设施的过程中我们要遵循一些规范,比如用户的习惯或者施工规范等,正是因为需要遵循这些规范,所以我们需要一个信息架构来体现这些。

比较官方的信息架构解释是这样的:信息架构设计是对信息进行结构、组织以及归类的设计,好让使用者与用户容易使用与理解的一项艺术与科学。

简单来说,信息架构设计就是让用户可以 容易地理解你的产品是怎样的。让他们在使用你产品的时候可以更顺利更自然。就像一进入饭店就会有一种感觉,门口是等餐的地方,进去就应该吃饭,如果找洗手间一定不会往门口走,而会往深处走。这就是信息架构的好处:他让用户使用同类产品时更容易上手和理解,让产品更容易被接受。

二、为何需要信息架构设计

那对于线上产品来说为什么需要合理的信息架构呢?大家来看下边3组 app 的 tab栏截图。你能仅仅从 tab栏就看出这款 app 是什么类型的 app,如何使用吗?

 

很明显的,***个是一款购物类 app,第二个是一款图片社交类的 app,第三个是微信的 tab,虽然首页名称是微信,但是我相信如果把名称换成「聊天」,你还是能认出这是微信的 tab栏。

从底部标签栏就可以大致看出产品是用来干嘛的,这就是信息架构的作用。一个合理的信息架构可以让产品非常容易被用户理解,可以让用户***眼对产品有一个简单的认知,指导自己可以用产品做什么事,指导产品提供什么服务。

再看一组反例:

 

这三组 tab栏就让人很困惑了,看了半天你也许根本不知道这几款 app 是做什么用的,以及如何使用。如果你让用户很困惑,他会分分钟抛弃你的 app。

所以信息架构的核心目标是为用户提供更好的体验,获得更高的留存率。

一款信息架构良好的产品必然遵循以下两个标准:

  • 让用户打开 app 的***秒就知道这是一款什么 app,怎么用;
  • 用户想要使用某一功能时,能够***时间找到。

我们通过这两个标准来印证下上边3个正面案例的信息架构:

 

  • 相信你能很快速的识别出这款软件的用途和用法,这就给提升留存提供了基础。
  • 那么如果信息架构像架构一个饭店一样简单,那么信息架构为何需要设计?

 

因为你的实际产品功能可能有这么多:

 

  • 毕竟我们不是支付宝,没办法把功能像豆腐块一样堆叠起来,我们需要一些科学的设计方法。

三、如何设计信息架构

合理的信息架构设计需要考虑5个步骤:

 

下面我来分步讲解一下。

1. 了解用户,场景,习惯

首先你的产品是给到用户用,你当然要***限度的了解你的用户,我们先来看下一个概念:「心智模型」。

 

[[242379]]

心智模型是经由经验及学习,脑海中对某些事物发展的过程,所写下的剧本。人类在经历或学习某些事件之后,会对事物的发展及变化,归纳出一些结论,然后像是写剧本一样,把这些经验浓缩成一本一本的剧本,等到重复或类似的事情再度发生,我们便不自觉的应用这些先前写好的剧本,来预测事物的发展变化。心智模型是你对事物运行发展的预测。再说得清楚一点,你「希望」事物将如何发展,并不是心智模型,但你「认为」事物将如何发展,就是你的心智模型了。

假设你从没见过 iPad,而我刚递给你一台并告诉你可以用它来看书。在你打开 iPad 使用它之前,你头脑里会有一个在 iPad 上如何阅读的模型。你会假想书在 iPad 屏幕上是怎样的,你可以做什么事情,比如翻页或使用书签,以及这些事情的大致做法。即使你以前从没有使用过 iPad,你也有一个用 iPad 看书的「心智模型」。你头脑里的心智模型的样式和运作方式取决于很多因素。

用户往往带着以往使用 APP 的一些习惯来使用产品;线下做同一件事的习惯、生活习惯、心智模型等。要考虑哪些是可以创新的,哪些是用户习惯,要在不妨碍用户习惯的情况下作出更能让用户接受的创新。

你要考虑清楚4个问题:

用户通常用你的产品做什么?

用户用你的产品来做什么?用来看新闻还是用来聊天?一定要考虑清楚用户的核心流程。从核心流程中提取信息架构的基础形式。

用户用这类产品最关心什么?

用新闻app 时咨询的真实性实效性,购物类app 精准搜索和售后功能,就是你的用户关注点在哪里,这是一个很好的突破口。

用户有哪些思维定式?

和用户年龄身份相关的属性,产品体验符合相应用户的思维模式,心智模型,用户就会比较容易接受。

用户用什么类似的产品?

类似的产品也会带来一些用户习惯,迎合这些习惯也会让用户快速上手接受产品。

了解了你的用户场景和使用习惯之后你会知道如何做出符合用户心智的,容易被接受的产品,你不需要担心做的产品没有差异性或者没有竞争力,我们可以在核心流程之外做出创新点,让用户觉得你的产品又好用又有些不一样。

2. 了解业务

这里的业务包括与产品接触的内部及外部的人提出的需求,比如公司的运营,市场,销售,BD,公司的外部合作伙伴等。

这些人的需求我们也要收集,比如运营人员想更方便的管理注册用户,销售想更多的添加广告位,市场推广人员要求能统计不同渠道带来产品的下载量,注册数,活跃数,合作伙伴需要进行账号,内容互通等,总之只要与业务有关的人的意见,尽可能的在产品设计前多收集,即使做不了,也告诉他们原因,要不然产品上线后就等着被他们吐槽吧。

3. 调研竞品的信息架构

在做一款 app 时,我们面临了和无数竞品争抢用户的局面,这时候分析竞品就非常必要,我们需要在知己知彼的前提下,做好核心流程功能,再思考如何在差异功能上做好突破。

首先我们需要把竞品功能梳理成思维导图:

 

其实思维导图就是信息架构比较基础的形式了,但是光有思维导图没用,我们需要对思维导图进行分析。

我以前做过的一款人脉 app 为例,当初对比了领英、赤兔和脉脉,分析了这4款 app 的思维导图后得出的共性和差异点:

 

共性就是要符合用户使用习惯的地方,如果你调研的3-5个产品都这么做了,很可能这里是产生用户习惯的地方,是我们需要去遵循的,这是获得用户好感度的基础。

分析产品时你一定也会得出一些产品差异的地方,而这些差异就是你的产品竞争点,也是别人用你的 app 不用其他 app 的理由。比如人脉软件都会有社交相关的功能,但是脉脉会比较注重职场招聘、直播等互联网职场人比较关心的点,这样对应的用户群体就比较会吃你这套,会提升用户的粘性。

相信你在梳理了竞品的信息架构,总结了共性和差异点之后对产品的信息架构已经有一个比较清晰的认知了,在做自己产品信息架构的时候也会更胸有成竹。但是***还有一件事我们可以做,就是对我们的要做的产品功能做卡片分类。

4. 卡片分类

 

[[242380]]

卡片分类法是我们工作中常用到的一种方法,它可以在用户侧再一次印证和检测我们的产品信息架构。

卡片分类法就是让用户对功能卡片进行分类,组织,并给相关功能的集合重新定义名称的一种自下而上的整理方法。

说直白点就是准备一堆卡片,在这些卡片上写上你所需要包含的功能名称,然后给到用户侧,让用户进行分类,让用户进行组织,来了解用户到底觉得这些功能应该怎么合并怎么归类的一种方法。它可以帮助你站在用户角度去了解用户是怎么认定这些功能的,也可以在卡片分类法的过程中更加了解用户是怎么想的。

卡片分类法大概的步骤和注意点是这样的:

 

卡片分类法最终会产出这样的一个树形图:

 

5. 产出信息架构

其实到这一步信息架构大概的雏形已经有了,你可以用 axure 或者类似 mindnode 的软件把信息架构梳理出来。

接下来你要对信息架构进行重要性分级,这样在产品开发的前期可以帮助梳理产品研发的优先级,集中精力解决用户的***痛点。在产出页面时也可以更好的把控页面元素的大小层级,位置关系等。

 

***你需要注意层和度的平衡:层一般不超过5层,超过操作困难。度过多会让用户认知成本增加,容易找不到想找的内容。这里的度指的是同一页面展示的信息量。

那么这次分享就到这里,相信你已经了解到信息架构的重要性以及如何设计信息架构了。希望给你的产品带来一些帮助,为你的产品带来更多的留存和好的发展方向,如果对信息架构有什么疑问或者建议,欢迎留言交流。

责任编辑:未丽燕 来源: 优设
相关推荐

2018-08-03 12:52:51

首页弹窗iOS

2018-08-08 20:35:58

APP结构指南导航

2018-05-16 10:07:02

监控报警系统

2019-09-24 16:15:03

架构配置代码

2018-11-28 09:38:34

微服务架构API

2013-05-27 10:58:28

Tumblr架构设计雅虎收购

2023-05-12 08:06:46

Kubernetes多云架构

2023-07-24 16:08:17

测试开发

2019-11-19 09:00:00

数据库架构设计

2022-04-22 17:19:49

开发设计师合作

2012-05-01 21:27:20

iOS

2020-04-17 10:51:26

数据分析设计师数据

2015-06-02 04:17:44

架构设计审架构设计说明书

2022-05-12 10:11:32

通信行业运营商裁员

2023-07-05 08:00:52

MetrAuto系统架构

2009-07-06 10:36:41

敏捷开发

2021-11-08 06:57:35

Redis架构设计

2012-05-11 10:38:15

Cloud Found

2009-01-15 09:43:51

Web架构设计缓存

2015-06-02 04:34:05

架构设计
点赞
收藏

51CTO技术栈公众号