About

Context:
This was self-directed work on my own WordPress sites—LCD Lab & LCD Academy, and my personal website—using AI to extend the platform’s functionality past its native limitations, so I could ship better UX without the cost of a developer.

My Role:
Designer, researcher, and problem-solver, with AI as a coding collaborator.

Tech Stack:
WordPress, WooCommerce, WP-Members, Total Theme / WPBakery, Popup Box plugin, Code Snippets plugin

Key Outcomes

WordPress limited my design—I used AI to push past it

The WordPress ecosystem is powerful, but it has a ceiling. Themes, page builders, and plugins each have their own constraints—and when none of them can produce the interaction you’ve designed, the usual options are: find a plugin that does something close, or hand it to a developer.

With these three projects, I used the same process each time: described the problem in plain language to ChatGPT, mapped the technical environment, iterated on the code, and tested until it held up across devices and browsers.

The components here are modest in complexity, but each one solved a real usability problem that the platform couldn’t solve on its own.

Problem

A reference tool that forces a full page load for every content category breaks the flow it was designed to support.

The Sustainable UX Buddy gives designers quick access to planet-friendly design strategies across 16 design categories, from content and styling to interactive components and AI. To be useful, it needs to work the way designers actually work: open alongside a design tool, on a second screen or mobile, with fast switching between categories.

The default WordPress/WPBakery approach would have sent users to a new page for each category—a full page load every time, breaking the flow of the tool entirely. For a reference tool used mid-task, that was a dealbreaker.

What I built

A slide-out drawer triggered on click loads content in-panel — instant access to any category without leaving the page or waiting for a page load.

Users can scroll through the strategies, then swipe or click to close and select another category. It works consistently across mobile, tablet, and desktop, allowing designers to use the tool in whatever way works best for them.

Process

1. Defined the interaction—what triggers the drawer, what it contains, and how it opens and closes
2. Mapped the constraints of the theme and page builder to understand what was and wasn’t possible natively
3. Described the full interaction to ChatGPT with enough technical context to get targeted code output
4. Tested how the drawer behaved at different breakpoints, handling edge cases like scroll locking and close-on-outside-click
5. Iterated on the animation and mobile behaviour until it worked consistently across devices and browsers

Time

1 day, including cross-browser testing—would be faster now the process is familiar

Problem

Sending users to a separate login page the moment they hit gated content breaks their context and kills the conversion the gate was meant to create.

Member-only content is only valuable if non-members can see enough to want access. The existing approach sent users away from the page the moment they hit gated content—to a separate login or registration page—with no clear path back to what they were looking at. Users lost their place, lost context, and often just left. It was a conversion problem caused by a poor handoff between the content experience and the membership journey.

What I built

An inline prompt replaces gated content in place, giving non-members a clear path to register or log in without leaving the page, then returning them directly to the content they came for.

Process

1. Mapped the membership journey—where users were dropping off and what a better flow needed to do
2. Identified what the WP-Members plugin exposed and where the conditional logic needed to sit
3. Described the problem and the technical environment to ChatGPT and worked through a conditional display snippet together
4. Tested behaviour across three user states: logged-out, logged-in non-member, and active member
   Validated across content types and browsers, refining edge cases where the prompt appeared inconsistently

Time

2–3 hours, including cross-browser testing—would be faster now the process is familiar

Problem

Without a way to filter by category, users had to scroll through everything to find what was relevant — and the native solutions that could fix it would have taken design control away entirely.

The LCD Lab’s work page lists everything the Lab has produced and delivered—books, courses, workshops, speaking engagements, research papers, and more. It’s a rich archive, but not all of it is relevant to every visitor. Without a filter, users had to scroll through everything to find what they were interested in.

The native WordPress and WPBakery options for filtering either required a plugin that dictated its own layout and styling, or a page reload per filter—neither of which gave the design freedom or the experience quality the page needed.

What I built

Filter by category, see relevant work instantly—no page reload, no layout compromise.

A lightweight JavaScript filter shows and hides items based on a selected category tag, without reloading the page. Each item is tagged in the markup; clicking a filter button instantly updates the visible set. The styling remains fully under my control — no plugin overrides, no layout constraints.

Process

1. Defined the filtering behaviour needed and why native plugin options weren’t viable
2. Mapped the WPBakery-rendered HTML structure to understand how classes and elements were organised
3. Described the element structure and filtering logic to ChatGPT and wrote a JavaScript function targeting those classes
4. Tested the filter across the full content set, checking that all category tags were applied consistently
5. Refined the active-state styling on the filter buttons and resolved compatibility issues with WPBakery’s rendered output

Time

1 hour, including cross-browser testing

Across the three components, real usability problems were solved that the WordPress ecosystem couldn’t solve on its own, without handing design control to a plugin, and without a single one taking more than a day to build.

Design intent, fully intact.

Each of these components could have been “solved” with a workaround that fell short of the original design. Custom code closed the gap between what was designed and what shipped, on tools and timelines that fit a solo practice.