AI-Native Design Workflow : Edition 07Content Ops Page and Platform Color System
Written: June 03, 2026
Summary:
I built the Content Ops page solo, without Lovable, and shipped it. Then I stepped back and looked at the whole dashboard as a system and found it wasn't one. Platform colors were duplicated across files, the same data was being visualized twice, and two pages were computing the same metric with different formulas. Building a new page is straightforward. Making it belong to the same product as everything else is the real work.
Deep Dive
1: The Content Ops page
Designed for a Monday morning check. Four sections answer three questions in order: how healthy is my content overall (stat cards), which pages need work right now (Fix First priority queue), what is the status of everything in the pipeline (Content Pipeline table), and how are pages distributed by publishing state (Status Distribution). Each section answers a question the others don't.
Content Ops page, full view (desktop & mobile). Stat cards, Fix First priority queue, Status Distribution, and Content Pipeline table. Each section answers a distinct question
2: Platform colors were semantically broken
Three platform colors were colliding with semantic tokens used elsewhere in the UI. Claude's green was identical to the "good" status color, Gemini's amber matched the warning color, and Copilot's coral was too close to the new Gemini orange. Platform identity and status communication were competing for the same colors. I moved all three off the conflicting values and centralized all platform constants into lib/platforms.ts. Before this existed, the same colors were copied into two separate page files and had already started to drift.
3: Replacing a chart that answered the wrong question
The original Citation Breakdown chart showed the same data already visible in the Coverage Matrix on AI Visibility. I replaced it with Status Distribution: proportional bars showing how pages are distributed across Live, Needs Update, In Review, and Draft states. The question a chart needs to answer is: what can the user learn here that they cannot learn anywhere else?
Critical Reflection
Consistency is not a feature. It is the product.
I spent most of this edition not building new things, but making existing things coherent. Centralized constants, a unified calculation, a replaced chart, a shared display pattern. None of this is visible to a user at first glance. But inconsistency is, and it erodes trust in a tool that is supposed to help people make decisions.
The deeper lesson: every shortcut taken during early development is a consistency debt. The duplicated PLATFORM_COLORS, the locally defined calculations, the chart that wasn't earning its space: all of these were created by moving fast. Paying them back required slowing down and auditing the whole product instead of just adding to it.
Conclusion
Achieved: Content Ops page built and shipped. Platform colors corrected and centralized into a shared module. Citation Breakdown replaced with Status Distribution. Avg Optimization unified to the same per-page calculation across all pages.
This is the final edition of this project. Four pages, a consistent design system, and a set of decisions I'd make differently if I started again, which is exactly what a portfolio project is for. The next project shifts domain: B2C IoT to B2B SaaS.
Deployed via Vercel / Built with Next.js & Tailwind CSS