知果:B端产品信息架构设计的6大组织原则

知果日记
+ 关注
2022-05-16 11:27
551次阅读
关键词:B端产品、信息架构、组织原则
你有没有遇到在梳理B端产品界面信息的时候,不知道该如何开始?
你有没有在梳理到一半的时候,觉得前面整理的不对,想从头开始?
我曾经都有过,因此我想了很多方法,期望尽可能整理出相对好用,又不反复修改的信息架构。
你知道吗?其实在很多地方,譬如在写ppt、写文章、设计网站、绘制海报中,信息架构都是用得到的。
今天呢,知果想和你聊聊有关B端产品信息架构的事情。
这事儿说大不大,说小不小。我的实践体会是,信息架构就像一个物体的骨架,有了好的骨架,我们才能更好的填充其里面的内容
打个比方,对于一栋居民住宅楼来说,楼的整体结构决定了楼道、电梯、屋子、厅堂等部分的设计。而对于屋内卧室的结构来说,其结构决定了桌子、柜子、床的摆放位置等。
对于B端产品来说,信息架构设计的好坏,一方面决定了用户在使用产品中的难易程度另一方面也影响着后续当产品功能添加时,产品的延展性如何
下面,知果将与你们分享关于B端产品信息架构设计的 6 大组织原则:
独立组织原则是指节点与节点之间是没有强烈的因果或先后关系,它们是相对独立的。它们可以共同完成某件事情,但完成的期间互相不相关;也可以相互之间完全没有关联,彼此独立。
例如,要把A任务分解成3个子任务,这3个子任务之间是没有前后关系的,它们可以同时进行,它们都做完了,A任务就算完成了。
再例如,通常来说,B端产品中用户信息模块和消息通知模块就是无相关关系的,我们在设计它们之间的结构关系时,就可以分别考虑。
包含组织原则是指节点与节点之间父与子的关系。我们看到的树形结构,就是包含组织原则的其中一种视觉呈现形式。
例如,在云效系统的项目协作模块中,包括了任务管理、需求管理、迭代管理、度量统计等子模块。质量管理模块中,包括了测试计划、测试用例、缺陷管理等子模块。
关联组织原则是指节点与节点具有某种联系,相互之间产生影响和牵连。
在我们日常生活中,大部分事物都不是独立存在的,而是以一种关联的形态出现。
例如,当一个外卖APP内商家的数量越丰富,食物越丰富且好评也越多的时候,用户也会越多,反之亦然。
在B端产品中,一些数据是通过API的方式从其他系统读取过来的。用户也许无需知晓数据的来源,但我们设计者需要在架构图上标注与明确这种联系,同步到成员。
再例如,在DevOps系统中,产品经理A给研发工程师B下完任务后,在A的任务清单里可以看到新增了一条他创建的任务,与此同时,在B处也出现了一条新的研发任务。
B端产品中很多的数据信息具有时效性,比如操作日志、待办事项、预定会议室数据等。因此,时间组织原则经常被用到。
列表内容的排序基本都遵循时间组织原则,将最近的数据往前靠。如果用户想查询几天前的数据,则可以使用列表上方的筛选条件查询相关数据。
B端产品中很多信息具有前后的流程关系,就需要用到流程组织原则了。
例如,员工A提交的请假审批流程,需要按照流程逐一审批才可结束。
再例如,在监控系统中,如果要给一个监视器添加告警信息,需要将监视器的其他基础信息补充完整,才能去添加告警内容。
维度组织原则是指信息按照维度来分类,并呈现给用户。在第4点中提到的时间组织原则就是维度组织原则中的一种。
在C端产品中常见的有,按推荐、按热度、按最新、按点赞数等。
在B端产品中,维度组织通常与场景、数据性质有关系,最主要的还是看用户需求。
例如,在DevOps系统中,一个测试工程师通常会跟进1-3个产品的测试,但他们最主要的需求是能在一个页面上看到所有待处理的任务,而不是每个产品下有几个待处理的任务。因此,信息组织的维度不是按产品,而是按任务状态。
最后的话
 
B端产品信息架构设计是碎片化需求转原型的第一步,理清产品的信息构架,才有之后的交互设计、视觉设计等一系列行为。
好的信息架构设计不仅易用、也易延展。
关于B端产品信息架构设计的其他方面,例如信息架构设计的基本思路、信息架构的4大模式、什么是信息架构中的节点组织原则等,在我的书籍《B端思维》中都有涉及到。
书中还包括B端产品用户界面导航如何设计、布局如何设计、信息如何呈现等均有详细阐述。

好啦,知果今天的分享就到这里,我们下期见~

本文来自微信公众号 “知果日记”(ID:gh_690a8b6479cb),36氪经授权发布。

0
消息通知
咨询入驻
商务合作