Flexible Admin Platform Under WordPress Migration Constraints
Redesigned No BS Weightloss’s admin experience from rigid page templates to a vertical-aware, component-based builder so non-technical admins could ship consistent, on-brand pages without needing engineers, even while the team’s main focus was migrating off WordPress.
Context and problem
No BS had grown into a large library of lessons and live sessions, but years on WordPress left admins managing inconsistent, unstructured pages without a shared design system. The first custom platform MVP attempted to address this with hard-coded templates. However, admins were forced to choose a layout upfront with no flexibility, often rebuilding pages from scratch, while introducing new layouts required engineering support.
Design Approach
The easy path was “add more templates.” I argued against this because: 1. More templates means more maintenance and more decisions, not better structure. 2. Templates don’t teach admins how to build good pages; systems do. 3. Repeating WordPress’s “anything goes” problem in a different form would just delay the pain. I proposed a Page builder that balanced hard-coded structure with flexible components, optimized for low-tech effort:
Role
Senior Product Designer
Industry
Online Coaching
Users
Internal admins and coaches
50K+ women, midlife & beyond
Consistency comes from a design system enforced through components and guardrails, not a growing pile of rigid templates.
Designing the sweet spot between consistency and flexibility
Phase One
Streamlining Admin Workflows
I worked directly with admins to map real workflow pain points and identify where the page builder was creating avoidable friction. By simplifying the interface, consolidating metadata into a compact system, clarifying action priorities, and adding intuitive controls like collapsing, reordering, hiding, and deleting components, I improved workflow efficiency, reduced engineering dependency, and made it easier for admins to troubleshoot save or publish issues independently through clearer error handling.
Phase Two
Scaling Component Versatility
I mapped existing WordPress pages to identify the core needs of admins, then designed a context-aware component library that expanded the platform’s content capabilities without requiring architectural changes. It included marketing banners, lead capture forms, and flexible typography options, giving admins more room to build richer pages.
Phase Three
Transitioning to Modular Design
I evolved the architecture into a flexible modular system, where templates became combinations of preset, context-aware components. By organizing these components for use cases like membership and marketing, I gave admins full autonomy to assemble and scale pages, removing the last barriers to operational independence.
All of this worked with the migration , not against it
no rebrand, no complex rules engine, just smarter use of what engineering could realistically support.
Guidance and accessibility
To keep non-designers safe, I created a simple admin guide explaining: 1. What each component is for and how it looks on the front end. 2. Basic accessibility do’s (headings, alt text, contrast, link labels) aligned with the existing design system.
Guidance and accessibility
Impact
With analytics in tools like Amplitude, the team saw improvements after launch: Pages abandoned mid-build then recreated with a new layout dropped by ~45%, meaning fewer “wrong template, start over” scenarios. Median time from “create page/course” to “publish” shortened by ~25%, showing faster, less brittle workflows for admins. Marketing and product teams could launch new flows and campaigns using existing components, without needing engineers to hardcode banners or lead forms. Admins summed it up as finally having a builder that “fits how we actually work” instead of something they fought against.
