互联网的“产品结构图”应该如何绘制？在讲方法之前先要明白产品结构层在产品设计中处在何处位置，这里引用《用户体验要素》中十分经典的产品框架体系。

　　战略层：一个清晰的产品战略需要明确回答出两个问题：1.用户可以通过产品得到什么？2.我们可以通过产品得到什么？相对应的就是用户需求以及产品目标。（我们为什么开发这个产品）

　　范围层：根据产品侧重于功能型还是内容型，来进行区别分析，对于功能性产品，考虑的是核心功能的确定以及功能的优先级划分，许多工具型app，boss直聘；对于信息型产品，考虑的核心内容的确定以及内容的优先级划分，例如数据分析网站，数据作为信息。如今的产品的竞争越来越激烈，产品范围越来越综合，涉及功能也涉及内容。

　　结构层：搭建结构层涉及交互设计以及信息架构两个方面。交互设计是做用户在界面上的、完成任务的操作以及对信息的获取，实则就是分析用户、信息、用户和信息之间的路径。（流程图吗）；信息框架侧重于高效得将信息表达给用户，需要注意两个方面：1.呈现给用户得信息是否具有意义。2.将信息进行分类，使之成为体系。

　　框架层：进一步提炼结构，确定很详细得界面外观，导航和信息设计，结构层相当于搭了一层骨架，框架层则需要将骨架变得充实。

　　可以看到产品结构层处在中间的位置，正处在一个又抽象到具象的过渡阶段，也正如此，设计产品结构层也是产品设计中最考验抽象能力以及具象能力的阶段，在抽象层面上，需要对需求、功能、数据进行分类与组织；具象层面上，将用户需求具象化。

　　本文针对结构层进行详细得说明，介绍产品设计的方法（场景分类法、功能结构图、信息结构图以及产品结构图）并希望大家学会具象化以及抽象化的思维。

　　讲一大堆的概念会让大家产生似懂非懂的感觉，总感觉差那么一点，这里以阅读书籍产品为例子系统地讲解产品设计的思路以及方法。

　　前置条件：在范围层中确定了关于阅读书籍的各种功能，比如挑选书、加入书架管理自己的书，对书进行分组，晒书，读书，加入书签，浏览内容等等等，功能多且乱，如何做到有序的分类呢，运用场景分类法可以联系现实中的场景，并根据场景分类法行大致分类。

　　小明最近迷上了养生，想买一本关于养生的书进行钻研学习，于是乎，他便找到附近的一家书店。这家书店十分会做生意，门店有各种宣传海报，有本月畅销书籍的海报（畅销书推荐），名家推荐的海报（作者推荐），新书的宣传海报（新书推荐）等等，这些书籍都在书店的门口，读者可以十分方便的购买。哇，有最近热播的《长安十二辰》还有《破冰行动》，铁粉小明立刻各拿下一本。

　　开心之余，小明差点忘了自己是要买养生的书的，于是便往里开始寻找。聪明的小明发现书店的书架上都有分类名（分类），于是小明问服务员养生的书架在哪里（搜索），得知在2楼之后，小明便前往挑选，但是小明还是没找到，于是又问了边上的服务员（历史记录搜索），最后终于找到了养生的书架。

　　发现关于养生的书真的是太多了，小明便拿出几本书进行仔细阅读，小明很有方法，先是查看书籍的封面与作者，然后看看简介与目录，其次挑几章进行了解，最后看看这本书在豆瓣上的评价（看书评），最后的最后选择了流芳百世的《皇帝内经》。

　　小明拿着两本书前往收银台，收银员告诉小明，购买会员卡可以享受冲多少送多少的优惠获得，天那，买100送100等于赚100啊！小明立刻拿出钱包，购买了100的会员卡买单，收银员将小明的个人信息以及购书信息记录在书店的系统中。

　　回到家里的小明，兴奋不已，开始将两本小说加入自己的书架中，将《破冰行动》《长安十二辰》当到书架的第一层（加入书架），这一层全是小说（分组），然后躺在沙发上便开始阅读《皇帝内经》，简直太好看了，一定要分享给我滴朋友小花，于是小明拿起手机拍了书本的照片给小花。小明妈妈叫小明去吃饭，小明给书加了个书签。

　　然而它只是一个骨架，需要有血有肉才能成为一个产品啊。那血肉是什么呢？细心的朋友会发现在用户体验要素的结构层中的信息架构，没错血肉就是信息！大家肯定也听说过信息结构图吧，这里就介绍一下信息结构图。

　　功能结构图绘制完之后，需要思考一个问题，在这些场景中，涉及到了哪些对象，如果对编程有了解的朋友应该知道基于对象的编程思维，万物皆是对象~这里可以提出四个对象分别是：书、我、书架、评论。记住万物皆是对象，评论也可以是！

　　NICE！现在有骨架，也有血肉了，但它连产品的雏形也不能称上，需要将产品功能结构图图以及信息结构图整合在一起，才能呈现产品雏形，于是乎，产品结构图就诞生了！

　　这里就要仔细地给分析功能结构图，可以大致将大致功能分别设为首页、搜索、书籍详情页、个人中心、书架、阅读页六大功能页面，然后根据其子功能的权重划分优先级，再分别给其对象填充信息，慢慢地便呈现出产品结构图啦！

　　这里就不全部绘制出阅读书籍的产品结构图拉，就针对首页以及书籍详情页进行简单的产品结构图绘制，如下：

　　如果对你有帮助的话，记得点赞哟！还有欢迎大家关注我的公众号：大道产品，找我聊关于产品的话题~关注送超足的产品经理资源教程~大家一起在产品经理的道路上冲冲冲！

　　教程和图示网上一找一大堆，方法多种多样，因人、公司、业务而异，复杂程度参差不齐，不一定最专业的就是最适合你或你的团队的，所以无法给出具体教程，这里我简单介绍个小方法供参考：

　　将所有功能一一列在纸上，确定产品的核心功能（这属于设计方法了，这里不铺开讲目标导向），并以核心功能为主，将每个功能要实现的目标和可能的业务逻辑大概罗列在下面。

　　一个或多个功能可能会组成一个模块，便于架构师、设计师、开发工程师等几乎所有干系人理解，更便于用户使用，将功能用线条跟模块进行组合。

　　某些大功能或大模块可能会由多个子功能\模块组成，将他们依次用线条连起来，需要注意是将主模块、子模块\功能依优先级或从属关系画成树状图。需要注意的是，某些子功能可能和其他模块进行交互，或多入口，或各种各样的业务流，没错，都把他们用线条连起来，无非就是换个颜色的线条（通常会带箭头）。可以用Mindmanager或OmniGraffle等，工具不限，ppt也可以做到。

　　没错，就这么简单，这就是IA的制作方法，只是其中会涉及到很多设计方如目标导向，会涉及到用户使用场景，还有Taskflow、Pageflow等，这些都是扩展知识点。

　　另外最重要的一点，这个IA不是一次完成就ok了，应该是个闭环，每次的讨论、评审，或战略变更、业务变更，市场情况变化，产品经理和公司高管肯定会对产品做调整。

　　当然IA的制作方法多种多样，一定要结合自己公司业务特点、团队合作方式等，定制出最适合自己的方式，才能起到作用。

　　作者：王志强 链接：643167来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

　　信产品功能图：就是将产品的功能结构、逻辑表达清楚。简单的说就是产品使用操作的功能表现。产品功能图实际上就是一种结构化的产品原型。我们在梳理产品功能的时候，就会清楚这个功能有哪些表现方式，跳转到什么样的网页上，网页之间的互相关联等。详情请点击链接。。

　　什么是效能？通俗来讲，效能是指事物产生功效的能力，比如医疗领域可以用来评价一种药物产生的疗效。从企业或者团队的生产力上来讲，效能则更多是指产生预期结果的能力，也就是说效能关注的重点单位是时间内的生产力，是达成最终结果的能力及对最终结果的可预测性。简单来说效能就是获得你想要的结果的能力，侧重于结果的价值，而高效能就是以高标准达成预期结果的能力。因此，如何提高效能也成为近几年企业或者团队管理者的热门话题。那么在软件架构领域，如何设计一套合理的架构从而提升团队研发效能也是一个值得思考的问题。

　　在 BeeArt 的新版本的研发过程中，我们通过以 “模型驱动” 的方式，进行了一系列架构和开发相关的实践，从而提高团队的研发效能，使研发团队能够快速的验证和实现业务需求，以及更加灵活的响应业务的变化。

　　什么是模型？简单来说模型就是一个静态结构，而所谓建模就是对一类数据进行抽象后进而得到的一个静态模型的过程。比如 Iron Man 的模型，它表示的是 Iron Man 这类数据的抽象结构，包含了被建模对象的各种属性以及行为能力:

　　而通常在软件设计初期，我们可能不会过度深入的去关注模型具体的值属性有哪些，把关注点放在模型的身份 - Identity 和关联关系 - Association 上，先将业务流程的框架表示出来。可能你会想，模型不是静态结构么，为什么还能表示业务流程呢？通常我们在考虑模型间的关联关系时，会先思考两种关系，聚合 - Aggregation 和组 合 - Composition :

　　所以，虽然模型是静态结构，但是也表达了一段时间内的交互，流程就是模型的隐藏维度。模型图也就成为了可以准确表达业务流程的工具。开发不断打磨、精细化模型的过程，就是不断深入理解业务的过程，而且通常我们在实践的过程中会发现，这个过程也会不断地促进业务去思考，从而反过来驱动业务的合理性验证。这个过程也会自然的达成一个结果，开发侧与业务侧统一语言。在BeeArt，我们会通过将模型按照不同的业务场景进行实例化来反复的验证建模的正确性，例如下图是我们其中一个子系BeeArt Foraging的模型以及模型的实例化：

　　通过对业务场景的实例化，我们的模型设计似乎已经可以满足业务的各种需求了。但是除了基础的流程框架，我们还需要对模型进行进一步的验证和打磨，这时通常我们会进一步的去思考用户的交互设计。 在 BeeArt 的团队准则里有一条，No detailed hifi mock ups：Who works on the card, propose your solution until POs said ‘yes!’. 没错，我们不期望 UX 在一开始就设计好 Hi-Fi，开发只用照着现成的方案去实现，而是由开发先设计 Mockups ，再驱动与设计和产品侧的沟通，进而产出最终的用户交互设计。

　　我们希望通过 Design System Pattern 来与设计和产品侧进行有效的沟通， 而非在一开始就陷入对具体设计细节的讨论中。通过之前的建模过程，开发人员对业务知识的认知已经足以支撑他们对用户交互进行简单的设计，甚至一些不善于画图的开发（比如我）可以使用 Design System 现有的 UI 组件库以及 Mock Data 通过编码的方式快速的将纯静态的 Mockup 做出来，从实际效果上看，通过粗粒度的 Mockup 进行沟通，的确会大大减少和设计师们的讨论时间。

　　在 BeeArt 我们选择了 AWS 的 Cloudscape 作为我们的 Design System 的基础框架，它不同于其他传统的 UI 组件库，会提供更加丰富的 Patterns 和更多的可测试性的支撑，来方便我们快速的构建 Mockup，如下图：

　　通过对建模，我们还可以划分出系统的限界上下文，从而指导我们的架构设计。如下图，我们通过模型表示两个系统的上下文以及之间的关系：

　　从模型上的上下文间的关系来看，可以了解到核心系统与子系统之间的关系是类似于接口与实现的关系，即核心系统定义核心业务流程框架（Activity - Outcome），子系统完成对核心业务流程的特殊实现（Facilitated Activity - Board Outcome）。可以想象，随着业务的不断发展，一定会有更多的特殊实现出现，基于这个信息，我们将子系统设计为插件式的结构，方便未来可以更加灵活的扩展更多的业务可能性，如下图：

　　正如 Sensible Default Practices 一样，在 BeeArt 开发团队，我们期望能够 100% 的实践 TDD。那么要想实现 TDD，一个首要的条件就是需要制定一个合理的测试策略。通常我们会基于进程内的架构设计，以进程内组件为视角设计合适的架构策略，并且提供打样代码。例如 BeeArt Hive 系统的前端进程内架构设计如下图：

　　基于当前架构，我们的测试策略需要能够覆盖架构内的所有组件，并且在打样过程中，需要消除实现测试的不确定性，比如使用什么样的工具或框架进行测试，如何替身测试依赖等问题。当前系统的前端测试策略如下：

　　可以发现，在 BeeArt 我们全部采用了自动化测试的方式来规划我们的测试策略，那么对于前端而言，UI 视图（View）层的测试在大部分项目中都采用的是手动测试的方式，原因很简单，缺少能自动化验证 UI 样式效果的测试工具。那么我们如何解决这个问题呢？正如测试策略里描述的一样，我们通过 Ladle + Playwright 来完成 UI 的测试。

　　通过 Ladle 完成对 Story book 的编写，覆盖各种 UI 组件的渲染效果，然后使用 Playwright 对 Story book 的内容生成截图，通过比较和上一次截图的差异来断言 UI 测试的结果。例如 BeeArt 的导航栏，我们故意把选中菜单的高亮颜色改为，则会验证失败，测试结果如下：

　　由于在开发初期，会出现很多的不确定因素，这也是为什么我们没有办法在一开始就将模型的所有细节，比如值属性等全部设计清楚，当然软件开发的过程是一个渐近明晰的过程，那么如何在这个过程中更高效的完成产品的研发，减少重复劳动或者返工，同样是一个值得考虑的问题。 在 BeeArt 新版本的开发过程中，我们采用了前端先行的方式，期望由前端驱动出更加完善和详细的 API 设计后，后端再进入开发，从而避免因为前期的不确定性对后端进行反复的修改。 这也是一种常见的 CDC（Consumer-Driven Contracts）开发模式，通过前端的不断迭发，将 API 的设计细节逐渐完善，从而驱动后端开发，后端的实现目的更加明确，从而达到快速将内核稳定，减少返工的效果。内核问题，区分前端模型与核心模型。后端也能够根据相应的测试策略，比如 Contract Test 自然的进入自顶向下的 TDD 的节奏。

　　在整个软件开发的生命周期中，整个团队会产生大量的知识，其中可能包括了团队的业务知识、技术知识，甚至是各种敏捷实践相关的知识，那么如何做好知识管理是提高团队效能的关键。

　　关于知识管理，我们首先想到的可能就是写文档，但是如何写好文档呢？通常有一个较好的实践是 “代码即文档”，意思是规范代码的命名，例如对象参数名称，方法名称等都要足够表意，即使没有代码注释，也可以一眼就能知道代码的意思。但是如果仅仅关注于实现代码的 “代码即文档” 可能效果会比较有限。 比如，你想要复用一个别人写的方法或者组件，那么你可能无法快速地通过方法名或者注释知道它应该如何使用，它的使用场景有哪些？应该如何配置参数？会有哪些 Sad Path 需要注意 ? 这些信息通常可能需要进一步阅读代码内部的细节才能了解。 在 BeeArt，我们遵循的是 “测试即文档” 的实践，测试代码天然就包含了对被测对象的解释信息，你可以通过测试的 Setup 和 Teardown 来了解被测对象是如何装卸的，通过 Test Cases 了解被测对象的各种使用场景，包括 Sad Path，从而不需要深入代码细节就能够快速的了解一个方法或者组件的使用指南。而且由于代码是通过 TDD 的方式产生的，所以甚至不需要额外的成本，就可以产生一个十分详尽的文档，而且有自动化断言的保护，这些文档全部都是实时可信的，不会存在文档过期的风险。甚至为了方便大家阅读，我们采用了中文的方式对测试进行描述，如下所示。 基于 Ladle - Story book 的视觉测试：

　　正如上面所描述的那样，我们有业务模型、架构设计、测试策略、打样代码等众多知识产出，那么如果是刚上项目的新人，应该如何快速的了解和掌握这些知识呢? 在 BeeArt，虽然我们有完整的 Onboarding 文档，以及每次讲解 Onboarding 文档时的录屏，但是我们并不认为 Onboarding 就是看文档和看录屏，我们坚持每次由 “ 老人” 对 “ 新人” 进行口口相传的方式进行 Onboarding，当然过程可能还是对着 Onboarding 文档进行讲解，但是实际的效果远比让 “ 新人” 自己闷头看视频要好的多，而且这么做同样会加强 和巩固 “ 老人” 对于现有知识的理解。

　　在 BeeArt 的团队准则里还有这么一条：Roles are hats, not identities. Everyone put on the “BA”, “QA” hats from time to time. 为了提高团队成员对业务的认知，我们认为每个人都应该承担起 BA 的职责， 戴上 BA 的帽子，在 BeeArt 的研发过程中，在 IPM 前，也需要由开发和业务侧一起产出粗粒度的 Story 和 AC，开发也需要在开卡后自己将故事卡的 AC 补充完整。 这么做的效果是显著的，作为 BeeArt 的开发人员，我能够很自信的说我熟悉这个迭代里的每一张卡的 Scope，而且在几次由开发人员主持的 Showcase 会议上，开发人员能够独立回答各种关于业务甚至是产品愿景相关的问题。

　　Pair Programming 作为 Thoughtworks 的 Developer 的 Sensible Default Practice，一直由于环境等外部因素不方便推广，结对可以带来众多好处，比如写出更简单的程序，更好的设计，以及更少的缺陷的代码，但是无论是哪种结对方式， 其更加核心的目的是让开发可以轮换，让知识可以传递，不会因为某一个成员的临时有事而 Block 整个开发工作。 在 BeeArt，我们虽然没有采用 Pair Programming，但是会每日轮换故事卡。如何做到呢？这同样依赖于我们采用了 TDD 的开发方式AG九游会，这促使我们需要基于 AC 的验收标准为故事卡拆解任务，也就是通常我们所说的 Tasking。这里我们采用了黑马的二层分解法，基于 AC - Example - Task 的方式进行 Tasking，所有的 Tasking 都是基于目前的测试目的编写的，当团队成员逐渐熟悉了基于 TDD 的 Tasking 方法之后，轮转就自然发生了。我们只需要在交接的时候讲解一下 AC 和 Tasking 的完成进度，就能很快速的切换到另外一张卡上。

　　除了需要不断管理团队已有的知识外，作为软件研发团队，还应该时刻保持着对于新技术的学习和洞见，在 BeeArt 团队，我们会坚持每天一场 Session，每场大概 15-30 分钟，由团队成员轮流承担，从我加入团队至今大概 2 个多月的时间，团队已经产出了 50 多场 Session。

　　本来是打算写架构的，但结果写了一堆其他的东西，但每一样都与团队效能密切相关，正如我如今的认知一样，我认为架构师或 TL 并不仅仅只是一个技术型的角色，只是他更擅长使用技术手段来解决团队研发过程中遇到的方方面面的问题，比如如何让架构有更好的可测试性，如何让架构扩展性更强 来适应业务的变化，如何保证核心架构稳定隔离变化，如何让团队成员快速理解业务和技术知识等等。 以上就是我在 BeeArt 产品研发过程中的一些实践总结。

　　近些年， “研发效能” 被各大行业，各个大厂持续关注，成为了当下炙手可热的词语。 “研发效能” 不仅是衡量企业的研发产出，提升人才利用率的方式。更重要的是高效的研发效能，能帮助团队提升产品质量，更高效、更可靠、可持续的交付更优的业务价值，在快速发展的行业中不断推陈出新，取得竞争优势！ 当然，研发效能的提升需要涉及方方面面，包括企业的组织架构、舒适的研发环境、高效敏捷研发实践、健壮的产品架构等。此次BeeArt 技术文集「重视效能，协同开发」从研发效能衡量指标入手，以点带面的阐述了研发效能的提升之路，同时也能帮助读者避免一些场景的研发效能提升误区。相信各位读者从这里会找到适合你们自己公司、团队的研发效能提升方案。

　　楼上到了点，产品结构图是基于产品的信息结构图之上的，至于产品结构图的具体画法可以参考这篇博客