信息架构梳理的方法是很成熟的，但是好像评判“好”和“不好”的标准都很理论。那么，要如何看待什么是“好”的信息架构？
一、一个不可避免的问题
某天，笔者看到了一个产品经理提问：
公司有个后台产品，产品主要是满足内部员工的使用，但是产品主要是以堆砌功能为主，加上公司并没有交互，导致两个问题：
第一个问题是虽然是能用，但有点难用。
第二个问题是由于功能的堆砌，给人很杂乱的感觉。
目前想先从产品的信息架构入手，进行产品的梳理，推动它的优化。但是问题来了，信息架构梳理的方法是很成熟的，但是好像评判“好”和“不好”的标准都很理论。想请教下大家，你们怎么看待什么是“好”的信息架构？
在产品生涯中，我们应该不可避免都遇到需要优化甚至重构的后台系统。
原因一般有：
前期项目太赶，导致没有好好的先规划再落地。
上一个负责该项目的产品经理经验不足。
因业务突然转变，原有的产品和信息架构无法很好的 支撑新业务转变落地。
当我们接受到优化、重构等任务，深知这是一个吃力不讨好的活儿。干好了，收益不是特别大，因为本来业务也一直在用这个系统，只不过难用一点而已。没干好，老板和项目组对你信心下降，对日后的工作开展和晋升都会有阻塞。
有时候我们不能直接拿任务梳理出解决方案，而是要把任务转化为完成该任务所需要的技能，再让技能的输出转化为解决方案。
优化或重构系统需要很多技能，其中涉及到设计落地相关最重要技能则是“能设计出好的信息架构”。
对于产品经理来说，信息架构是什么：产品经理的工作需要设计业务架构、产品架构和信息架构。一个企业的业务架构决定了产品架构，产品架构决定了信息架构，是一个递进的关系。
从产品体验要素五层理解去信息架构，则它存在于结构层、框架层、表现层，并且也是由该三层分别不同的元素：交互设计、信息框架、界面设计、导航设计、视觉设计等组成。
后台，是直面用户前端的信息系统，该系统的架构是否合理则决定了用户对该系统的直接感知。产品经理需要为后台设计出一个合适的信息架构，让用户觉得好用。
信息架构本身的含义是：是一种连接信息供需方，让其按设计好的流程进行操作，形成任务闭环的工具。
假如我需要在图书馆找一本书籍，那么我需要找到图书馆的书籍目录总纲，在此基础上根据书籍名称或分类等筛选查找，直到找到书籍的对应位置。在这个场景下，书籍目录总纲则是充当信息连接的工具，并且我需要借助该工具，完成查找书籍的任务。
随着时代的发展，信息量也不断的增加，人们查找信息的速度趋向缓慢甚至0效率，故而针对不同的场景，设计出合理的信息架构，帮助人们完成任务，提高人们依靠信息输入进而解决问题的效率，是信息架构这个工具最重要的使命。
但是，信息架构本身存在悖论：很难（几乎为零）设计出完美的信息架构，因为所有的定义和优化对于任何人来说都不能是最完美最合适的。
对于运营人员来说，希望做完活动后，能马上看到营销效果数据，那我们是基于在营销系统上实现“营销效果数据查看功能”，还是把这些数据当做是企业的核心数据资产，统一放在数据中心处查看呢？还是两边都做？
对于资料管理人员来说，采购人员负责供应商资料和商品资料的新建维护，那这个资料是放在采购系统里面还是系统资料中心统一管理处？
假设一张单据需要重做功能，该功能的按钮文案通常叫“重做”。但产品经理考虑到单据的逻辑后，将文案定义为了“作废并新增”，也许是一个更好的方案。
即便面对同一事物，不同人基于各自所处的环境和思维层面不一致，总会导致存在认知和理解上的差异。
所以，用户抱怨“系统不好用”、“功能太繁杂了”等原因，本质是因为不同的人对信息的理解都不一样，我们没办法从根本上上解决这个问题，世界本来就是复杂的。
不过不要太悲观，基于对信息架构悖论的认识，我们依旧可以给出一套行之有效的方案：找到该场景最合适的信息架构框架，并且能随时迭代这个架构对人、对信息、对任何内外部要素的连接能力。
信息架构一直发挥着连接信息、连接人的作用，只要能把信息架构的这个能力不断提高，那么这就是一个好的信息架构。
注重信息架构的连接能力，这样在不同的阶段，我们都可以设计出“好”的信息架构，为不同的用户去提供一个好用的后台系统（或者是任何系统）。
如果一个后台十分庞大，但用户依然很清晰后台架构，并且觉得很合理，专业人士感到高效，小白不会迷失方向而能快速上手，这就是一个好的信息架构设计，因为这个信息架构很低成本就和不同的人群系统连接起来了。
希望到这里可以解开你对信息架构是什么，怎么才算一个好的信息架构的疑问。
直到这里依然是概念阶段，我们来看看如何设计。
要设计连接能力突出的信息架构，需要从情景、内容、用户三方面去考虑完整。大部分情况下，我们都是直接按照自己的设计美感输出优化方案，最终效果总是不尽人意。
4.1 考虑情景
一个项目是由战略、文化、市场、技术、资源、政治和经济环境各种组成。
理解公司的战略目标，商业目标，目标的变化可能会影响：我们从一个进销存系统变成一个ERP系统，客户管理页面迭代成一个CRM子系统。
理解所处行业、市场、商家的信息：如果是新兴或科技行业，可以比较大胆超前的去设计架构，但如果是传统行业，信息化程度本来不高，需要有漫长的发展周期，那么架构需要保守，可用。
理解能提供的资源和技术上限：公司给予这个项目的资源和技术支持到什么程度，如果是战略级别项目，可能会配备顶级开发，最后迭代为一个中台项目。
理解其他如政治、经济环境等因素可能会造成的影响：如果项目是十分受经济波动和政治因素影响的，那么也需要提前考虑会影响信息架构，避免犯重大错误，例如制药的流程违规导致违法。
仔细看这些都是产品负责人所需要的技能，所以从另外一个角度来说，比较好的信息架构只有产品负责人能设计出来，其他人没有办法去做，一是没有足够的信息，二是自身技能还没点满。
4.2 考虑内容
内容所有权：不同信息的所有权所属不同。例如优惠券的信息则属于运营部门所有，但是活动效果却是所有部门公有的，这里面涉及到数据权限的设计、数据效果的展示工作。
内容属性：内容属于开放性还是非开放性的，属于哪些维度，可维护还是不可维护等。很多后台的操作都需要考虑到权限问题、操作闭环。
技术：关于数据库、大数据、数据格式等体系知识。特别是对于后端产品经理来说，需要对数据库知识、UML知识有一个了解。
数量：内容的数量有多少？需要放在哪里才能存储？客户上传的短视频，企业到底要存储多久呢，以后是否有法律风险需要调回查看？一个企业的备案信息，国家通常会保留很多年。
动态性：内容是如何变动的 ？变动的速度趋势是怎么样？增长率有多少，不同的内容的生命周期是怎么样的。用户的画像是否会随着数据和技术的发展，更加完善？用户的画像什么时候需要更新，什么时候需要重新评估 ，什么时候需要丢弃？
4.3 考虑用户
用户即使业务的目标群体，不过多赘述。
受众：用户群体，一个庞大的系统，有一个主群体，然后有很多分散的小群体（部门）。C端的产品一开始可能只有一种目标群体，但随着业务的拓展自然会瞄准更多的用户群体。B端的系统是分别给一个企业不同的部门用的，不用的部门又有岗位的区分，每个群体绝对有很大差异。
任务：每个大群体、大部门、小组织、个体需要完成的任务流程。多考虑功能的闭环和异常流程，考虑这个工作完对个体有什么影响，是否会让他舒畅的完成每一次工作？考虑业务流程实现后对该企业有什么影响，是否能带来可量化的业务价值？
需求：要考虑真正的需求本质，搜索和查找不是目的，完成任务/工作闭环结果才是。用户不在意对接的人工智能客服还是人工客服，能快速解决他的问题就可以了。
搜索和查找：大量的搜索和查找，怎么样才能优化效率，是否有完善的设计方法论？不同场景的搜索查找都有一定的设计方案，用户也一定有自己的搜索习惯，系统是去迎合还是打破？
整体体验：B端产品也有不同于C端产品需要的用户体验，产品体验可以分为两种：第一种我很懂你，你可以随便进行怎么做，整体过程感觉很好，但结果不一定保证（2C）。第二种是你只能按照我的要求做，但是我可以给一个很好的结果你（2B）。
不属于你的用户：考虑不属于我们的用户，即要考虑他们为什么觉得不好用 ，觉得其他竞争对手的产品好用。
设计者应该明确上述三点的定义，并且把这三点连接起来，由此才能设计一个连接性强的系统。这需要大量技能组成和实践经验，所以设计信息架构这个技能并没有那么简单。
不过对于大部分同学，先完善对信息架构的认知，再把认知转化为思考，慢慢运用到实际工作中，已经可以产生比较大的帮助。
五、总结
（1）在产品生涯中，我们总会遇到优化或重构系统的问题。这类型问题通常吃力不讨好，特别是在大公司。
（2）遇到棘手的任务时，需要把任务拆解成完成该任务所需的产品技能，快速习得该技能，输出解决方案。
（3）好的信息架构，应该可以能低成本与其他系统建立连接。但是信息架构存在悖论，本质是因为人与人之间认知差异造成的。即便没办法设计完美的信息架构，但是它能阶段式的解决问题，这就足够了。
（4）在优化或者重构系统之前，先思考情景、内容、用户，并且把三者连接起来，随时记着信息架构最重要的是它的连接能力。
（5）最重要的是：问题依旧存在，解决问题的工具也会存在，我们要接受不完美，但只要有效。
你当初是怎么去优化那个“看着都烦”的后台系统的呢？欢迎留言分享。
