Live Products
Rytass CMS
Design Systems · UI
Overview
A shared CMS and design system, standardised
Standardized Rytass's client-by-client CMS into a shared, role-based publishing product, supported by a rebuilt Mezzanine design system.
Rytass maintained multiple client sites with a CMS that was intentionally configurable. Over time, each project drifted into a different structure and editing flow. The result was repeated rebuild work and an admin experience that was hard to learn and maintain.
This project defined a shared CMS model and rebuilt the Mezzanine design system to make the experience consistent across projects while keeping necessary flexibility.
Problem
No shared foundation, high rework cost
The CMS needed to support different site structures and content types without requiring a redesign for every new client.
Key issues
- No shared information architecture across projects
- Inconsistent editor/admin workflows between client instances
- High rework cost when starting new websites
Impact
- Slower delivery due to repeated CMS setup and UX decisions
- Higher training and support overhead for admins and editors
My Role
Design lead for standardisation
I led product and UX design for the standardisation work and partnered closely with a PM and engineering leadership.
Mezzanine design system
Mezzanine is developed internally, open source, and used across the CMS.
Mezzanine work
- Rebuilt design system foundations and key UI patterns to support a shared CMS
- Defined components and interaction patterns for content creation and publishing (navigation, forms, tables, states, empty/error patterns)
- Documented variants and usage guidelines so teams could ship consistently across client configurations
Storybook: storybook.mezzanine-ui.org
Quadrant (open-source embedded article editor)
Quadrant is the CMS's embedded article editing system for composing and managing content blocks within an article.
Demo: demo.quadrats.io
My focus: designed and integrated a table block and table editing behavior (Quadrant previously did not support tables). Defined interaction and edge cases for table creation and editing (insert rows/columns, resize, copy/paste, responsiveness).
Key Challenge
Editorial state and versioning
Publishing was not a single action. With review and approval, “published” becomes a state reached through different roles and transitions. We needed clear definitions for:
Needed clarity on
- What each state means
- What action triggers the transition
- Which version of the article the state refers to
Aligned editing behavior with the article state and version model to reduce “which version am I editing?” ambiguity.
Approach
Role model and article state model
Role model
Two roles
- Editor: drafts and submits content for review
- Admin: reviews, approves/rejects, and controls publication
Editors cannot publish directly. This boundary reduced ambiguity and made workflows easier to define.
Article state model
Five states
- Draft (草稿): In progress. Not submitted for review.
- Reviewing (待審核): Submitted by the editor. Awaiting admin review.
- Publishable (可發佈): Approved by admin. Ready to publish.
- Scheduled (已預約): Approved and scheduled for a future publish time.
- Published (已發佈): Live on the site.
To support real-world use, I mapped non-happy paths and maintenance actions, including rejection and return-to-draft behavior, editing content that is already published, rescheduling scheduled content, and version ownership across transitions.
Outcome
Shipped and active
Result
- Successfully handed off the end-to-end publishing flow to the software engineering team, with clear ownership and implementation-ready specs.
- Reduced time required to spin up each new client CMS instance by standardizing the core model and repeatable setup steps.
- Synced product logic across design, engineering, and PM so workflows, state transitions, and schema definitions stayed consistent.
- Enabled more fluent PM–engineering collaboration on defining the content model and schema (content types, permissions, and lifecycle states), speeding up decisions and reducing rework.
Reflection
What I'd do differently
Takeaways
- Standardization required clear decisions on what must stay fixed versus what can be configured per client
- Defining the state model before UI design reduced rework and made interaction decisions easier to validate
NDA
Portions may be under NDA. If you need deeper context, contact me.