Designing a persona system for consistent AI content
Brand voice drifted between sessions because users retyped it every time. I shipped a persona builder, watched it go unused, and rebuilt identity into the generation layer instead.
- Role
- Product Designer
- Team
- Product Designer (Me), CTO, Lead Developer
- Timeline
- 4 Weeks
- Tools
- Figma (Design, Make, Jam), Claude Code, Lottielab, v0
I designed a system for people to describe their brand once. Half of them skipped it entirely and kept typing the same instructions every session. The second version stopped fighting that habit and absorbed it.
I owned
- Problem definition from usage data
- Both versions, v1 and v2
- The adoption post-mortem
- Archetype model
- Prompt-to-persona bridge
- Generation-surface redesign
Shared
- Extraction rules with engineering
- Rollout with the lead dev
Not mine
- Model and prompt-chain implementation
I shipped v1, watched it fail, and made the case internally for rebuilding a feature that was already live — including writing up my own miss. The interesting half of this project is the second half, and I only got to it by being the person who said the first half hadn't worked.
The situation
AI is flexible. Brands are not.
MoFlo could generate captions and visuals well. What it couldn't do was sound like the same company twice.
- Users retyped tone instructions every session
- Emotional tone differed across platforms
- Manual edits to "fix voice" after every generation
- Confusion about who the content was actually for

The usage data had been hinting at it: high draft generation, low direct publish, frequent manual edits before scheduling.
If every draft needs rewriting, the system isn't reducing cognitive effort. It's relocating it. The AI was producing content and users were still doing the thinking.
What users actually meant by "brand"
Nobody thinks in adjectives
I expected people to describe voice the way a brand guideline does. They didn't. They thought in audience and intent.
What they could articulate: who they were speaking to, what they wanted to be known for, how they wanted to be perceived, and what they avoided saying.
The version that failed
I shipped a persona builder. Adoption didn't follow.
The first system asked users to define brand identity explicitly, then apply it at generation time. Structured, deliberate, and more effort than most were willing to spend.

Four weeks of usage data:
The number that mattered. Creation was a one-off; reuse was the point.
Sixty percent still typed manual tone instructions into the prompt anyway, and regeneration for tone mismatch stayed high.
The feature was structured, discoverable and shipped. It was also asking people to do setup work in exchange for a benefit they couldn't feel yet. That trade only works if the payoff is visible, and here it was invisible by design: the rules applied silently, so there was nothing to reward the investment.
The rethink
Stop asking users to build identity. Let them pick it and adjust.

The goal was never to eliminate prompting. It was to eliminate repetition.
Users recreated their brand voice inside the prompt box every session. Tone adjustments lived in memory, not in the system, so every session started from nothing and the same instructions were retyped from scratch.
What shipped
Identity, moved into the generation layer
Lightweight creation. Instead of constructing identity from scratch, persona creation starts from base archetypes and gets refined.
Active visibility. The selected persona stays visible during generation. Users can see which rules are applied, edit them inline, and understand why output looks the way it does. Identity stopped being invisible and became explainable.

The prompt-to-persona bridge. This is the piece I'd defend. When a user types a tone rule into the prompt ("make it less salesy", "more direct", "target investors"), the system offers to add it to the persona.
Manual behaviour becomes structured data. Rather than fighting the habit of retyping, the system treats each retype as the user telling it something, and offers to remember. The habit that broke version one is what feeds version two.
The hard part
An offer that's wrong twice is an offer nobody reads again
The bridge is easy to describe and was the piece I spent the longest on, because "detect a tone rule and offer to save it" hides three decisions that decide whether it works.
Only durable instructions get offered — a standing rule about voice, audience or things to avoid. One-off content direction (“mention the Tuesday special”) never does.
Costs the user · Get this wrong in the permissive direction and the persona fills up with last week's promotions.
I wrote the extraction rules as a design artefact — what qualifies, what doesn't, with examples on both sides — rather than handing engineering a confidence threshold to tune. The classification isn't mine. The definition of a false positive is, because a false positive here isn't a model error: it's the product telling someone it knows their brand better than they do.
Version one asked for setup. Version two asks for confirmation. That is the entire difference, and it is worth more than any of the rules inside it.
Impact
Within one month
Direct publish rate after the first draft rose 18%. The behaviour changed more than the numbers did: users stopped rewriting their identity every session and started selecting and refining it.
🎉 BIG NEWS! We're now OPEN ON WEEKENDS! 🎉 That's right — you asked, we listened! Book your appointment today and experience the difference. Don't miss out! Link in bio 👇 #weekendvibes #bookNow #smallbusiness
The difference isn't quality — the first one is competent marketing copy. It's that the first one could be any business, and the second one belongs to a specific business talking to people who already know it. That gap is what users were closing by hand, every session, with the same typed instruction.
What I'd carry forward
Structure has to absorb habit, not correct it
AI features rarely fail for lack of capability. They fail when they misalign with what people already do.
Version one asked users to change their behaviour first and rewarded them later. Version two watched the behaviour and built the structure around it. Reduce repetition, not control. And make the system's reasoning visible, because invisible correctness earns no trust.