信息架构的理解与实际运用.docxVIP

信息架构的理解与实际运用 一提到信息架构，相信大家第一反应就是脑图，比如 Xmind、幕布等。 过去，我在学习产品经理必备的工具时，看到别人分析产品，是用脑图将所有信息穷举出来。所以我也一度认为，信息架构就是用脑图穷举信息。 在工作中实践的多了，我才发现自己是将「思维方式」和「实现手段」搞反了。简单说，我是要梳理信息，才要借助脑图帮我梳理思路；而不是用脑图梳理后的结果，才是信息架构。 切入理解的点不同，也会直接影响你后续行为方式。下面，我会结合自己的经验，谈谈我对信息架构的理解。 一、什么是信息架构？ 首先，我们从全局的角度理解信息架构。 业务架构 → 产品架构 → 信息架构，这本身是存在递进逻辑的。 1. 业务架构 是包含产品目标和用户需求的核心，也是产品运作的核心；而业务逻辑，是连接业务架构与产品架构的桥梁。 2. 产品架构 具体表现在产品的模块与功能，再通过业务流程向下连接。 3. 信息架构 细化到每个小功能点以及信息，展现在用户面前。到这里，你可能会觉得产品架构和信息架构差不多，为了区分我举个小例子： 先看左侧微博的视频和动图自动播放，属于功能，并且处于产品架构。而下面的 3 个选项，对应的是信息架构的小功能点，可以理解为信息。 到这里，可能细心的你会发现，为什么微博会有 3 个选项，而微信只有两个？ 对比后发现，微信其实是对“仅 WiFi ”做了简化，也就是微信在 WiFi 下是默认自动播放的。因此，就只剩下 4G 播放和关闭两个选项。 而既然是两个选项，组件用开关表示即可。说句题外话，我们手上 App 每个功能的背后，背后都有一定逻辑。 都可以从「目标用户」和「使用场景」两个维度做大致的分析，并在自己设计功能时参考这些理念。而这，离不开我们对信息架构的理解与运用。 二、信息架构运用 谈完对信息架构的宏观理解，接下来阐述信息架构运用的实际案例。 1. 信息架构是否要独立存在？ 当业务、产品相对简单的时候，产品架构和信息架构可以是混在一起的。 比如我负责的 App，最近在做功能架构的调整，以及业务流程闭环的设计，思考时就用到了信息架构。 在分析时，我就会自上而下的做分析，为的就是将逻辑梳理清楚。这其中最重要的部分，是功能整理、业务逻辑和操作路径。 边梳理边思考、边思考边整理问题，一点点发现问题，做到逻辑不遗漏。当然，如果有过往的产品文档可以帮我们省下不少时间。 很多人包括我，肯定都有学过各种课程，教给我们要分开梳理，逻辑才清晰。我只想说，不要拘泥于形式，混用产品架构和信息架构，能够帮你更好的厘清思路，做出判断。 2. 信息架构应用在 SQL 查询 没想到吧，信息架构的分析方式还能用在这里，下面做个简单的介绍。 1）产品概述与背景介绍 一句话概括，我负责的产品是将线下巡检线上化。 简单说，就是 PC 端录入检查标准，指派给 A 角色执行任务，他的 App 上会收到这条任务。然后 A 角色到门店里照着任务检查，完成后提交。 这个过程，如果发现门店存在问题，比如卫生消毒做的不好，会扣分并填写反馈说明或上传图片。 2）问题 目前我们 App 没有限制对检查项在判定违规时，要求 A 角色必填说明和上传图片。而客户反馈说，会有部分人忘记填写，但这个从业务上来说是必填，希望我们能解决这个问题。 3）解决方案 必填这件事首先是合理的，其次是到底要必填什么？ 拆分一下可以分3种： 仅文字必填（个人倾向于此方案）； 仅图片必填； 文字和图片都必填。 别小看了这个细节，毕竟一个任务里面多的有 50 个检查项，必填行为是会给实际操作者增加不小负担的。 产品既要考虑到管理者诉求，也要考虑执行者的压力。对此，我需要查询了解大部分用户的使用习惯，也就需要拉取过往数据。 信息架构的具体使用方式如下图： 当然，这过程中肯定少不了调整，但只要思路和方向时对的，就不存在大问题。在信息架构这件事上，我自己也有了不少思考，也跟你分享一下。 三、理论与实践结合，就是你的方法论 读书时我有个朋友，英语学得特别好，听力、阅读理解、小作文样样拿得出手。 不过从来没有注重对话能力，毕竟考试也不考这个。等出了国，碰到了外国人，交流时慌得不行，沟通几句就没然后了。 我们当时笑他，考那么高分有什么用？ 1. 理论要落地，光说不练假把式 说起来，英语和产品有一点很类似，都是实打实的落地学科。 英语，你要能真的做到沟通，最起码听得懂，回得了；实在碰到不懂的词，上手比划都可以。别笑，外国人学中文可比我们好玩的多得多。 回到产品，你要能真的做好分析、设计、对接、上线。有自己的行为习惯和准则，并能实打实做得好，而不是纸上谈兵。 真的，很多人可能只会说，真到自己手里做得比谁都差。 2. 理论是我们前进的助推器 继续刚才的故事，那位同学的英语成绩真的就没用了吗？ 不是的，他只是心态上不行，