Case study 02 · AI product · Working prototype
AI Content Assistant: from brief to a page a team is confident to publish
FlowPilot Content is a working prototype of an AI assistant for small marketing teams. It takes a campaign brief through a strategy a person approves, a section-by-section draft, objective SEO checks and a second person's approval, and ends with CMS-ready output. The design work is in making AI output easy to check: every section shows where it came from, and nothing ships that a person hasn't read.
- Strategy firstA person approves the angle, intent and structure before any copy is written.
- No scoreNamed checks that pass, warn or fail, each with the reason and a fix.
- Edit = re-approveAny edit withdraws approval, so what was approved is always what's exported.
01 Context
Small marketing teams ship a lot of pages with very few people.
A new campaign usually needs a landing page: the right audience, search intent, brand voice, internal links, metadata and accessible structure. On a small team, one writer juggles all of it, and the guidelines that should shape the page live in five different documents.
I've seen this up close. On the Kurv website rebuild, the content and SEO teams had almost no way to update copy without engineering. On Kurv's paid-search pages, small copy and layout decisions changed which leads came in. The work was repeatable, rule-based and high-stakes: a good fit for AI that drafts and checks, with people making the calls.
FlowPilot is a fictional company. All the sample data in the prototype (brand rules, pages, customer quotes, figures) is invented.
02 Problem
Generic AI writing tools make drafts faster and reviews slower.
A chat tool can produce a page in seconds, but it doesn't know the brand's rules, the SEO guidelines, which pages already exist, or which customer quotes are approved. Reviewers then spend their time hunting for what's wrong, and nothing tells them which parts to trust.
The risky part isn't generating content. It's not knowing which parts to check.
03 The brief
I started from a brief, and pushed back on six parts of it.
I used ChatGPT as a thinking partner through research, discovery, planning and strategy: looking into how small teams use AI writing tools and where those tools fall short, and pressure-testing the brief. The brief described a familiar AI writing tool: generate the page, score it, publish it. Each change I made came from the same question: what would make a reviewer confident, not just fast?
- No quality score."97/100" invites trust without saying what to change. The review shows named rules that pass, warn or fail, each with the reason and a fix.
- Strategy before copy, approved by a person.Most bad AI copy starts from a bad angle. A 30-second strategy check is cheaper than rewriting seven sections.
- Confidence from traceability, not polish.Every section shows its sources and whether it's an AI draft or human-edited. The assistant never invents quotes or numbers.
- Any edit withdraws approval.It costs a click and prevents the worst failure: shipping text nobody read.
- No publishing to live sites.The tool prepares output; a person publishes. For a small team, an unreviewed live page costs more than the saved minute.
- Final approval by someone other than the writer.Small teams skip this under time pressure, so the product makes it the default path.
That was desk research, not user research: I haven't put this in front of users yet. These are design bets, and the plan to test them is in Results.
04 Insights
People don't need more text. They need text they can verify.
- Context beats prompts.Output quality depends more on the guidelines and pages it's grounded in than on clever wording.
- Review is the bottleneck.Speed only counts if a reviewer can approve a section quickly, not rewrite it.
- Trust is per section.A page is never all right or all wrong, so status, sources and approval live on each section.
05 Opportunity
Design the review, not just the generation.
How might we help a small team produce on-brand, search-ready pages faster, while making it easier, not harder, for a person to stay accountable for what ships?
06 Solution
Five stages, with a person deciding at every one.
| Stage | AI | Person |
|---|---|---|
| 1 · Strategy | Reads the brief and the knowledge base; proposes audience, search intent, page type, tone, angle and structure | Edits and approves before anything is written |
| 2 · Write | Drafts each section from the approved strategy; regenerates, rewrites, shortens or expands on request | Edits, comments, approves or marks each section "needs changes" |
| 3 · SEO review | None: checks are computed from the text and the guidelines | Fixes what fails, decides on what warns |
| 4 · Approval | None | Page approval, then final approval by a second person |
| 5 · Publish | None | Copies or downloads JSON, HTML or Markdown and publishes it |
- Decision
- Review section by section, not page by page.
- Why
- Reviewers approve what's solid in one click and spend their attention on what's flagged. The page can't be approved until every section is.
- Trade-off
- More clicks for a perfect draft. Far fewer missed errors in an imperfect one.
- Decision
- Show who wrote each section: a dashed rule for an AI draft nobody has edited, a solid one once a person has.
- Why
- Reviewers can see at a glance which text no human has touched yet.
- Trade-off
- One more visual signal to learn, so it's explained at the top of the draft.
- Decision
- Any edit withdraws approval, for the section and the page.
- Why
- What was approved is always what's exported.
- Trade-off
- A small typo fix after approval means asking again.
AI Roles, guardrails & evaluation
Clear lines between what the AI does and what people decide.
-
AI role
What the AI does
- Proposes a strategy from the brief and the knowledge base
- Drafts each section from the approved strategy
- Regenerates, rewrites, shortens or expands one section on request
- Lists the sources it drew on for every strategy and section
-
Human role
What people control
- Approving the strategy before any copy is written
- Editing, commenting on and approving every section
- Final approval, by someone other than the writer
- Publishing
-
Guardrails
How bad output is stopped
- Customer quotes only from approved proof; links only to known pages
- Numbers checked against the sources they came from
- Malformed AI responses rejected before they reach the page
- Placeholders block approval; the offline demo engine is labelled as not AI
-
Evaluation
How we'd know it's working
- Time from brief to approved page
- "Needs changes" rounds per page
- Failing checks at first review
- Share of sections approved with zero edits (too high is a warning too)
07 System
Status never relies on colour alone.
The design system has dedicated tokens for the states this product is about: AI draft, needs review, needs changes and approved. Each always pairs colour with an icon and words. The page being written is set in Newsreader, a serif, and the controls in Geist, so you can always tell content from interface.
08 Build
A working prototype, built so each part can be swapped.
I built the prototype with Claude Code. The product decisions, guardrails and interaction design were mine; Claude Code helped me turn them into a working Next.js app, with tests for the rules that matter most, like edits withdrawing approval and unapproved quotes never being offered.
Every AI request runs the same pipeline: retrieve from the knowledge base, generate, then validate. The loading state shows those stages as they really happen ("Reading your brand, SEO and product guidelines", then "Found related content" with a count of the sources used), so waiting describes real work.
- Retrieval is a small lexical (BM25) ranker over brand rules, SEO guidelines, product features, existing pages and customer proof. Brand, SEO and product guidance are always included.
- Two AI providers: Claude through the Messages API when a key is set, and a deterministic template engine that runs offline and is clearly labelled as not AI.
- Workflow stage is derived from the data, never stored, so the status badge can't disagree with what's on the page.
- Swappable by design: the model, the retriever, storage and the CMS are each one interface. WordPress, Webflow, HubSpot and Contentful show as "planned" adapters.
- Accessibility: landmarks, a skip link, visible focus, live announcements for saves and AI results, move up/down buttons instead of drag-only reordering, and reduced-motion support. Checked by keyboard walkthrough at 1440, 820 and 390px. A full screen-reader audit hasn't been done yet.
Link the live prototype here if you host it, and note one thing that changed in the design once it was built.
09 Results
No results yet, on purpose. Here's how I'd measure it.
The prototype hasn't had users, so nothing below is a result. These are the hypotheses, the measure for each, and the baseline I'd need first.
| Hypothesis | How to measure | Baseline needed |
|---|---|---|
| Brief-to-approved time falls | Timestamps already in the activity log | The same task in the team's current process |
| Fewer review rounds per page | Count of "needs changes" events per page | The last 10 pages from the current process |
| Reviewers trust the output more | A short survey after each approval; edits per section | The same survey on human-only drafts |
| Fewer brand and SEO errors reach review | Failing checks at first review | An audit of recent published pages |
| People edit AI text, not accept it blindly | Share of sections approved with zero edits | None |
A fair first test: 5 to 8 people from small teams each produce one page with the tool and one with their current process, in either order, then compare time, edits, reviewer ratings and what they'd change.
10 Reflection
Designing for AI is mostly designing for doubt.
- 01
The interesting design work is in review.
Generation is the model's job. Making its output easy to check is the designer's.
- 02
A score is the easy answer, and the wrong one.
Named rules with a reason and a fix tell a reviewer what to do next. A number only tells them how to feel.
- 03
Be honest about the limits, in the product too.
The demo engine is labelled, missing keyword data is stated, planned integrations say "planned". Known gaps: lexical retrieval misses synonyms, the checks are heuristics, and live model quality hasn't been evaluated.