I had a client last year, a large WooCommerce store, convinced they needed a full UX overhaul because “Sarah the Millennial” was not buying enough. They sent over a 50-page PDF of stock photos, invented hobbies, and “Sarah’s” favorite brand of soy milk. None of that is any use to a developer. It said nothing about why people were hitting “back” on the checkout page, or why nobody could find the shipping calculator.
My first move was an amateur one. The client wanted a redesign, so I cleaned up the UI, added some CSS animations, and swapped the hero images to match “Sarah’s” vibe. The conversion rate did not move at all. Aesthetics were never the issue. The friction sat in the functional tasks, and we had been designing for a poster of a customer rather than someone with a job to finish. So I switched to functional personas with AI.
Why traditional personas break your design
A traditional persona describes who someone is on paper. A functional persona describes what they are trying to get done. When I build a checkout flow, I do not care whether the user is 24 or 54. I care that they have five items in the cart, that they are unsure about the return policy, and that their discount code is not applying. Map the tasks and the demographics stop mattering much.
Speed is part of why AI helps here. The bigger part is that it will chew through the messy data you already hold and never open: chat logs, support tickets, raw review text. The model finds the complaints that keep repeating, so you are not guessing at them. Smashing Magazine covered this approach to functional personas with AI.
A practical workflow for busy devs
Set up a “Project” in ChatGPT or a “Space” in Claude. One file is not enough context, and thin context is where the hallucinations come from. I usually run a SQL export of customer notes or feedback entries so the model works from things people actually wrote. That beats a survey.
<?php
/**
* Simple export for AI persona feeding.
* Prefix everything to avoid collisions.
*/
function bbioon_export_feedback_for_ai() {
global $wpdb;
// Grabbing recent customer notes from WooCommerce
$results = $wpdb->get_results( "SELECT comment_content FROM {$wpdb->prefix}comments WHERE comment_type = 'order_note' LIMIT 100" );
$output = [];
foreach ( $results as $row ) {
$output[] = strip_tags( $row->comment_content );
}
return json_encode( $output );
}
With the data in place, brief the model. Tell it: “Act as a UX researcher. Segment these users by their primary tasks and the specific questions that stop them from acting. Ignore age and income.” What comes back looks like “The Comparison Shopper” or “The Quick Restocker,” and those you can write code against.
Check it against your support team
Don’t ship what the model hands back on the first pass. Take the draft personas to the people who answer the phone. Ask them, “Does this sound like the person who calls us every Tuesday?” A yes means you can use it. If they look at you like you have three heads, the model made it up, so refine the prompt and run it again.
This gets complicated fast. If you are tired of debugging someone else’s mess and you just want the site to work for the customers you actually have, drop my team a line. We have probably seen it before.
The short version
- Stop cataloguing soy milk preferences and start tracking task completion.
- Point the AI at the messy feedback already sitting in your database.
- If the persona is any good, it changes your navigation, your button text, and sometimes your API logic.
- Keep updating the document instead of letting it turn into another dead PDF.
