0 → 1 AI-native landing page builder for Typeform
Company
Typeform
Role
Senior Product Designer
Timeline
4 months
Impact
  • Creation of new design system, including components, tokens and documentation
  • Shipped 0-1 product

Context

Forms captured data, but creators were stitching Typeform together with Squarespace, Webflow, or Lovable to get a page in front of their audience. That meant Typeform sat downstream of every first impression.

With Typeform Pages, Typeform poses an answer for SMB customers who want beautiful webpages but lack the experience or skill to design converting landing pages from scratch.

Role and Responsibilities

I joined the Typeform Pages project in April 2026 as the second designer on a greenfield squad alongside one other designer, a PM, and four to five engineers from the Blocks team. The brief: design an AI-native landing page builder — no traditional drag-and-drop, no open canvas. Everything through conversation.

The highest-leverage calls traded flexibility for guaranteed quality. Where Webflow and the rest of the no-code category hand creators a blank canvas and drag-and-drop mechanics, we hand them a controlled block library.

Control isn’t limitation. My impact was mostly seen in making a small set of blocks stretch and balancing maximum flexibility and customization while keeping technical scope small enough to ship. I designed hero and content blocks which are configurable enough to cover a wide range of use cases without spawning a new block type.

Designed and shipped:

  • First-run and empty state experience
  • Entry points from Forms into Pages
  • Hero blocks with media and form embed support
  • Content blocks for social proof, product catalogs, and form embeds

Embedded forms keep their own theme

I surfaced the tension: a form dropped into a page often clashes with everything around it, but forcing the page theme onto it would break forms already live and bury complexity we’d pay for later. So the form keeps its theme by default and the AI restyles it on request — honest embeds, without over-engineering beta scope.

Maximum flexibility with minimum implementation effort

By designing one configurable block container instead of separate block types for every content type, I avoided repeating the form builder’s technical debt, where each question block ships its own independent code. Working with a configurable block meant engineers could easily add new content types without building a new block from scratch. This approach also makes A/B variant switching possible later.