Bryan Headrick

One of the more fun projects I’ve worked on recently was for a stroller company that wanted to help customers find the right product without wading through a full catalog. The idea was a stroller selector quiz: a shopper answers a handful of questions: number of kids, terrain, budget, whether they need something that folds one-handed, and lands on a recommended product, or a short list of them, pulled straight from their WooCommerce catalog.

The quiz itself wasn’t the hard part. Building a multi-step form that walks a user through questions and spits out a recommendation is a well-understood problem, and there are plenty of ways to approach it. The actual challenge,and the part of the project I found most interesting, was building a custom admin UI that let the marketing team manage the whole thing without touching code.

The problem with “just hardcode it”

The tempting shortcut on a project like this is to hardcode the quiz logic: write a chain of conditionals that map answer combinations to specific products, ship it, done. That works fine for a demo, but it falls apart the moment the client wants to add a new stroller, retire an old one, tweak a question, or run a seasonal promotion that changes which products get recommended for which answers.

This client wanted the quiz to be a living part of their WooCommerce store, not a one-off microsite bolted on the side. That meant the questions, the possible answers, and the logic connecting answers to products all needed to live in the database and be editable from the WordPress admin – by someone who had never opened a code editor in their life.

Designing the content model around what actually changes

Before writing any admin UI, I spent time thinking about what would realistically change over the life of this quiz, and what wouldn’t. The client had already told me that the number of questions and the order they appeared in were locked in, that structure wasn’t going to shift. What would change, almost certainly, was the wording: the phrasing of a question, the copy on an answer option, the intro text at the start of the quiz, the success message shown once a shopper landed on their recommended stroller.

That distinction shaped the whole content model. Because the questions themselves were fixed in number and sequence, I didn’t need a flexible, reorderable post type for them. I built them as a custom taxonomy instead, which gave the client a clean, admin-editable place to manage the wording of each question along with its intro and success copy, without giving them the ability to accidentally reorder or duplicate a question and break the quiz’s logic in the process. In other words, the content model matched the actual shape of the problem instead of over-engineering flexibility that was never going to be used.

The part that couldn’t be done by hand: the answer matrix

Wording was the easy part to make editable. The harder problem was the sheer number of possible answer combinations. With several questions, each carrying several possible answers, the number of unique combinations that needed to map to a recommended product got large fast, large enough that expecting someone to sit in the WordPress admin and manually build out that matrix, one combination at a time, was never going to work. It might have been tolerable for a handful of tweaks here and there, but not for standing up the whole thing, and not for any kind of large-scale revision down the line.

The client’s marketing team had actually already done the hard thinking here: they’d worked out the full set of desired question-and-answer combinations and their corresponding product recommendations in a spreadsheet. So rather than asking them to re-enter that spreadsheet by hand into a UI, one row at a time, I built a dedicated import tab into the admin interface where they could paste the spreadsheet data directly in. From there, I wrote the logic to parse that pasted data, match it against the existing questions and answers already defined in the system, and use those matches to populate and update the underlying answer matrix table automatically.

That import tool ended up being the single most valuable piece of the admin UI. It meant the team could do their planning in a format they already understood, a spreadsheet, and never had to touch the raw matrix table at all. When they wanted to revise a whole set of recommendations, they’d update the spreadsheet, paste it in, and let the matching logic reconcile everything against the current questions and answers.

Why this matters beyond one stroller company

Product recommendation quizzes are everywhere in e-commerce now, and it’s easy to build one that works well on day one and then becomes unmaintainable by day ninety. The lesson from this project, and honestly one that echoes a lot of the content-management work I do, is that the quiz logic itself is rarely the hard part. The hard part is building a manageable admin UI that lets non-developers keep the thing alive long after launch, inside the WordPress and WooCommerce ecosystem they already know.