<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Natália Kováč]]></title><description><![CDATA[Natália Kováč]]></description><link>https://natalia-kovac.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Tue, 03 Nov 2026 04:49:19 GMT</lastBuildDate><atom:link href="https://natalia-kovac.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Research first: how I turn a pile of sources into a draft]]></title><description><![CDATA[A simple process for collecting, checking and organising information before you write the first sentence]]></description><link>https://natalia-kovac.hashnode.dev/research-first-how-i-turn-a-pile-of-sources-into-a-draft</link><guid isPermaLink="true">https://natalia-kovac.hashnode.dev/research-first-how-i-turn-a-pile-of-sources-into-a-draft</guid><category><![CDATA[writing]]></category><category><![CDATA[research]]></category><category><![CDATA[content writing]]></category><dc:creator><![CDATA[Natália Kováč]]></dc:creator><pubDate>Wed, 21 Oct 2026 17:57:01 GMT</pubDate><content:encoded><![CDATA[<p>When a draft fights me, the problem usually isn't the writing. I started before I knew what I thought. When the research is done properly, the draft almost organises itself. When it isn't, I end up rewriting the same section four times because I keep discovering things halfway through.</p>
<p>So I treat research as its own stage. A text file or a spreadsheet is all it needs.</p>
<h3>1. Start with questions, not a topic</h3>
<p>A topic like "remote onboarding" is too wide to research. You can read about it forever. Before I open a single tab, I write down the questions the finished piece has to answer. For example:</p>
<ul>
<li>Who is this for, and what do they already know?</li>
<li>What decision or task is the reader facing?</li>
<li>What are the two or three things they most need to understand?</li>
<li>What would a sceptical reader push back on?</li>
</ul>
<p>Those questions become my reading filter. If a source doesn't help answer one of them, I can skip it, however interesting it looks.</p>
<h3>2. Keep a source log</h3>
<p>Every source I use goes into one list with the same few fields:</p>
<table>
<thead>
<tr>
<th>Field</th>
<th>Example</th>
</tr>
</thead>
<tbody><tr>
<td>Source</td>
<td>Title, author or organisation</td>
</tr>
<tr>
<td>Where</td>
<td>Link, book and page, or "interview, notes from call"</td>
</tr>
<tr>
<td>Date published</td>
<td>So I know how current it is</td>
</tr>
<tr>
<td>Date checked</td>
<td>When I last confirmed it still says this</td>
</tr>
<tr>
<td>Key point</td>
<td>One line, in my own words</td>
</tr>
<tr>
<td>Exact quote</td>
<td>Only if I might quote it, copied word for word</td>
</tr>
</tbody></table>
<p>The last two columns matter most. Keeping my summary separate from the exact wording stops me from accidentally presenting my paraphrase as a quote, or a quote as my own idea. It also makes fact-checking at the end much faster, because I'm not hunting for "that article I read on Tuesday".</p>
<h3>3. Check sources before you trust them</h3>
<p>Not every source deserves the same weight. Before something goes in the log as a fact, I ask a few quick questions:</p>
<ul>
<li><strong>Who is behind it?</strong> An organisation with expertise, a company selling something, or an anonymous page?</li>
<li><strong>Is it the original?</strong> If an article cites a study or a report, I try to find the study itself. Details often get lost or bent along the way.</li>
<li><strong>Is it current?</strong> A guide from years ago can still be right, but for anything technical, legal or about prices, I look for something recent.</li>
<li><strong>Does anyone else say the same?</strong> One source is a lead. Two independent sources are a lot more comfortable.</li>
</ul>
<p>If I can't check a claim, I either leave it out or say clearly that it comes from one source.</p>
<h3>4. Separate what sources say from what you think</h3>
<p>While reading, I keep a second short list called "my take". This is where my own reactions go: patterns I notice, places where sources disagree, things that surprised me, gaps nobody seems to cover.</p>
<p>This list is usually where the actual angle of the piece comes from. The sources give me facts; the "my take" list tells me what I want to say about them. Keeping them apart means I always know which parts of the draft need a citation and which parts are my argument.</p>
<h3>5. Look for the gaps</h3>
<p>When I think I'm done, I go back to the questions from step 1 and mark each one:</p>
<ul>
<li>answered, with at least one solid source</li>
<li>partly answered</li>
<li>not answered</li>
</ul>
<p>A "not answered" question has three possible fixes. I research more, I cut the question from the piece, or I'm honest in the text that the answer isn't clear. What I try not to do is fill the gap with vague sentences that sound confident.</p>
<h3>6. Outline from the questions</h3>
<p>Only now do I outline. Each question becomes a section, roughly in the order a reader would ask it. Under each heading I paste the relevant points from the source log and the "my take" list. When I start writing, every section already has its material, and the job is to connect it in clear sentences.</p>
<h3>Knowing when to stop</h3>
<p>The hardest part of research first is stopping. There is always one more article. My rule of thumb: when new sources mostly repeat what's already in my log, it's time to write. If something important turns up later, the log makes it easy to slot in.</p>
<p>It feels slower at the start, but the draft needs fewer rewrites and the final fact-check goes much faster.</p>
<p>How do you handle research? Do you collect everything first, or research as you write?</p>
]]></content:encoded></item></channel></rss>