Weeks
1–2 days
Time required to create and publish a rich page
BackCase studies
AI systems · Design systems · Content infrastructure
From static screenshots to an AI publishing system I could ship
Reduced production time from several weeks to approximately 1–2 days.
Reconstructed visuals · confidential systems and prompts omitted.
01 / 07
The publishing workflow was built around static assets
Static assets created handoffs. The new path kept governance.
Publishing path
Value · Weeks → 1–2 days
Old workflow
Several weeks
- 01
Writer brief
Handoff
- 02
Designer creates visual
Handoff
- 03
Engineer builds custom section
Handoff
- 04
CMS setup
Handoff
- 05
Review
Handoff
- 06
Revisions
Handoff
- 07
Publish
Multiple handoffs · Repeated feedback loops · Custom work for each page · Several weeks
New workflow
~1–2 days
- 01
Screenshot or brief
- 02
AI-assisted generation
Gate
- 03
Review and edit
- 04
Structured Contentful entries
Gate
- 05
Publish
Approved components · Section-level revisions · Existing publishing pipeline · Approximately 1–2 days
Two separate paths: friction and handoffs on the left, governed gates on the right—same destination, different cost.
Blog authors often needed to explain complex product interfaces, graphs, or evaluation results. The fastest option was usually to insert a screenshot.
That solved the immediate need, but created handoffs, stale visuals, and content that never became structured CMS data.
I needed a workflow that could generate, review, and publish rich experiences through the existing website architecture — not another one-off eng page.
Screenshots go stale
Product UI moves; the image does not.
Every rich idea needs handoffs
Design and engineering become blockers for routine posts.
Nothing lives in the CMS
Experiences cannot be edited, reused, or governed as content.
02 / 07
Turn screenshots into interactive embeds
One transformation: image-only to explorable embed.
Transformation
Static → Interactive
Before
blog.example / posts / atlas-evalPNG
Atlas Specialist vs baselines
Captured Mar 2024
AccuracyToken efficiencyLatency
Atlas Specialist86%
Ours
North Large79%
Baseline
Harbor Mid74%
Baseline
Image only · not editable · goes stale when the product changes
After
Atlas Specialist vs baselines
Blog widgetInteractive · editable in CMS · reconstructed data
Pass@4 on held-out investigation tasks
Loading chart…
Same Atlas comparison as a frozen PNG versus a live Plotly widget the editorial team can update in Contentful—fictional data only.
Phase one: I replaced static images inside blog posts with interactive widgets that still followed the design system.
Authors provided a screenshot, audience, and takeaway. The system recommended a pattern and produced a draft the team could edit before Contentful.
03 / 07
The system needed to know when to use each component
Component choice was reasoned, not decorative.
Component intelligence
Value · Rules beat vibes
A
atlas-landing-07
Multi-section eval story
We need a landing page for Atlas Specialist vs baselines: hero proof, sequential eval workflow, interactive metric widget, and a demo CTA—without stacking three process patterns or overflowing Contentful field caps.
Constraints locked: purpose, neighbors, a11y list semantics, CMS field limits. Timeline cannot sit beside Workflow Steps. Comparison Table is optional only if diffs are primary.
Primary job is explaining the evaluation process, then proving it with the widget.
Workflow Steps
Live preview · 94% match
- 01
Ingest the run
- 02
Compare candidates
- 03
Inspect failures
- 04
Share the finding
- Purpose · Pass
- Content length · Pass
- Neighbors · Pass
- A11y · Pass
- CMS model · Pass
Patterns
Match
Complex page: ranked patterns under neighbor and CMS constraints—not visual preference.
General-purpose AI can make something that looks right without understanding production design-system rules.
I encoded purpose, content limits, neighbors, accessibility, and CMS field requirements so recommendations were reasoned—not decorative.
04 / 07
From brief to page to Contentful in one path
Brief, plan, preview, and CMS—without repeating the same demo.
Publish path
Value · One governed flow
Author input
atlas-dashboard-capture.png
Audience
Technical buyers evaluating investigation workflows
Takeaway
Readers should compare Accuracy, efficiency, and latency themselves.
Page brief
- Audience
- AI product leaders
- Goal
- Explain evaluation workflows
- Message
- Identify model performance issues faster
- Evidence
- Three measurable outcomes
- CTA
- Request a demo
Interpretation
Interactive metric comparison
Avoid · Static product screenshot
One progressive path: brief, plan, page preview with a static comparison stub, then Contentful fields—live Plotly stays in Widget only.
Phase two: I expanded the same constraints into full pages — structured brief, validated plan, preview, then CMS entries.
Output was never disposable frontend code. It became editable Contentful content on the existing publish pipeline.
05 / 07
AI generated the draft. People remained in control.
People stayed in control of every approval step.
Human review
Value · People stay in control
Approved production version
Find model regressions before they ship
Supporting component
Workflow Steps
Diff vs Version 1
Headline
Evaluate models with interactive investigation workflows
Find model regressions before they ship
Supporting
Metric Summary→Workflow Steps
Approved and stored in Contentful
- 01
Author
Edited headline
- 02
Design
Replaced supporting component
- 03
Approved
Ready for Contentful
Versions stay comparable and approvable—regenerate is shown disabled; this page has no live generation backend.
I designed versioning, section regeneration, and approval states so real teams could trust the workflow.
Authors shortened copy, designers swapped components, and only approved versions entered Contentful.
06 / 07
A production path across AI, cloud, and CMS
AI, infrastructure, and CMS as one ship path.
System architecture
Value · Ship path
Reasoning path
01
Authoring UI
Briefs, previews, approve
02
Gemini reasoning
Interpret + structure
03
Component rules
When / why / neighbors
04
Schema validation
Props + CMS fields
Publish sink
Contentful
Structured entries
Production site
Existing pipeline
Infrastructure
- Cloud Run
- Google Cloud
- Version storage
- Preview env
Authoring feeds Gemini through component rules and schema validation into Contentful and the production site—no real endpoints on this page.
Gemini reasoned; Cloud Run ran services; Contentful stored the result; the website shipped it.
I put schema validation and revision tracking between generation and publish so the rules were structural, not optional.
07 / 07
What changed—and what I learned
Outcomes, insight, and reflection—no more product chrome.
Outcomes
Static
Interactive
Product visuals became explorable, reusable, and easier to maintain
Code dump
CMS content
Outputs remained editable, governed, and deployable
Weeks of production became about 1–2 days — without inventing vanity metrics.
Tools can already generate attractive interfaces. The harder problem is encoding which components to use and how the result becomes production content.
I did not simply build an AI page generator. I built a publishing system that connected AI reasoning, design-system rules, structured content, human review, and production deployment.
What I learned
AI needs constraints to create reliable systems
The most valuable work was not prompt writing alone. It was creating a structured understanding of components, content, and publishing constraints.
CMS architecture determines whether AI output is useful
Generated UI is easy to demonstrate. Structured, editable, production-ready content is much harder and much more valuable.
Human review should be designed into the workflow
Versioning, section-level regeneration, and approval states made the system usable by real teams.
Design systems can become machine-readable product infrastructure
The project expanded the role of the design system from a component library into a source of decision-making rules.