Context:
LCD Lab & LCD Academy—lifecentred.design ↗
My Role:
Designer, researcher, and problem-solver. AI as coding collaborator.
Tech Stack:
WordPress, WooCommerce, Sensei LMS, Total Theme / WPBakery, WP-Members, Koko Analytics, Sendy
Contents
These are three small projects where I used ChatGPT as a design and coding collaborator to extend the functionality of my WordPress site.
Introduction
With each of these three small projects, I described to ChatGPT what I wanted and what I was seeing in the dashboard, in plugin settings, in debug logs. We worked through solutions together, testing, failing, and iterating until it worked.
None of these is a large engineering project. But that’s the point.
A designer who can move from “this experience is broken” to “here’s a working fix”—without a handoff, a ticket, or a sprint cycle—is a meaningful capability in a small team or product environment. AI-assisted coding isn’t replacing developers. It’s expanding what a senior designer can do independently.
My process—describing the problem, reasoning through the constraints, iterating on solutions, testing across contexts—is the same process I use in any design problem. The output just happens to be code.
What this work taught me
Think in systems, before you write a line of code
Tracing how plugins and platform components interact is the same muscle as mapping how a design decision ripples through a business — catching problems earlier and producing solutions that hold up outside the design tool.
Know your tech stack
Each plugin owned different data and behaved differently. Getting the solution right meant knowing who was responsible for what—course access, purchase records, user profiles, email segments—before designing anything.
Use AI deliberately, not reflexively
For well-defined problems with a clear output, AI is fast and effective. For problems that were still fuzzy, slowing down and working through the logic manually first consistently produced better results. The friction was useful.
What this means in practice
Faster problem-to-solution cycles.
A designer who can scope a front-end problem, prototype a fix, and validate it without a developer handoff reduces friction in small teams and early-stage products.
More productive developer collaboration.
Understanding the technical environment means clearer briefs, better questions, and fewer back-and-forth cycles when working with engineers.
Project system awareness reducing downstream problems.
The most useful skill wasn’t learning to code. It was understanding the technical environment well enough to ask the right questions—without that, the AI would just generate plausible-sounding code that solved the wrong problem.
1. A better user dashboard
PROBLEM: After purchasing a course or tool, users landed on a default WordPress/ WooCommerce profile page.
PROBLEM
A user dashboard that was disjointed, hard to navigate, and did nothing to reinforce the value of what users had bought.
WHAT I BUILT: Using a custom code snippet and WordPress shortcodes, I created a dedicated “My Power Ups” page that pulls in each user’s purchased courses and digital tools — displayed as visual cards, clearly labelled, with direct access links.
This new page feels more intentional, and answers the first question any new member asks: “So, where do I find my stuff?“
SOLUTION
A dedicated “My Power Ups” page that surfaces each user’s purchased courses and tools as visual cards—easy to find and clearly labelled.
PROCESS:
- I described the problem to ChatGPT, along with what plugins I was using and what data they exposed.
- We worked through which hooks and shortcodes could surface the right content, wrote a snippet, dropped it into the Code Snippets plugin, and tested it.
- A few iterations to sort the layout and conditional logic for different product types.
- Cross-browser checks.
TIME:
Under 1 hour (including testing across browsers)
2. Enabling customers to easily renew subscriptions
PROBLEM: A technical gap causing a retention problem
Courses and tools on the platform use time-limited access, typically 12 months.
When access expired, there was no warning. Users would simply lose access and have to find their way back to the store to repurchase as if they were a new customer. There was no acknowledgement that they’d already been through the course, no reassurance that their progress was saved, and no path back that felt considered.
PROBLEM
No expiry warning for subscriptions and no reassuring renew journey
WHAT I BUILT: A two-part solution:
- An expiry badge—a “Renew Access” label appears on any course or tool card that is approaching or has reached its expiry date. Users see it on their dashboard before they lose access, not after.
- A dedicated renewal journey—rather than sending users back to the standard product page, the renewal flow includes clear messaging that their purchase is a renewal, that their course progress is saved, and what they’re getting for another 12 months.
SOLUTION
A “Renew Access” badge on expiring course cards, plus a dedicated renewal journey that reassures returning users their progress is saved—so re-enrolment feels like a continuation, not a repurchase.
PROCESS:
This was the hardest of the three. The solution needed to pull data from three different plugins—Sensei LMS (courses), WooCommerce (purchases and expiry), and WP-Members (user access)—plus the theme’s page builder. None of them were designed to talk to each other in this specific way.
I had to learn where to find the right data: digging through cPanel file structures, reading debug logs, identifying which plugin was responsible for what. ChatGPT helped me interpret error messages, suggest alternative approaches when one hit a wall, and write the code—but the design decisions about what the experience should feel like were mine.
I also had to figure out how to test properly, including setting expiry dates manually to simulate different states, and checking behaviour across browsers and devices.
TIME:
1 week to build, 1 week of testing. As a first real coding and debugging project, a lot of that time was learning the environment. I’d estimate it at 2–3 days now.
3. Conversion tracking without the bloat
PROBLEM:
The analytics plugin I use on the platform is deliberately lightweight — it’s a low-data, low-energy choice that aligns with my low-carbon design principles. The trade-off is that it doesn’t track granular events. I had no way of knowing whether a promotional email had led to a registration or a sale, which made it hard to know what was actually working.
PROBLEM
No expiry warning for subscriptions and no reassuring renew journey
WHAT I BUILT:
A small piece of tracking code added to specific call-to-action buttons — the ones that lead to a registration or a purchase. When a user clicks one of those buttons, they’re tagged and added to the appropriate segment in Sendy (my email platform), so I can see which segment they came from and whether that action completed.
No third-party scripts, no heavy analytics layer. Just a targeted snippet that answers the specific questions I had.
SOLUTION
Lightweight button-tracking that tags users into the right email segments on click — no third-party scripts, just the specific conversion data I actually needed.
PROCESS:
-
- I described the journey to ChatGPT—which buttons, which plugin handled the email lists, what the segment structure looked like in Sendy.
- We wrote a lightweight tracking script together.
- Testing involved manually clicking through the journeys and checking the Sendy dashboard to confirm the right tags were being applied.
TIME:
2 hours (including testing)