People often ask what a template designer actually does all day. The honest answer involves a lot of staring at the same page and moving one line of text down by four pixels. But there’s a real process underneath, and I thought it might be useful — or at least interesting — to walk through how a template goes from a vague idea to something you can duplicate into your own workspace.
Every template starts with a feeling, not a feature list. The journaling template began because I wanted a page that felt like opening a nice notebook — warm, uncluttered, a little bit special. I wrote that feeling down before I touched Notion: ‘like a linen-bound notebook on a Sunday morning.’ Everything that followed got measured against that sentence.
Next comes the skeleton on paper. I sketch the pages as simple boxes — what goes on the daily page, what lives on the monthly page, where the navigation sits. Paper is faster for this because I can’t get distracted by fonts. I usually draw three or four versions of the same page and pick the one that feels calmest. Calm almost always wins over clever.
Then I build the first draft in Notion, and it’s always bad. The first version of the goal-setting template had eleven linked databases. It was technically impressive and completely overwhelming. I deleted most of it and started over with three: one for yearly intentions, one for monthly check-ins, one for weekly actions. The constraint made it better.
After the structure settles, I spend an unreasonable amount of time on typography and spacing. Notion’s defaults are fine, but ‘fine’ isn’t the goal. I use callout blocks with soft background colors for prompts, add generous blank space between sections, and keep headings small so they guide rather than shout. The test is whether the page feels good to scroll through slowly. If I find myself scrolling fast, something’s wrong.
Then comes the part most people don’t see: I use the template myself for at least two weeks before it goes anywhere near the shop. This is where problems surface. A prompt that seemed lovely in theory turns out to be annoying on a busy Wednesday. A database property that made sense in the build feels like friction in practice. I keep a running list of small irritations, and I fix every one before release.
The testing period also tells me what to cut. The first draft of the life organization bundle had a page for tracking subscriptions, a page for meal planning, and a page for planning outfits. I used none of them. They’re gone. What remains is what I actually opened: a daily page, a weekly reset, a monthly reflection, and a projects list.
Once the template passes the two-week test, I write the setup guide. I keep it short — a few paragraphs and a screenshot or two — because a template that needs a manual is a template with a design problem. If I have to explain a page, I usually rewrite the page instead.
The final step is the least glamorous: I duplicate the template into a fresh workspace and go through it like a customer would. I check every link, every database view, every prompt. I make sure the duplicate link works and that nothing depends on my personal workspace. This is where the small stuff gets caught — a broken relation, a filter that only makes sense with my own data.
The whole process takes about three weeks from first sketch to release, though the best templates spend longer in the testing phase because I keep finding reasons to use them. That’s the real signal. If I’m still opening a template a month after I built it, it’s ready. If I’m not, it isn’t — no matter how good it looks in a screenshot.