How to do research with modern note-taking tools?

詹雨安 Alan Chan
8 min readJun 24, 2022

English Version / 中文版請點擊或往下滑


Modern note-taking tools (e.g., Heptabase, Roam Research, Notion) are powerful. They provide features such as whiteboards, bi-directional links, block-based editor, database, etc., that allows us to interact with our thought in new, powerful ways.

However, giving you a pen doesn’t mean you’ll write like Hemingway; these powerful features in modern tools also won’t make you think like Einstein if you’re not conscious of the way you use them. Instead, it’s easy to result in a giant bi-directional linked graph or a messy whiteboard with hundreds of cards without knowing how to use them.

In this article, I want to share how I, a creator of one of the modern tools called Heptabase, use my tool to achieve my goal. I do not intend to teach you the ‘right way’ of using these modern tools. Instead, I want to help you see the real potential behind these tools and figure out your own way of using them.

Capabilities of modern tools

When using a new tool, we should always be conscious of two things:

  1. What’s my purpose for using this tool?
  2. What new capabilities does this tool provide?

Early-stage startup founders, like me, spend most of our time doing user & product research. My purpose in adopting a new tool is to help me do better research.

When I first started using Heptabase, I knew its features provide three capabilities for doing research:

  1. Whiteboard: Capability of gaining a deep understanding of a topic in a spatial context.
  2. Bi-directional link: Capability of moving and filtering information from one textual context to another.
  3. Card Transclusion: Capability of reusing information in multiple spatial contexts.

Research is the process of creating knowledge from information. To create knowledge, we must put information under a context to gain a deep understanding and new perspective of this information — that’s how the first capability comes into play.

However, the context of how information is acquired is often different from the context of your research. Therefore, research usually requires moving, filtering, and reusing information from one context to another. That’s when the second and third capabilities become useful.

Now we can see how I use these three capabilities to help me do user & product research.

Example: User & Product Research

Every product solves problems for its users. When building a product, the more we know about our users, the better we can solve their problems. Therefore, my everyday job is converting tons of user feedback and feature requests into an understanding of user personas and user problems.

When doing user & product research, I have to move information across three contexts constantly: feedback and feature requests on discord community (context 1) → user personas and user problems (context 2) → design problems and possible solutions (context 3). Let’s see how I perform this process in practice.

Context 1 → Context 2: Overview

Startups don’t solve problems for a single user (e.g., AlanChan#1234). We solve problems for several user personas (e.g., Researchers, Project Managers, etc.)

For example, AlanChan#1234 requested a feature of using a whiteboard to read PDF files. Instead of building what he told us to build, we asked him questions to learn more about his background and why he requested this feature.

It turns out AlanChan#1234 is a Ph.D. student, and when he’s reviewing his research notes, he finds it difficult to retrieve the source that inspired him to take these notes, and all the sources are stored in PDF format.

Therefore, AlanChan#1234’s user persona includes Researcher and Student, and one of his user problems is “When I’m reviewing my research notes, I find it difficult to retrieve the source.”

After we understand the user problem, we might not solve it immediately. Hence we want to ensure that when we want to solve problems for Researchers in the future, AlanChan#1234’s user problems will re-surface.

Context 1 → Context 2: Practice

In Heptabase, I have created a process to convert feature requests into an understanding of user personas and user problems. The process includes three types of cards:

  • Persona cards, such as “Researcher”, “Project Mangers”, “Software Engineers”, etc.
  • User cards, such as “AlanChan#1234,” “Yeefun#5678,“ etc.
  • Feature request cards, such as “Heptabase Feature Request (2022/06).”

In feature request cards, I write feature requests in the format of a link to a user card (e.g. AlanChan#1234) + feature description (e.g., I want to use a whiteboard to read PDF). With this format, when I open AlanChan#1234’s card, I can see all his feedback and feature requests in the backlink section.

Using this information, I can better understand AlanChan#1234’s user problems. I will then link AlanChan#1234’s card to its persona cards (e.g., Researcher, Student) and write down his user problems under the persona card links.

Now, when I open the backlink section of a persona card, such as Researcher, I can see all user problems from all users who have linked to this persona. By weighing these user problems, I can determine the most significant user problem researchers face.

In Heptabase, I’ve put all the cards mentioned above: feature request cards, user cards, and persona cards, on a whiteboard called “Heptabase Users Feedback (2022.06).” This whiteboard allows me to create a pipeline of processing information and group user cards based on their status.

In this pipeline, we have the feature request cards as input, persona cards as output, and user cards as an intermediate layer that helps us convert feature requests into an understanding of user personas and user problems.

Context 2 → Context 3: Overview

After I understand user personas and problems better, I can use this information to determine the priority of which user problem we should solve first and start thinking about design problems of this user problem.

For example, the user problem “As a researcher, when I’m reviewing my research notes, I find it difficult to retrieve the source” can introduce many design problems, such as:

  • I want to create notes while reading my sources and link them automatically.
  • I want to store my sources within my notes.
  • I want to integrate my note-taking system with my source-manager.

Different design problems will lead us to different solutions. For example, the first design problem might result in allowing whiteboard to read and break down PDFs, the second might result in allowing uploading PDFs to a card, and the third might result in integration between Heptabase and Zotero or Mendeley.

When thinking about design problems, we have to be careful about choosing the right problem and not falling into a solution too fast. It is important to constantly reflect on the original user problem, compare all existing solutions (i.e., how other products are solving this user problem), and think about whether there are new ways to solve it.

Context 2 → Context 3: Practice

In Heptabase, I have created a process that converts a user problem into a design solution.

For example, last month, I was trying to solve the user problem of “As a researcher, I find it difficult to convert daily fleeting ideas into knowledge that’s useful for my research.” Many users create cards with only a title or one sentence and don’t know how to make use of them afterward.

To solve this user problem, I created a whiteboard called “How to convert fleeting ideas into useful knowledge.” I reuse the Researcher’s persona card on this whiteboard as a starting point to see all related feature requests to this problem.

Whenever I have a new idea about how to solve this problem, I create a new card on this whiteboard. I also looked into many other tools (e.g., Roam, Obsidian, Mem) to see how they solve this user problem and create a summary card for each on the whiteboard.

After a while, I have many cards on this whiteboard — related feature requests, new ideas and insights, existing solutions, different angles of understanding the problem, words from our users, etc. I was constantly rearranging cards, merging and dissecting them, and eventually converting them into a finalized structure.

The finalized structure allows me to create the design of a new feature — Journal. So far, most users like it and think it helps solve the problem much better than our original Timeline feature.


In the above example, you can see that I’ve been using the capabilities Heptabase provided to do my research. I used bi-directional links to convert feature requests into user personas and problems. I used card transclusion to convert a user problem into design problems. I used a whiteboard to convert design problems into feature spec.

Here are the core lessons we learned from the above example:

  1. When using a new tool, be conscious of the new capabilities it provides and your purpose for using the tool.
  2. Try to design a process that utilizes these capabilities to fulfill your purpose.
  3. Always think about the input/output of the process before you start taking notes.

In Douglas Engelbart’s Augmenting Human Intellect: A Conceptual Framework, he didn’t just talk about the new capabilities computer can provide. He emphasized how these new capabilities can introduce new, powerful processes to augment our thinking. When talking to users of these modern tools, that’s something I’ve seen most people miss. I hope this article can raise your awareness of it and inherit Engelbart’s spirit when using a new, powerful tool.


現代筆記工具(例:Heptabase、Roam Research、Notion)非常強大,提供了白板、雙向連結、區塊編輯器、資料庫等功能,讓我們可以用全新的方式與知識和想法互動。





  1. 我使用這個工具的目的是什麼?
  2. 這個工具提供了什麼樣的新能力?


我在初次使用 Heptabase 時,知道它的功能提供了以下三個能幫助我做研究的能力:

  1. 白板:在一個空間脈絡下深度思考一個主題的能力。
  2. 雙向連結:在多個文字脈絡之間傳送和過濾資訊的能力。
  3. 卡片複用:在多個空間脈絡之間重複使用資訊的能力。

做研究的本質,就是透過資訊創造知識。要創造知識,我們必須將資訊放在一個特定的脈絡下,建立深刻的理解與新的觀點 — 這就是第一項能力有用的地方。





在做用戶和產品研究時,我必須將資訊在三個脈絡中轉換:用戶在 Discord 社群的反饋和功能請求(脈絡一)→ 用戶畫像和用戶問題(脈絡二)→ 設計問題和潛在解法(脈絡三)。下面是我完成這個轉換的流程。

脈絡一 → 脈絡二: 概覽


舉例來說,用戶 AlanChan#1234 要求我們讓白板可以讀取 PDF 檔。我們並不會直接幫這位用戶做他要求的功能,而是會問他一些問題,像是他在做什麼工作、他為什麼需要這個功能?

我們發現,AlanChan#1234 是一個博士研究生。當他在複習他的研究筆記時,他發現他很難找到讓他記下這些筆記的原始文獻,也就是一堆 PDF 檔。

由此可知,AlanChan#1234 的用戶畫像包含了「研究者」和「學生」,而他其中一個用戶問題是「當我在複習研究筆記時,我很難調出該筆記的原始文獻」。

我們現在知道 AlanChan#1234 的功能請求背後的用戶問題了,但我們不一定會馬上解決這個用戶問題。也因此,我們希望未來當我們想要幫「研究者」這個用戶畫像解決問題時,AlanChan#1234 的用戶問題可以重新浮現在我們眼前。

脈絡一 → 脈絡二: 實作


  • 用戶畫像卡片:例如「研究者」、「產品經理」、「軟體工程師」。
  • 用戶卡片:例如「AlanChan#1234」、「Yeefun#5678」。
  • 功能請求卡片:例如「Heptabase 功能請求(2022/06)」。

在功能請求卡片中,我寫的每一個功能請求都會包含發請求的用戶(例:AlanChan#1234)以及請求的內容(例:我希望能用白板讀取 PDF 檔)。這樣的格式可以讓我在打開 AlanChan#1234 這張卡片時,在反向連結的欄位看到這個用戶過去發過的所有反饋和功能請求。

這些反饋和功能請求的資訊將會讓我對 AlanChan#1234 的用戶問題獲得更深的認識。我接著會從 AlanChan#1234 的用戶卡片提及他對應的用戶畫像卡片,也就是「研究者」和「學生」,並在這些用戶畫像卡片的連結底下寫下與他有關的用戶問題。


Heptabase,我會將上面提到的所有卡片(功能請求卡片、用戶卡片、用戶畫像卡片)全部放到「Heptabase 用戶研究(2022.06)」這個白板裡頭。這個白板讓我可以很清楚地看到一套流水線,每一種類型的卡片都會根據他被處理的狀態添加不同的顏色。


脈絡二 → 脈絡三: 概覽



  • 我希望在閱讀文獻時,創造與文獻相連的筆記。
  • 我希望將我的文獻存在我的筆記裡頭。
  • 我希望能將我的筆記系統和文獻管理系統整合再一起。

不同的設計問題會導致不同的解決方案。第一個設計問題可能導致我們做出讓用戶用白板閱讀和拆解 PDF 的功能,第二個設計問題可能讓我們做出讓用戶在卡片中上傳 PDF 的功能,第三個設計問題可能讓我們做出將 Heptabase 和 Zotero 或 Mendeley 整合的功能。


脈絡二 → 脈絡三: 實作




每當我對解決這個用戶問題有新的想法時,我就會在這個白板建立新的卡片來紀錄想法。我也研究了很多其他工具試圖解決這個問題的方式(例:Roam, Obsidian, Mem),並將它們的作法建立總結性筆記放到白板上。


這個收斂出來的結構幫助我完成了 Journal 這個新功能的設計。截至目前,大部分的用戶們都很喜歡 Journal,認為它比我們原本提供的 Timeline 功能更好地解決了「如何將零散的靈感轉換成有用的知識」這個問題。


在上面的例子中,你可以看到我不斷地在使用 Heptabase 提供的能力來進行我的研究。我使用雙向連結將功能請求轉換成用戶畫像和用戶問題、使用卡片複用將用戶問題轉換成設計問題、使用白板將設計問題轉換成功能設計。


  1. 當你在使用一個新的筆記工具時,最好先暸解這個工具提供了什麼樣的新能力,以及你使用這個工具的目的是什麼。
  2. 試著思考你可以怎麼使用這些能力設計一套流程來達成你的目的。
  3. 在記筆記之前,先想想你設計的流程的輸入是什麼、輸出又是什麼。

Douglas Engelbart 在 Augmenting Human Intellect: A Conceptual Framework 這個經典著作中不只提到了電腦能提供什麼樣的新能力,更強調了這些新能力可以讓我們創造什麼樣的流程來強化我們的思考。在和很多現代筆記工具的用戶對話時,我發現人們很常忽略了流程的重要性。我希望這篇文章能幫助你重新思考你的筆記流程,繼承 Engelbart 的精神,更好的使用現代筆記工具來達成你的目標。