什么是“好”的信息架构?

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

信息架构梳理的方法是很成熟的,但是好像评判“好”和“不好”的标准都很理论。那么,要如何看待什么是“好”的信息架构?

一、一个不可避免的问题

某天,笔者看到了一个产品经理提问:

公司有个后台产品,产品主要是满足内部员工的使用,但是产品主要是以堆砌功能为主,加上公司并没有交互,导致两个问题:

  • 第一个问题是虽然是能用,但有点难用。
  • 第二个问题是由于功能的堆砌,给人很杂乱的感觉。

目前想先从产品的信息架构入手,进行产品的梳理,推动它的优化。但是问题来了,信息架构梳理的方法是很成熟的,但是好像评判“好”和“不好”的标准都很理论。想请教下大家,你们怎么看待什么是“好”的信息架构?

在产品生涯中,我们应该不可避免都遇到需要优化甚至重构的后台系统。

原因一般有:

  • 前期项目太赶,导致没有好好的先规划再落地。
  • 上一个负责该项目的产品经理经验不足。
  • 因业务突然转变,原有的产品和信息架构无法很好的 支撑新业务转变落地。

当我们接受到优化、重构等任务,深知这是一个吃力不讨好的活儿。干好了,收益不是特别大,因为本来业务也一直在用这个系统,只不过难用一点而已。没干好,老板和项目组对你信心下降,对日后的工作开展和晋升都会有阻塞。

二、关键是能设计出好的信息架构

有时候我们不能直接拿任务梳理出解决方案,而是要把任务转化为完成该任务所需要的技能,再让技能的输出转化为解决方案。

优化或重构系统需要很多技能,其中涉及到设计落地相关最重要技能则是“能设计出好的信息架构”。

对于产品经理来说,信息架构是什么:产品经理的工作需要设计业务架构、产品架构和信息架构。一个企业的业务架构决定了产品架构,产品架构决定了信息架构,是一个递进的关系。

什么是“好”的信息架构?这篇文章会告诉你。

从产品体验要素五层理解去信息架构,则它存在于结构层、框架层、表现层,并且也是由该三层分别不同的元素:交互设计、信息框架、界面设计、导航设计、视觉设计等组成。

什么是“好”的信息架构?这篇文章会告诉你。

后台,是直面用户前端的信息系统,该系统的架构是否合理则决定了用户对该系统的直接感知。产品经理需要为后台设计出一个合适的信息架构,让用户觉得好用。

而一个好的信息架构,应该可以能低成本与其他系统建立连接。

你应该对信息架构还有许多疑问,我们接着往下看。

三、信息架构和其悖论

信息架构本身的含义是:是一种连接信息供需方,让其按设计好的流程进行操作,形成任务闭环的工具。

假如我需要在图书馆找一本书籍,那么我需要找到图书馆的书籍目录总纲,在此基础上根据书籍名称或分类等筛选查找,直到找到书籍的对应位置。在这个场景下,书籍目录总纲则是充当信息连接的工具,并且我需要借助该工具,完成查找书籍的任务。

随着时代的发展,信息量也不断的增加,人们查找信息的速度趋向缓慢甚至0效率,故而针对不同的场景,设计出合理的信息架构,帮助人们完成任务,提高人们依靠信息输入进而解决问题的效率,是信息架构这个工具最重要的使命。

但是,信息架构本身存在悖论:很难(几乎为零)设计出完美的信息架构,因为所有的定义和优化对于任何人来说都不能是最完美最合适的。

  1. 对于运营人员来说,希望做完活动后,能马上看到营销效果数据,那我们是基于在营销系统上实现“营销效果数据查看功能”,还是把这些数据当做是企业的核心数据资产,统一放在数据中心处查看呢?还是两边都做?
  2. 对于资料管理人员来说,采购人员负责供应商资料和商品资料的新建维护,那这个资料是放在采购系统里面还是系统资料中心统一管理处?
  3. 假设一张单据需要重做功能,该功能的按钮文案通常叫“重做”。但产品经理考虑到单据的逻辑后,将文案定义为了“作废并新增”,也许是一个更好的方案。

你认为的“信息”和我认为的“信息”真的是在同一层面上吗?

即便面对同一事物,不同人基于各自所处的环境和思维层面不一致,总会导致存在认知和理解上的差异。

所以,用户抱怨“系统不好用”、“功能太繁杂了”等原因,本质是因为不同的人对信息的理解都不一样,我们没办法从根本上上解决这个问题,世界本来就是复杂的。

不过不要太悲观,基于对信息架构悖论的认识,我们依旧可以给出一套行之有效的方案:找到该场景最合适的信息架构框架,并且能随时迭代这个架构对人、对信息、对任何内外部要素的连接能力。

信息架构一直发挥着连接信息、连接人的作用,只要能把信息架构的这个能力不断提高,那么这就是一个好的信息架构。

注重信息架构的连接能力,这样在不同的阶段,我们都可以设计出“好”的信息架构,为不同的用户去提供一个好用的后台系统(或者是任何系统)。

如果一个后台十分庞大,但用户依然很清晰后台架构,并且觉得很合理,专业人士感到高效,小白不会迷失方向而能快速上手,这就是一个好的信息架构设计,因为这个信息架构很低成本就和不同的人群系统连接起来了。

希望到这里可以解开你对信息架构是什么,怎么才算一个好的信息架构的疑问。

直到这里依然是概念阶段,我们来看看如何设计。

四、怎么设计连接能力强的信息架构

要设计连接能力突出的信息架构,需要从情景、内容、用户三方面去考虑完整。大部分情况下,我们都是直接按照自己的设计美感输出优化方案,最终效果总是不尽人意。

4.1 考虑情景

一个项目是由战略、文化、市场、技术、资源、政治和经济环境各种组成。

理解公司的战略目标,商业目标,目标的变化可能会影响:我们从一个进销存系统变成一个ERP系统,客户管理页面迭代成一个CRM子系统。

理解所处行业、市场、商家的信息:如果是新兴或科技行业,可以比较大胆超前的去设计架构,但如果是传统行业,信息化程度本来不高,需要有漫长的发展周期,那么架构需要保守,可用。

理解能提供的资源和技术上限:公司给予这个项目的资源和技术支持到什么程度,如果是战略级别项目,可能会配备顶级开发,最后迭代为一个中台项目。

理解其他如政治、经济环境等因素可能会造成的影响:如果项目是十分受经济波动和政治因素影响的,那么也需要提前考虑会影响信息架构,避免犯重大错误,例如制药的流程违规导致违法。

仔细看这些都是产品负责人所需要的技能,所以从另外一个角度来说,比较好的信息架构只有产品负责人能设计出来,其他人没有办法去做,一是没有足够的信息,二是自身技能还没点满。

4.2 考虑内容

内容是该信息架构相关的行业的所有信息。

内容所有权:不同信息的所有权所属不同。例如优惠券的信息则属于运营部门所有,但是活动效果却是所有部门公有的,这里面涉及到数据权限的设计、数据效果的展示工作。

内容属性:内容属于开放性还是非开放性的,属于哪些维度,可维护还是不可维护等。很多后台的操作都需要考虑到权限问题、操作闭环。

技术:关于数据库、大数据、数据格式等体系知识。特别是对于后端产品经理来说,需要对数据库知识、UML知识有一个了解。

数量:内容的数量有多少?需要放在哪里才能存储?客户上传的短视频,企业到底要存储多久呢,以后是否有法律风险需要调回查看?一个企业的备案信息,国家通常会保留很多年。

动态性:内容是如何变动的 ?变动的速度趋势是怎么样?增长率有多少,不同的内容的生命周期是怎么样的。用户的画像是否会随着数据和技术的发展,更加完善?用户的画像什么时候需要更新,什么时候需要重新评估 ,什么时候需要丢弃?

4.3 考虑用户

用户即使业务的目标群体,不过多赘述。

受众:用户群体,一个庞大的系统,有一个主群体,然后有很多分散的小群体(部门)。C端的产品一开始可能只有一种目标群体,但随着业务的拓展自然会瞄准更多的用户群体。B端的系统是分别给一个企业不同的部门用的,不用的部门又有岗位的区分,每个群体绝对有很大差异。

任务:每个大群体、大部门、小组织、个体需要完成的任务流程。多考虑功能的闭环和异常流程,考虑这个工作完对个体有什么影响,是否会让他舒畅的完成每一次工作?考虑业务流程实现后对该企业有什么影响,是否能带来可量化的业务价值?

需求:要考虑真正的需求本质,搜索和查找不是目的,完成任务/工作闭环结果才是。用户不在意对接的人工智能客服还是人工客服,能快速解决他的问题就可以了。

搜索和查找:大量的搜索和查找,怎么样才能优化效率,是否有完善的设计方法论?不同场景的搜索查找都有一定的设计方案,用户也一定有自己的搜索习惯,系统是去迎合还是打破?

整体体验:B端产品也有不同于C端产品需要的用户体验,产品体验可以分为两种:第一种我很懂你,你可以随便进行怎么做,整体过程感觉很好,但结果不一定保证(2C)。第二种是你只能按照我的要求做,但是我可以给一个很好的结果你(2B)。

不属于你的用户:考虑不属于我们的用户,即要考虑他们为什么觉得不好用 ,觉得其他竞争对手的产品好用。

设计者应该明确上述三点的定义,并且把这三点连接起来,由此才能设计一个连接性强的系统。这需要大量技能组成和实践经验,所以设计信息架构这个技能并没有那么简单。

不过对于大部分同学,先完善对信息架构的认知,再把认知转化为思考,慢慢运用到实际工作中,已经可以产生比较大的帮助。

五、总结

(1)在产品生涯中,我们总会遇到优化或重构系统的问题。这类型问题通常吃力不讨好,特别是在大公司。

(2)遇到棘手的任务时,需要把任务拆解成完成该任务所需的产品技能,快速习得该技能,输出解决方案。

(3)好的信息架构,应该可以能低成本与其他系统建立连接。但是信息架构存在悖论,本质是因为人与人之间认知差异造成的。即便没办法设计完美的信息架构,但是它能阶段式的解决问题,这就足够了。

(4)在优化或者重构系统之前,先思考情景、内容、用户,并且把三者连接起来,随时记着信息架构最重要的是它的连接能力。

(5)最重要的是:问题依旧存在,解决问题的工具也会存在,我们要接受不完美,但只要有效。

你当初是怎么去优化那个“看着都烦”的后台系统的呢?欢迎留言分享。

祝:文章部分知识点由笔者阅读《信息架构:超越 Web 设计》总结而成。

 

作者:德拉克马 ;公众号:五百桶户(ID:Drachmaos),交流是最好的进步途径之一。

本文由 @德拉克马 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!