In my work I deal with a flood of information and manage many concurrent projects. I run a behavior design and gamification consultancy called Influence Insights. I’m also a behavioral product strategist for a startup studio called Spark Wave. In both roles, I work with multiple products simultaneously, applying what I learn and know about behavioral science, game design, and product design to apps so users are more likely to engage in the behaviors that make them successful in the app.

When user behavior doesn’t lead to user success, I’m tasked with understanding why said behavior isn’t already occurring, framing the problem in a useful way, and generating creative solutions.

I’m frequently taking in a lot of information from varied sources, while considering many diverse problems at once. I’m meeting with an assortment of different people who all possess their own interesting perspectives and questions. As a result, my database is chaotic, but that chaos has just enough structure to enable systematic synthesis and ideation when needed.

In a recent project, I was tasked with designing the onboarding system for GuidedTrack, a basic programming language/app that allows product creators and social science researchers with no coding experience to develop flexible experiments and basic apps. We’re doing an official launch soon (anybody can use it today, but we haven’t started marketing it yet). Before we launch, we want proper onboarding.

Roam, better than any other tool, allows me to allocate my attention in many different directions while ultimately consolidating when needed. For every project I work on, I take many sorts of notes:

  • Meeting notes, which are tagged with [[meeting notes]], the people who were involved, the date, and the topics of discussion within the outline.
  • Notes on my research into topics related to behavioral science and game design. These may or may not have been directly done for a specific project, but almost always end up useful.
  • Freewriting sessions, where I flexibly jump from thought to thought, topic to topic, and project to project, generating many ideas at once in Daily Notes. This is one of my favorite ways to work.

At this point, I have hundreds or even thousands of blocks that could help me come up with ideas about onboarding for GuidedTrack, many of which aren’t directly related to GuidedTrack. It’s time to structure chaos.

This means:

  • I need to narrow it down. There’s a massive amount of notes I could sift through and I have limited time, so I want to make sure my review time is as useful as possible.
  • This isn’t a sprint. Finding the best possible solutions to multifaceted questions takes days, even weeks. The point of this process is to provide inspiration/clarity, limit wasted review, and crucially, allow me to pick up where I left off.

I start by making a page. I call these pages Looking Lenses, but you could think of it as a multi-step saved search process.

I pull up my [[open question]]s related to [[GuidedTrack]]. I’ve been documenting these whenever they come up. I find that understanding a problem and designing a solution comes with many questions. When they’re project specific, I turn them into todos. This gives me a starting point rather than a blank page. I’ll spend some time writing responses to those questions, developing the questions into new formulations, and adding any new questions that I have.

Some example questions include:

  • How does [[onboarding]] relate to [[search behavior]]?
  • What are {[[GuidedTrack]] [[user goal]]s}, and how does that relate to their {[[first ten minutes]] or [[continuous onboarding]]}?
  • What [[user feedback]] have I seen from [[GuidedTrack]] users?
  • What [[onboarding]] solutions have I seen work for other apps?
  • What other details of the [[GuidedTrack]] [[persona]]s do I need to consider?

These are the sorts of questions that can be turned into queries, which are basically a search into your database using the power of logical operators. I keep a list of tags of related ideas on some of the more general pages, like search behavior or onboarding. This helps me improve my queries or develop better questions. For example, maybe I don’t explicitly link onboarding and search behavior, but I link onboarding and information foraging theory. Tags metadata helps me to keep track of those possibilities so I can set up my queries to capture that for the sake of this search, [[information foraging]] and [[search behavior]] are referring to the same thing.

Some of the main ways that I use queries in this context:

1. Saved searches! Sometimes it’s more agile to simply look through the linked references for a page, but after, I’ll turn them into queries. This way, I know what I’ve already looked through and can pick up where I left off when I revisit this page.

If a search works out to be unfruitful, then I’ll delete the query and explicitly write down: “Asking my database for _ was unhelpful for the purposes of this project.” My database is massive and I’m only about five months in – I want to get a better sense for my database by keeping track of what does and doesn’t work.

2. Queries also allow me to ask more meaningful questions than linked reference filters do. See this video for details.

As I’m processing my queries, I’m keeping track of the specific blocks that seem most relevant to the goal of this research project and block referencing them into an outline in the sidebar. If I recognize a common theme between blocks, I group them together under a heading. I’ll also add a layer of commentary next to block references, providing myself context for why it was included in the outline if it’s not self-evident.

These outlines give me a deeper understanding of how previous pieces of thought map together and where the gaps are. If I need new information, I document my searches on the web on these looking lens pages as well.

It’s my personal preference to have the outline on the saved search process page, and control-shift-o to open that block in the sidebar. Fun trick – you can rearrange your outline easily through drag-and-drop by opening the outline in the sidebar next to the outline.

If answers start to come up at any point, I feel no shame in stopping or pausing the process to write in the additional thoughts section of the looking lens page. The point of this is to help me find clarity, not to lock me into a process. This approach works beautifully for that purpose.

Following a process like this, you end up with something that models a conversation. Your queries represent questions to your past self. Block references are the best answers. Your comments are the responses. Congratulations, the answer was within you the whole time. These are the most valuable pages I have.

My system is still being built and subject to change. To see an early version of how this was being conceptualized a few months ago, see here:

Below is an image of what these pages end up looking like (reproduced, sanitized, and reduced in size for viewing by the public).