I was asked to elaborate on this tweet, because it's admittedly dense. Example: If I'm trying to answer a question like, "What should the onboarding look like for GuidedTrack?" There are dozens of possible questions embedded within that.
Throughout my meeting notes, free writing sessions, research sessions (into topics immediately and indirectly related to GuidedTrack), etc., I've been collecting notes that all serve as potential inputs for this question. Literally hundreds or more blocks could help, gotta narrow
I pull up my [[open question]]s related to [[GuidedTrack]] or [[onboarding]] (I've been documenting as I go) and I add any more questions that I think of. At this point, I think about how I'll find that information. Questions will of course evolve as I find more "answers."
Some example questions:
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?
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?
I might look through the linked references to answer one question, find something helpful, which raises another question, causing me to look through LR in a different way. Advantage of this sort of search vs. queries? Agility.
Some of the main ways that I use queries: A. Save searches. Think of it like a set of filters that doesn't change. B. Ask more meaningful versions of a linked reference question.
Fruitful searches through my linked references get saved in the form of queries.
Fruitful searches through my linked references get saved in the form of queries.
Queries are indented under a line of descriptor text for the question it represents and tagged [[saved view]]. Via block reference/embed, I can look through past queries easily. Use this bit of CSS to make this more agile with text wrapping inline search. github.com/classicrob/Cur… 
I also might look through a set of linked references and find that it's unhelpful for the question I'm trying to answer. I write that down so I don't go down that path again next time. I don't want to waste time when I come back to this overall question, or ask similar questions.
Finding answers to multifaceted questions usually takes more than a day and take more than a single search. I want to get a better sense for my database by keeping track of what does and doesn't work. I also want to be able to pick up where I left off.
Affinity mapping into outlines- I keep track of the specific blocks that I like and I move them into an outline via block reference. If I notice a common theme between a few, I indent them under a header describing the common theme.
Block references are agile and link back to the original context. I'll add commentary on top as appropriate so I know why the blocks are included and I elaborate on my thoughts. Usually, by this point, I'm getting a clearer understanding of how to answer the research question.
These affinity maps/outlines give me a better 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 saved search process pages as well.
If answers start to come up at any point within this process, I feel no shame in stopping or pausing the process to write on this page. The point is to help me find clarity, not to lock me into a process. Systematic creativity and insight, not rigid structure needing completion.
Your queries represent questions to your past self. Block references are your past self's best answers. Your comments are the responses. Congratulations, the answer was within you the whole time. These are the most valuable pages I have.
“Hey Rob, what do you think about this?” “Hmmm let me collect my thoughts and get back to you”
