Cutting time-to-first-page by giving the template library a backbone.

Templates were the entry path the product didn't have.

This project was part of a broader company initiative focused on improving the trial experience and making templates a more central part of the product journey.

I owned Phase 1 end-to-end: redesigning the in-app template catalog and aligning it with the marketing website experience, so users would see the same templates before and after signup.

The challenge was that template adoption was extremely low. Even though Instapage had hundreds of templates available, most users ignored them and started from a blank page instead. Only around 1 in 10 pages was created from a template.

Before expanding the template ecosystem further, we first needed to solve the core UX problem: users struggled to discover, compare, and confidently choose templates inside the product.

A flat grid of generic thumbnails is not a library — it's a wall.

I started by treating the existing catalog like an unknown product and walked through the new-user flow myself. The story was the same every time: land on the layouts page, see ~80 thumbnails arranged with no apparent logic, scroll, scroll again, fail to spot anything that fits, click "blank page" instead. There was nothing wrong with the templates individually — the system around them gave the user no purchase.

Three structural issues compounded:

• No mental model for browsing. Templates weren't grouped by anything a user would think in — industry, page type, what they were trying to do. The implicit categorisation was internal naming, which leaked through to UI.
• No way to narrow. Users couldn't say "show me only e-commerce product pages in dark themes." They had to eyeball the grid until something matched, then hope.
• Templates looked similar to each other. The catalog had accumulated over years and many layouts converged on the same visual register — without strong differentiation across use cases, users couldn't tell what each template was actually for. Decision-making became elimination by feeling, not by fit.
• Inconsistent template quality. Some templates were modern and on-brand; others were aged and off-tone. Without curation, the bad ones poisoned trust in the good ones.

The blank-canvas escape hatch was the predictable consequence — and the slowest possible path for a new user. An empty page editor is the worst onboarding in landing-page software: every decision has to be made from scratch, in a tool the user is still learning.

Structure before visuals.

We intentionally started with the filtering structure before redesigning the catalog UI. Instead of focusing on thumbnails or visual polish first, we focused on how templates were organized and discovered. The goal was to make the existing library feel easier to navigate and more relevant — without simply adding more templates.

Together with the PM and engineering lead, I helped define a clearer filtering system with five filter categories that users could combine naturally while browsing:

Two simple rules made the system work — and I asked the team to write them down explicitly, because filter behavior is where good catalogs quietly fail:

In parallel with the filter taxonomy, I collaborated with our Professional Services team to refresh the template library itself — the team that helps customers with custom solutions, page design, onboarding, and implementation, so they know what real customers actually use templates for. The catalog had accumulated over years; many templates were aged and visually similar to each other. Together we curated the existing set down, then added a new layer of visually distinct templates with stronger differentiation across use cases. A good filtering system on top of a stale catalog would only solve half the problem.

Three things stayed out of scope for Phase 1: search functionality, sorting, and a live template count. The constraints were partly real — the search infrastructure wasn't ready and the live-count required event tracking we hadn't built — and partly by design choice. I wanted the taxonomy to carry the catalog on its own before we earned the right to layer search on top. If users were finding the right template through a search bar, we'd never know whether the filters worked.

Five steps from "I want a page" to "I'm editing one."

Filtering happens upfront — users narrow the catalog before opening any individual template, so every preview is a deliberate commit rather than a guess. The flow works the same way for new and existing users.

What we said the new library should do.

The PRD framed three nested hypotheses, each with a metric we could read post-launch.

• Hypothesis 1 (this case): a curated, filterable catalog inside the product will increase the ratio of template-led page creation versus blank-canvas creation.
• Hypothesis 2: a synced marketing-site catalog will increase trial CVR — because prospects can see what they'd be building before they sign up.
• Hypothesis 3: better template-led pages convert better — increasing paid CVR downstream.

Phase 1 owned the first hypothesis. The numbers below show the documented baseline ratio (template:blank = ~0.1, i.e. 10:90) and the post-launch target:

What I argued for — and what I argued against.

The interesting design conversations on a project like this are rarely about the visible UI. They're about the constraints — what gets cut, what gets simplified, what gets refused. Four of those calls shaped Phase 1.

The library, redrawn.

Four pieces of the design are worth seeing — the catalog grid with the new ordering and filter interaction, the filter panel with all five axes, applied tags, and the template preview state.

Templates moved from the long tail to the default path.

To validate the quantitative results, I also reviewed 10 random Hotjar session recordings after launch and manually measured the time between users landing on the template page and opening a template in the editor.

Two other things moved with the time reduction:

What I'd do differently.

Three things I'd change next time.

• Tag the existing catalog before re-curating it. We curated and tagged in parallel, which made the "what gets cut" conversation harder than it needed to be. If everything had been tagged first, the cut list would have been obvious from the data.
• Run a small qualitative study with a synthetic catalog before locking the axes. The five axes worked, but I'd have more confidence in them if I'd validated them on five users with a card-sort plus a prototype, before engineering started building filter logic.
• Build the empty-state harder. Phase 1 had a "no templates match your filters" state, but it was thin. With the right empty-state copy and one nudge ("clear your color filter — that's the most restrictive one"), the failure mode of an over-narrowed search could become a teaching moment.