Home Writing Redefining UX, in practice
Case Study UX Management UX Design UX Research Jun 2026

Redefining UX, in practice.

A commissioned study landed as Figma screenshots buried in a PowerPoint. Here's how AI, twenty years of reading code, and my own research platform turned it into a live, clickable prototype before the kickoff call - and why that still leaves a bad taste.

— Share this post

Disclaimer: this article was NOT written by AI. Honest.

User Experience seems particularly hard hit by the constant need to evolve and adapt, and the fluidity of UX job titles has always reflected that. I started out as a UX Designer, but as a sociologist with no strong background in UI design, I always drifted towards the more research-oriented end of things. I was also lucky enough to pair with talented visual designers.

As a freelancer, I've had to decide whether to market myself as a UX Researcher or a UX Designer - money and attention are in short supply these days. But over the last few months I've started to appreciate the blurring of the lines between the two. The split is still real for customers, yet I feel I'm developing a workflow that's genuinely my own, one that merges UX Design and UX Research into a single thing.

The brief is a PowerPoint

A study I was recently commissioned to run came with a unique challenge upfront: the flow I was meant to test arrived as Figma screenshots pasted into a PowerPoint presentation. If you've been around the block a few times, this is hardly new - and you probably also know that getting hold of the actual source files means jumping through several hoops that inevitably eat up time.

It helps to know code, but it helps just as much to know what your tooling actually lets you do. I built my first website all the way back in 1995 or so, but I never went much beyond HTML and basic CSS once it showed up. From the early oughts I was running Axure, and as I drifted towards management, even that fell away.

Still, having worked non-stop inside webdev teams, I've always managed to read and understand code, even if I never got enough practice to write it confidently myself. And with the advent of - yes, here it is - AI, my life has become a lot easier, because I can now leverage all that web dev, DevOps and design knowledge quickly. Let's take a look at this particular case.

Build it, fake it, or generate it

The customer wants to test a flow with their users. As the research specialist, I need to sweeten the deal - and I have an edge. I've developed my own platform for deploying websites, and it doesn't just use my own suite of metrics; it's plugged into Cint, so I can funnel real participants into it. An actual working example is what will sell it, so I get to work. I need a clickable process to put in front of the customer. My options are:

  1. Code it by hand from the images in the deck. In my case, very labour- and time-intensive. The added complication is that the flow is fairly high-fidelity, probably built on a Figma component library I don't have access to.
  2. Fake a website out of screenshots. I'd be genuinely disappointed in myself if I went this way - it's underwhelming for everyone involved, whether that's me, the customer, or the eventual users. It sets a bad precedent, and I'm supposed to be the expert here. You want to look your best.
  3. Adapt the images into a real website with AI. This is the best approach, I found. Claude made short work of the prototype - though, as is always the case with genAI, it filled in some blanks semi-creatively and needed a firm hand. On the plus side, it improvised plenty of things that weren't immediately obvious, like CSS effects, and brought in some context from the customer's particular business angle - stuff I'd have had to research anyway, but now with a solid starting point.

Going with option three also sets me up nicely for later. If the project goes ahead, I can spin up a Figma MCP process and build my own component library. If I do get the Figma components from the customer, I can use Claude to bridge the gap between its initial implementation and the single source of truth. The project memory feature earns its keep here, as everything pertinent gets filed away for next time.

Done before the kickoff

Since the platform is mine, it's time to prepare the flow for presentation. I have a set of unique metrics my server can track - it's built for detailed, implicit e-commerce monitoring, and it's precise down to 500ms. I tag the freshly created HTML elements, deploy the full flow, and now I have a working version of exactly what I'd be running. Here's the important bit: the whole thing takes a few hours - less than half a day. And the meeting goes well.

The customer doesn't expect you to turn up with the whole thing ready to go, and they'll always appreciate the extra mile. That's exactly what happens here, and it's a relief for both the product manager and the UX team, who won't have to spend ages communicating and adapting their prototypes - they just wait for results. Back when I commissioned UX Research as a client, these are precisely the things I valued from partner agencies.

The project itself is, of course, far more involved to set up. The partner agency I work with needs to sort the contract, a study plan has to be agreed, moderators and participants sourced, and a timeline locked in. On my end there's housekeeping: securing the prototype behind a magic link, getting the databases clean and ready, and bracing for three intense weeks of work.

There are some caveats, though. The AI-generated content isn't always perfect, and it can sometimes produce unexpected results. For one thing, it currently won't do a 1:1 replication of the original design, unless driven by very specific skills, which I've created for these kinds of tasks. It's also too eager and will overcomment and overproduce. Finally, interacting with Figma via MCP requires AI credits, of which you only get a handfull on the free seat.

Honestly, a few years ago this would have been a job for a whole team. There are pitfalls, too. There's the ever-present risk of hallucinations, and the trap of letting a sycophantic AI agent talk you into a code boondoggle that looks like the real thing but is hollow underneath. This is where the years of reading code pay off.

The final step is a manual review of the HTML and CSS, and some extra JS that needs to be written to handle dynamic behavior and extend user behavior logging. And after that, a lot of testing.

And I'll keep repeating this: on a moral level, using AI sucks, because the people behind it are horrible and the way it's been rolled out is costing people their jobs. Alas, it's the reality we have to function in - or, as the kids say, "we live in a society".

— Share this post
— Find me & subscribe
← Are UX Designers screwed?