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