产品视角 on Hi, I'm 5key

Heptabase VS Tana，两种不同的知识管理逻辑

Wed, 05 Nov 2025 00:00:00 +0000

TL;DR

Heptabase 让你「看见思考」，Tana 让你「组织思考」，它们不是彼此替代，而是天然互补。

如果你想同时拥有快速记录的效率和全局思考的深度，不妨让两者并行使用。

为什么我要重新思考知识管理工具

2022 年，我离开了公司。十多年陆陆续续做的记录，随着电脑一起交还了回去。那一刻其实挺好，终于不用再去维护那些零散、混乱的信息了。

对我来说，这是一次从零开始的机会。没有历史包袱，也不用考虑数据迁移。我可以重新搭建一套属于自己的知识体系，围绕我接下来真正关心的领域和命题，重新构建思考的框架。

后来我陆续接触了 Heptabase 和 Tana。

这两款工具的思路完全不同，一个强调空间，一个强调结构。这几年里我也在它们之间来回切换，想找到一个最合适的方式，但却又始终没能真正解决我的问题。总觉得哪里不太对，却又说不清。

直到今年，我才慢慢意识到，问题并不在工具本身，而是我把自己困在了「All in One」的执念里。总想着在一个工具里解决所有场景的需求，结果什么都顾不上，也什么都没做好。

所以，这一期的文章，我想重新聊聊知识管理这件事。聊聊我这几年在工具之间的反复和困惑，以及我现在怎么看「如何选择一款知识管理工具」。

💡 如果你对知识管理方法论本身感兴趣，可以先看我之前写的 HQ&A 笔记法：让你的思考更有效，讲的是从「记录」到「理解」的三步思考框架，和本文聊的工具选择互为补充。

Heptabase vs Tana

这两款产品的特点其实非常鲜明，差异也很大。

从表面来看，Heptabase 更像是一个帮助你看清全局、发散思考的工具。它把笔记这件事彻底空间化，让你能像警察办案那样，在一块白板上把所有线索思路连接起来。

那些原本散落在各个角落的想法，突然被放在同一个平面里，变得可以移动、组合、连接。你能清楚地看到思考的路径，也能在重新排列的过程中，发现新的关系与洞见。

当然，让我真正决定付费的并不是当时的产品形态，而是它背后的理念。Heptabase 的核心并不是「记录」，而是「理解」。它让思考变成一个空间事件，而不是文字的堆叠结果。

创始人 Alan 对如何思考知识这件事的理解，远比市面上大多数笔记产品要深。大家感兴趣的可以去阅读一下他这篇文章。

Heptabase: My Vision Project Meta

而 Tana 的重心则完全不同。它关注的不是「全貌」，而是「结构」以及结构化之后组织信息的方式。

我一直很喜欢节点式、大纲型的工具，因为它足够简单、快速，最适合即时记录想法。

还在公司的时候，我用过很长一段时间 Logseq 和 OmniOutliner，它们都很好用，但问题也很明显。内容容易变得零散、粗放，彼此之间缺乏联系。每条笔记都像是一个孤岛，你知道它们存在，但很难串联成体系。

Tana 出现后，演示视频立马就吸引了我。它在大纲的基础上引入了 Supertag，让每个节点都可以带上语义结构。从「记录信息」变成了「组织知识」。

这种方式极大地弥补了 Logseq、OmniOutliner 在信息管理上的不足，也让我真正感受到笔记其实可以是「有逻辑的网络」，而不是一堆堆分散的文本。

当然，Tana 也是我接触过学习门槛最高的一款工具。

它不像 Heptabase 那样容易理解，而是要求你具备相当强的结构化思维能力。你得自己去定义、去构建、去设计那套逻辑关系。这个过程很难，也注定需要反复的尝试。坦白讲，我中途放弃过好几次，直到最近一年后才真正用顺手。

业务思考力，设计师跳出执行的起点

Mon, 31 Mar 2025 00:00:00 +0000

TL;DR

设计师跳出执行的关键，是建立自己的业务思考力。

两个最常见的认知错位：把 KPI 当成终点而不是线索（围着 KPI 做设计，但偏离了真正的业务目标）；把用户反馈直接等同于业务问题（响应症状而非根源）。

学会用业务视角反推设计决策，是从执行者走向决策者的起点。

我们一直强调，设计是要服务于业务目标的。但在实际工作中，这句话往往会变了味。

大多数时候，业务目标是由一系列数字呈现的。数字看起来明确、量化、可追踪，所以也就理所当然地变成了决策依据、优先级判定标准。但问题也就出在这里，我们每天面对的是 KPI，而不是目标本身，这就让设计工作很容易变得看起来合理，实际上却偏离了核心。

KPI 是起点，但并不是答案

KPI 本意是为了帮助我们从目标回推行动，但在实际工作中，它往往变成了另一种“任务指令”。指标一旦被拆解到每个人头上，就很容易变成一个明确的执行目标，而不再是一个值得分析的问题。

我们会习惯性地围着 KPI 做设计：DAU 要上涨，那就提升 Push 的频次；GMV 要提升，就改按钮、调样式；点击率要提升，那就多加俩弹层。

这些操作不一定错，但很多时候，它们只是“指标驱动”下的机械响应，而并未真正回到目标本身的去理解它的目的，从而反过来思考我们究竟应该选择什么样的路径和方法来达成？

事实上，很多的需求在流转过程中逐步失焦，并不是因为老板瞎定目标，也不一定是 KPI 本身出了问题，而是大家在拆解 KPI 时，把它当成了终点，而不是线索、问题。这也是最常见、也最隐蔽的认知错位。

KPI 是我们实现业务目标推理链路上的线索节点。你需要做的，是搞清楚它和目标之间的逻辑关系，以及它和当前设计工作之间的传导逻辑。

如果你发现这之间没有可验证的连接，那你就要停下来问一句：我现在做的，是为了实现目标，还是只是为了完成一个动作？

用户反馈不等于业务问题

如果说 KPI 让我们在执行上会失焦，那用户反馈的问题则往往会让我们在方向上跑偏。

很多设计师在面对用户的声音时，会本能地站在「同理心」的一边。我们习惯说，“要为用户而设计”，于是只要用户说“这个地方不好用”或者说“我希望能有某个功能”，我们就会将它们一通整理，然后写一个 PPT 告诉需求方，产品需要改进、体验需要优化。

这看起来很负责任，也很为用户着想，但同时也可能会出现跑偏的问题。

用户说的，真的是他的本质问题吗？他描述的是需求，还是他自己想象出来的解决方案？

大多数情况下，用户反馈的是某个体验层的卡顿感。比如“流程不合理”“步骤太多”“结构不清晰”。但这些感受并不等于问题本身，它们往往还存在着更深层次的问题。

你得顺着这些反馈往下挖。你要问的不是“他说了什么”，而是“为什么他说这个”。更重要的，是判断这个问题是否真的和我们的目标相关，是否值得投入资源去解决。

而判断的标准，不是谁的声音大、谁抱怨多谁就对（对于产品经理的沟通同理）。而是这个问题，是否来自我们真正要服务的那一类人、那一类场景？

不是所有用户的问题都需要被解决。一个产品的核心竞争力，恰恰来自于它知道该为谁解决问题，也知道不为谁解决问题。

所以下当一次我们面对用户的问题，不妨思考一下：这是症状，还是根源？是个体，还是代表？是“我们要服务的用户”，还是“我们暂时不解决的场景”？

看到这里，相信你对「设计师如何理解业务目标、判断需求价值」已经有了一些新的思考。

那么，后面的内容将更值得你深入了解。

在这篇文章剩下的付费部分，我将继续展开三个关键问题：

01. 如何判断一个需求值不值得做？
拆解业务目标，建立需求与转化路径之间的连接逻辑。

02. 如何构建自己的业务本体结构？
用一个案例，展示如何将获取到的信息转化为思考、决策的支撑。

03. 有了判断，如何把握时机？
不是表达得快就有效，而是要谋定而后动，选对节奏精准出手。

💡 延伸阅读：

如何用业务语言表达：设计的意义，得用业务语言讲明白

设计师未来的两种路径：设计师的下一站，成为架构师，还是走向业务？

长期视角：做了 5 年互动设计，我遇到了设计师职业发展天花板

欢迎订阅我的小报童专栏，解锁本期文章全文内容。

从「白板」开始你的设计工作

Thu, 13 Feb 2025 00:00:00 +0000

你会如何开启设计工作

很多设计师拿到一个新需求时，第一反应往往是习惯性的打开设计工具，比如 Figma 或 Sketch 开始设计。

为什么会这样？

其实这不仅仅是工作习惯的问题。更重要的是这些设计工具已经成为我们的“主场”，是我们的舒适区。就像工程师需要记录点信息时，第一反应是打开自己的代码编辑器。我们都在各自的安全领域中“安营扎寨”，在工具中舒适地“解决问题”。

这其实也并不是什么坏事，毕竟趁手的工具干起活来效率高。但问题就在于这种依赖性，其实会把我们“圈”得死死的，导致我们很多时候不自觉地陷入细节，而忽略了更重要的思考。

想象一下，当你打开设计工具，面对那些熟悉的界面和准备好的模板、组件库，会让我们不自觉地进入到设计的实现中，开始沉迷于界面设计的细节。一会改一个布局，一会调整一下组件的位置。于是，我们就掉进了细节的陷阱里，开始在“小问题”上耗费大量时间，最终不自觉地忽略了背后的更重要的业务需求、用户痛点，甚至我们本该考虑的设计策略，也是在最后评审时“反向推理”出来的。

设计得虽然好看，但可能并没有能真正的解决问题。

而事实上，一个真正好的设计方案的核心，并不是能画出多少炫酷的界面，而是是否能理解业务需求、分析用户问题、找到合适的设计策略。这些前期的思考环节做得足够扎实，最后的设计实现才能真正的站得住脚。

总的来说，一个好的设计方案，其实应该是：七分思考分析，三分设计实现。可是，现实往往是我们花了七成时间搞设计实现，剩下的时间都用来在思考上“打酱油”。

企业如何看待设计师的专业能力？

曾经，企业可能更关心设计师的技能树。你能掌握哪些设计工具？擅长哪些设计方法？能不能做出一些酷炫的交互原型？但现在，企业更在乎的是你能不能用设计帮助公司获得增长，帮助公司营利。

设计不光是为了好看，它最重要的任务是好用。能让用户更舒服地使用，进而带来商业价值。如果设计最后还是不能解决问题，再精致再华丽也不过是“空中楼阁”，根本不能为公司创造实际价值。所以，设计师的角色已经不再是做个漂亮的界面那么简单了，再好看的设计也不能忽视「生意」的本质。我们还得成为「问题的解决专家」。

AI vs 设计师，应该选哪个？

当我们还在死守专业的时候，不要忘记了在另一边还有一股“力量”在试图替代我们。随着这两年 AI 能力的突飞猛进，我们的传统技能，比如设计流程、画界面之类的活儿，已经越来越容易被机器取代。

以为对专业工具的操作和界面设计的能力就足够形成牢固的壁垒了吗？不好意思，AI 也能干，而且比我们更快，还没有情绪、不需要休息。虽然它们现在可能只具备一个实习生的能力，但它的“晋升”速度可能会比我们想象的快得多。

去年年底兴起的 Cursor、Windsurf，能够帮助我们直接完成需求文档到产品实现的路径。甚至更进一步的 Devin ，我们已经可以把它当成团队里的一位新成员，它们能做的事，可能比我们想象的还多。

虽然 AI 在设计实现方面的能会越来越强大，但这里依旧在某些方面暂时还无法替代我们。那就是对业务的理解、问题的分析、策略的制定，总的来说，就是我们对业务思考的能力。而这些，也正好是企业对不仅仅是设计师的每一个角色在当下最核心的期望。

从白板开始你的设计工作吧

我们前面提到，设计师的工作应该是“七分在分析，三分在设计实现”。也就是说，设计师应该花更多时间思考和分析，而不是直接进入设计工具进行细节的实现。

理解我们需要进行思路的转变不难，难的是如何实施。在我看来，工具是一个具备可行性的切入点。白板就是这种思维方式的具体体现。

白板不仅仅是一个工具，它是一个思考的空间，是设计师跳出工具局限，全面分析问题、构建解决方案的地方。

我在 Heptabase VS Tana，两种不同的知识管理逻辑里也聊过类似的思考：Heptabase 这类空间化白板工具的核心价值，恰恰就是把「思考」从线性文档解放出来，变成可以被看见、被移动、被组合的过程。设计的前期工作其实和它是一回事。

接下来的付费内容中，我将通过一个实际的案例，向大家展示如何利用「白板模式」进行设计的前期工作。确保我们的设计思路清晰，决策有依据。

设计的意义，得用业务语言讲明白

Wed, 08 Jan 2025 00:00:00 +0000

TL;DR

设计师和产品经理之间的争执，根本不是"你觉得不行、我觉得可以"的口味之争，而是双方在用不同语言系统沟通。

设计要被业务认可，需要用业务语言（数据、价值、KPI 关联）来重新表达。

本文介绍一个实用框架：功能价值指数（FVI），帮你把"我觉得这个体验更好"翻译成"这个改动能带来 X% 的业务收益"。

每一个重要的项目里，设计师和工程师都不会缺席。设计师负责将业务的想法界面化，工程师负责将这些界面和功能工程化。但几乎每一次项目中，设计师多少都会与产品经理、运营人员之间出现一些不同意见。有时候甚至会发展成争执，最终演变成“你觉得不行、我觉得可以”的局面，弄得大家都不太愉快。

问题出在哪？设计师和产品经理的逻辑难道就永远对不上吗？答案其实并不复杂。

我们工作的环境，始终是一个商业环境。而这个环境中，每个角色的目标与视角有着天然的差异。

运营人员和产品经理，是企业对商业需求的具体化表达，他们的目标非常明确：拉新、转化、留存、盈利。而设计师和工程师，尽管同样为这些目标服务，却更倾向于用自己的专业语言看世界。一个关注用户体验的美感与流畅，一个专注于技术实现的逻辑与效率。

这种视角的差异就像在用两种不同的语言互相喊话。设计师的“这交互更符合用户习惯”，和产品经理的“能不能提高点击转化率”，往往成了两种语言体系，彼此不理解，谁也无法完全说服谁。摩擦因此变得不可避免。

商业环境下，设计师的天然“劣势”

企业的核心始终是商业，而问题的本质最终也得用业务视角来解读。对于以专业视角为主的设计师来说，这是一个天然的劣势。我们精通设计的语言，但在商业这套逻辑中，却很难用专业的话语去表达设计的价值。

为什么设计师很难在业务的“牌桌”上拥有发言权？因为我们习惯把设计结果当成目标。而产品经理甚至是管理者更关注的是设计对商业目标的推动。

换句话说，设计师工作的重点不是“设计得好不好看”，而是“设计是否为商业提供价值”，最终是不是能解决业务问题。

产品经理关心的是最终的商业数字：这次改版能提升多少转化率？这个页面的点击量有没有提高？这条用户路径是否更高效？而设计师往往沉浸在自己的专业领域，视觉呈现、交互逻辑，甚至是一些设计师眼中的设计情怀。但如果设计无法转化成商业结果，那么在业务视角里，它可能就是“无效产出”。

这也是为什么，设计师可能在项目会上自信满满地展示了新设计，却被运营人员一句“这个流程复杂会不会降低转化率”击得无话可说。

设计师用体验的逻辑看待问题，但企业期待的是用增长和盈利的语言解答问题。

为什么设计师需要业务 Owner 精神？

我们常说，设计师需要具备“业务 Owner 精神”。这话听起来有点虚，很多人并不理解是什么意思？它不是让我们只用专业去解决业务问题，而是跳出专业视角，把自己当成业务 Owner，站在业务视角重新定义问题，看待设计。

业务 Owner 的视角是什么？

如果设计师在乎的是“这个界面好不好看”，**那业务 Owner 关心的则是“这个功能能不能帮我留住更多用户？”。**如果设计师想着“这个交互是否符合最佳实践”，那业务 Owner 关注的则是“这个流程是否能让用户更快完成操作？”。

简单来说，业务 Owner 精神就是要求你把业务的成败当成自己的责任，而不是单纯完成一张图、一套交互逻辑就算了。界面漂亮是一回事，但业务跑不动，你也得真心地发愁。

业务 Owner 精神不仅仅是调整视角的问题，还要求设计师在日常工作中主动去接触、理解业务的数据和问题。这就意味着，无论是设计方案的产出还是业务会议的讨论，我们的身份都应该是业务的 Owner。我们需要用业务发展的视角看待一切问题，设计只是我们最擅长的一项技能而已。

所有这些，都是在帮助你跳脱“专业”的局限，把设计的价值与业务目标紧密结合。

当设计师转为产品 Owner 时会发生什么变化？

在做了十多年的设计后，我开始转向了产品工作，一晃也五年了。当你真正开始为一个业务的生死负责时，思考方式针对会发生巨大的变化。每天我最关心的，不再是设计本身做得如何，而是更具体、更紧迫的问题：

用户量怎么样？
活跃度是否达标？
商业收入能不能支撑下个月的运营？

设计的确重要，但它只是这整个体系中的一环。每天琢磨如何让产品活下去时，你才会真正的体会到，设计不仅要服务于用户，更重要的是还得为商业目标负责。

于是，我会要求团队里的设计师要用业务的视角来看设计。如果一个设计对业务没有贡献，那它再精致也是失败的。

设计师需要从“设计好不好看”，走向“设计对业务有没有价值”。这样的转变并不意味着抛弃专业，而是要求我们从专业的层面出发，为业务创造更大的价值。设计是帮助业务实现目标的工具，而不是业务的负担。

而首先，我们需要从真正的理解业务开始。

理解业务的第一步,数据和设计的语言转化

企业中，业务目标的语言是数据：转化率、收入、月活、日活… 这些指标是衡量成败的信号灯。

产品经理常说：“这个页面转化率太低了，能不能调整一下流程？”设计师回答：“调整流程会牺牲体验啊，用户可能觉得麻烦。”

表面看起来，这像是两个无解的问题，实际上，这恰恰是我们在职场工作中最大的劣势。我们需要学会用数据和专业语言对话。我们需要学会用商业语言和专业语言对话。

设计师只有从数据中找到设计的依据，把自己的专业思考转化为商业逻辑，才能更好的与产品经理和运营人员进行同频的沟通。

也才能够更加成熟的思考设计于商业的价值。

如何正确地理解数据，并让数据真正为设计所用？关键在于为业务问题和设计方案之间建立清晰的关联。

首先要做的是切换到业务数据的视角，了解问题的本质，而不仅仅停留在表层的体验数据上。接着，还需要借助一套强有力的观察指标，帮助我们建立设计与商业目标之间的连接。

这不仅能论证设计的价值，也能让我们反思设计的必要性，确保每一个方案都在为业务增长服务。

在做设计中台产品的那个阶段里，有大量的时间在做汇报。我需要有一个能够同时面向于老板们和团队内的指标，来让大家对产品的有一个共性的直观感知。

所以我创建了一个观察指标，我将它称之为功能价值指数（FVI）。

在对 FVI 指标不断优化的过程中，我开始逐渐找到了一个商业与设计之间理解数据的平衡点。同时帮助团队更好地建立商业目标与设计之间的链路。