CMS UI Patterns / Case Study
Presence CMS Framework
What I wanted to solve
School and civic content teams manage pages, alerts, documents, and calendars alongside their other work. I wanted the CMS to make those tasks easier to follow, with clear actions and enough context to understand what a change will do.
I organized the framework around repeated decisions: what am I editing, what state is it in, who owns it, and what happens next? Buttons, forms, tables, messages, and tabs give those decisions a consistent structure that can be reused across admin screens.
My contribution
Experience design
I designed the CMS editing experience, organizing how content owners create, review, publish, and maintain their pages.
UI design
I designed the forms, tables, buttons, and messages so everyday admin tasks look and feel consistent.
Prototype development
I built the underlying front-end prototypes, turning the UI patterns into reusable components and example admin screens.
What I focused on
- Familiar actions across screens
- I wanted save, preview, approve, cancel, and delete to feel familiar wherever they appear. Editors should not have to learn a different set of controls for every task.
- More than a page title
- I included ownership, location, status, and timing alongside the content. Those details help an editor decide whether a page is ready to publish.
- A clear next step
- I gave success, warning, and error messages different roles. Each should tell the editor what happened and whether they need to do anything next.
How can a CMS make everyday editing decisions clear while giving teams a consistent starting point for new admin screens?
How the flow works
- 01
Create and configure
Add content, then set its location, ownership, metadata, and visibility.
- 02
Review
Check the preview, resolve errors, and understand any approval requirements.
- 03
Publish
Confirm the intended timing and visibility before making the content available.
- 04
Maintain
Use status, ownership, and row actions to find and update existing content.
Why I designed it this way
Give each action a clear job
I used different button styles to make the main action stand out from supporting choices. Smaller icon buttons save space in tables, with labels and visible keyboard focus to keep them understandable.
Buttons and action hierarchyKeep feedback close to the task
I paired color with clear messages for success, warnings, and errors. If a required field stops someone from saving, the message should explain what needs fixing, not just say something went wrong.
Feedback statesKeep related fields together
I grouped the title, page type, owner, publishing date, summary, and visibility in one form. Editors can check the important details together. Tabs keep larger groups of settings organized without taking them away from the page they are editing.
Page editor formMake content easy to scan
I kept the page name, section, status, and owner in consistent columns. Actions sit beside the page they affect, making it easier to compare records and see what each button applies to.
Content tableA closer look at the designs
This guide breaks the CMS framework into reusable interface components. Each section explains the purpose of the component, where it fits in an admin workflow, and how the existing class names can be reused consistently across pages.
- StatusDraft
- TemplateSubpage
- UpdatedApr 26
- Version2.0
Use tabs for related configuration panels inside a single CMS task flow.
<div class="CMS_element">
<div class="CMS_title CMS_T4">Page editor form</div>
<input class="CMS_input" value="District News">
<div class="CMS_buttonGroup CMS_bg-Mt CMS_bg-R">
<a href="#noop" data-no-scroll="true" class="CMS_button CMS_bGo">Save changes</a>
</div>
</div>
Looking back
I wanted this framework to make the small, repeated parts of CMS work feel consistent. The forms, tables, buttons, and messages give me a starting point for new screens without having to redesign the basics each time. The prototypes also make those decisions easier to share with developers.