RoleLead Product Designer
Discovery → MVP / handoff
Instapage needed schema markup as its first move into website tools — to compete on organic and AI-driven traffic, not just paid. The challenge: the same feature had to serve two opposite users. Non-technical marketers who didn't know what schema was, and SEO experts who knew it well and didn't trust AI to write it. I led design from discovery through MVP, anchored on six moderated usability sessions with internal SEO experts, then handed off to a partner team for shipping and consulted through completion. Once users engage with the feature, ~78% complete the flow from starting a schema to publishing it.
A new feature in a technical domain none of us had prior expertise in — schema markup, the structured-data backbone for SEO and AI discoverability.
Six moderated usability sessions revealed two opposite user types: non-technical marketers who feared schema, and SEO experts who knew it but didn't trust AI to generate it.
Dual-track UX. AI-assisted generation with a constrained type-picker for novices. Manual editor with in-product validation for experts. One flow, two doors.
Facilitated six expert interviews before development — with SEO leads, customer success, support, and design. Built a dynamic AI prototype as a learning artefact.
~78% through-funnel completion from starting a schema to publishing the page. The dual-track design works — once users engage, they finish.
Designed the feature end-to-end through MVP — research, flows, prototype, high-fidelity. Handed off to a partner team for implementation; consulted through ship.
The product had been built for paid traffic. Marketing budgets were shrinking, and AI-driven search was rising. Schema was the fastest, lowest-cost path to making the platform work for organic discovery too — and the entry point into a new "website tools" category.
The product is a landing-page builder that has long served marketers running paid campaigns. Two trends were converging: marketing budgets were tightening, so customers needed organic-traffic wins to stretch their spend; and AI-powered search assistants were starting to rely on structured data to decide what to surface to users.
Schema markup is the standardised way pages tell search engines and AI what they're about — who the brand is, what's offered, where it's available, how it connects to user intent. It's invisible to the visitor but central to how the page is discovered.
For the platform, shipping schema was the lowest-cost way to make every customer's landing page more discoverable — without expanding the page builder's scope, and without requiring developers in the loop.
The feature had to make schema feel approachable to people who didn't know what it was — without dumbing it down for people who already knew schema cold and didn't trust AI to write it for them.
I started this project without prior expertise in schema markup. So did most of the team. The first decision wasn't "what should the UI look like" — it was "how do we learn enough to make the right call." But before that, the clearer the user picture got, the more it became obvious we weren't designing for one user.
Has heard schema matters for SEO and AI. Doesn't know what it actually is. Is afraid of breaking something or applying the wrong type to the wrong page.
Knows schema deeply. Has used external validators, schema.org, ChatGPT for years. Cares about correctness more than speed.
If we'd designed only for one of them, we'd have shipped a feature that activated half the audience and alienated the other.
I ran six moderated usability sessions before development, using a dynamic Figma prototype as the artifact under test. The experts I interviewed weren't external — they were internal SEO leads, customer success staff who'd been SEO marketers, and support. The cheapest, most credible expert input we had.
I didn't have schema expertise on day one, and neither did the team. Pretending we did would have cost us months. So I treated the discovery phase like an apprenticeship: assemble the people inside the company who already knew the domain, and learn from them while testing a prototype that was deliberately incomplete.
Most participants recognised schema mattered for SEO. Few could explain how. The term itself felt intimidating and was confused with page layout.
Users went to schema.org, Google docs, or ChatGPT to check correctness. Bringing validation into the product was a clear unmet need.
Users expected schema to behave like analytics scripts: save it once, it's live. The mental model needed to be made explicit, not assumed.
"Don't paste <script> tags," "remove deprecated properties." Catching errors before submission, not after, was higher-trust than post-hoc validation.
"What if the AI applies LocalBusiness to a Product page?" Users wanted constrained types and previews — not free-form generation.
Common types — Product, Article, FAQ, Event, Organization — are well-understood. Surfacing them as a curated picker reduces both AI hallucination and novice paralysis.
Findings paraphrased from internal usability research; raw quotes and recordings withheld under confidentiality.
If we ship a dual-track flow — AI-assisted with guardrails for novices, manual with validation for experts — meaningful share of indexed-page users will adopt schema, and most will use it on more than one page.
If we make schema markup approachable for non-technical users while respecting power users who want manual control, we will activate a meaningful share of indexed-page customers — and most adopters will use it on more than one page.
The team's first instinct was "let AI do everything." I pushed back. Pure automation would have alienated the experts, who are the loudest voice in any SEO community. The dual-track design — AI and manual, both first-class — was non-obvious and the right call.
The biggest call wasn't aesthetic. It was about whose trust to optimise for. Non-technical users wanted help; experts wanted control. I argued we couldn't pick — we had to make both feel like the primary path.
Dual-track flows are harder to design than single-path ones. The risk: users dither at the entry choice, or the two paths feel like they're hiding things from each other. We mitigated this by making both doors visible, equally weighted, and reachable from each other (an expert can drop into manual mode mid-AI flow; a novice can ask AI to start them off in manual mode). Status, validation, and save-publish behaviour are unified across both tracks — only the input method differs.
The shipped flow lives inside the page's SEO settings. From the same panel, novices can generate schema with a constrained type picker; experts can paste or write their own. Both paths converge on the same in-product validator and save-republish status pattern.
Discovery happens in the page's settings — under a clearly labeled SEO section, with schema markup as a named subsection alongside a friendly intro and a help-centre link. From there, the user picks one of two doors, then converges with the other path on validation, save, and publish.
The post-launch funnel shows where the design works and where the next opportunity is. Through-funnel completion (start → publish) is ~78% — a strong signal that AI generation, manual editing, and in-product validation are doing their jobs. The next-iteration constraint is upstream: the discovery rate from "saw the SEO tab" to "started a schema."
I track adoption two ways: end-to-end (saw it → published it) and through-funnel (started it → published it). Both tell parts of the story.
Funnel shape and conversion rates anchored to actual post-launch results. Absolute counts rounded for illustration. Internal raw numbers withheld under confidentiality.
What the funnel tells us:
Three things I'd change next time: front-load discovery copy in usability testing, tighten the design-to-handoff bridge, and bring help-centre content inline rather than linking out.
I'd usability-test the discovery copy specifically. The pre-build research focused on the schema flow itself — and the flow works. But the ~11% engagement rate at the SEO-tab step suggests the entry-point copy is doing less work than it could. Five short sessions on just the SEO-tab module would have caught this earlier.
I'd build a tighter handoff artifact for the partner team. Some of the more nuanced parts of the design — persona-aware micro-copy, error-state edge cases, help-centre integration — didn't make it through. A handoff package with explicit "must / should / nice-to-have" tagging on each component would have made trade-offs more visible to the team picking it up.
I'd bring help-centre content inline. The research clearly showed users want plain-language explanations and examples at the point of action, not a link to read elsewhere. Linking out works in v1; embedding contextual explainers is the v2 move.