How I kept research in the room while AI tools made interface generation cheaper than ever.

A user mentioned that they always worked across two monitors. I knew pretty quickly that this would matter to my design solution.

That detail never surfaced in the requirements, epics, or stakeholder meetings. But it immediately explained why users constantly lost workflow continuity inside the legacy application.

And that insight didn’t come from AI.

It came from talking to an actual user and paying attention to how they described their environment, frustrations, and workflow.

The challenge was properly synthesizing and socializing all the rest of the user research fast enough to influence decisions while those decisions were still being made.

This time, I leaned on NotebookLM as a synthesis layer on top of my UX research workflow. It helped me turn interviews into patterns, surface edge cases, compare requirements against real behavior, and keep product conversations grounded in evidence.

And unlike many specialized UX research tools, the barrier to entry is surprisingly low.

User Empathy, Meet the Boardroom

At its best, UX research builds empathy toward users.

And for organizations with low UX maturity, the value of UX research often depends on how quickly it can surface actionable patterns and make user pain visible to decision-makers.

UX research helps teams see where assumptions fail and where workflow friction happens for the people actually using the product every day.

Depending on what the research uncovers, fixing those gaps can improve efficiency, reduce workflow interruption, lower support burden, or reveal entirely different product needs than the requirements originally suggested. All of those outcomes have downstream business impact.

Synthesize, Package, Persuade, Repeat

Just three short years ago, my workflow looked something like this:

• Zoom or Google Meet for interviews
• PlaybookUX or Maze for prototype testing
• Otter.ai for transcription
• FigJam, Google Sheets, and Google Docs for synthesis
• iMovie and Google Slides for stakeholder presentations

The workflow was fragmented and heavily manual.

At the time, I even put together a proposal for dedicated UX research tools because so much of the operational burden still sat with the researcher: cleaning transcripts, grouping themes, tracking observations, pulling clips, and consolidating findings into something stakeholders could actually consume.

One of the most effective stakeholder presentations I ever created involved manually clipping together user interview footage into a 10-minute highlight reel showing users struggling through the product in real time.

It worked because seeing and hearing actual frustration changed the conversation quickly.

But it also took roughly 8–12 hours of manual editing work to produce.

The tooling proposal never got approved, so our team’s workflow stayed heavily manual.

That didn’t just slow the work down. It slowed how quickly research could influence product decisions and business outcomes.

Synthesis Without the Slog

NotebookLM immediately reduced a huge amount of manual work involved in organizing and reviewing research findings.

The synthesis report quickly surfaced recurring usability issues across interviews:

• Excessive clicking and navigation
• “Shadow workflows” outside the application
• Operational fatigue caused by workflow interruption

And interestingly, this experience mirrors how many UX researchers and product teams are starting to use NotebookLM: as an evidence-backed research assistant layered on top of existing workflows.

• Quick synthesis across interviews, notes, and support conversations
• Multimedia summary outputs including reports, slides, audio overviews, and video tied directly to source material
• A searchable, chat-based research workspace where teams can ask questions against uploaded interviews, requirements, and documentation
• Faster identification of workflow gaps, operational friction, and edge cases across research inputs

NotebookLM sped up the administrative side of the work. The actual insight still came from talking to users and understanding how they worked.

Requirements Say What, Research Says Why

This project was also the first time this client had experienced a formal UX research process firsthand.

Early on, there was understandable concern that interviews might duplicate work already captured in the requirements.

But the difference between the requirements and the UX research became clear pretty quickly.

In one interview, a user mentioned:

“It would probably be easier if the transcript and the activity log were kind of within the same screen.”

Users weren’t just struggling with information access. They were struggling with workflow interruption and constant context switching.

The interviews revealed the human element: how users actually experienced the application, where friction accumulated, and what they needed from the experience to work effectively day to day.

Quickly synthesizing and sharing those findings showed that the research process could be fast, actionable, and a genuine additive benefit to the project.

Finally, Research Can Keep Up

We’re entering an era where almost anyone can generate interfaces quickly using AI-assisted design tools like Google Stitch, Figma Make, v0 by Vercel, and Lovable, and others.

That lowers the barrier to producing interfaces. It does not lower the barrier to understanding users.

Shipping polished UI faster doesn’t reduce the need for research. If anything, it increases the importance of making the right product decisions before teams accelerate in the wrong direction.

For years, one of the biggest operational constraints around UX research wasn’t gathering insight. It was turning that insight into something teams could absorb quickly enough to influence product direction while decisions were still being made.

Now, research findings can move from interviews into synthesis, stakeholder conversations, and product discussions far faster than before.

When UI becomes cheap to generate, the advantage shifts to teams that understand users fastest.

About my work

I write about UX research, AI-assisted workflows, and product strategy, especially where AI reduces operational friction and where human judgment still matters most.

More at → jameswalsh.me

AI Is Making UI Faster to Create. Can UX Research Keep Up? was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

A practical workflow for turning dense requirements into usable UX insight.

Most of my career, I was the person filling in what wasn’t there.

Vague tickets. Half-formed briefs. Stakeholders who knew what they wanted but couldn’t quite articulate it. That ambiguity was practically part of the job description.

Then I stepped into an enterprise product design role and hit the opposite problem: 9 epics, roughly 60 pages of requirements each, all of them deeply interconnected.

NotebookLM is what made it navigable. And it ultimately helped me deliver the project 40% faster than estimated.

That speed came with a consequence I didn’t see coming.

More Requirements Than You Can Shake a Jira Ticket At

Before moving into enterprise product design, most of my work lived in environments where requirements were relatively lightweight. Sometimes a Jira ticket, sometimes a one-pager, sometimes just a verbal request.

A big part of the work was helping clarify requirements, align stakeholders, identify edge cases, and translate loosely defined business goals into usable product decisions. That ambiguity came with its own challenges, but it was familiar territory.

But stepping into this new role meant stepping into an entirely different operational environment.

These weren’t simple UX specs. They blended operational workflows, institutional rules, legacy application behavior, revision histories, workflow constraints, and UI “requirements” into the same place.

A single sentence could represent weeks of meetings, research, and prioritization.

And no single document provided the full picture.

The Requirements Behind the Requirements

My first challenge was understanding what the requirements actually meant operationally before I could apply UX best practices to them.

Parsing the documentation was only one part of the work. I was also trying to understand how staff actually used these systems day to day, what the underlying data represented operationally, and how all of that translated into coherent UX flows.

Each epic described specific UI patterns and broader UX implications throughout the documentation rather than presenting them cohesively.

The people writing the FRDs deeply understood the systems themselves. But many of the prescribed UX and UI patterns reflected implementation assumptions and legacy behavior more than actual user experience principles.

For example, I would run into descriptions of patterns that leaned heavily toward error states instead of error prevention, UX copy that blamed the user, controls that didn’t quite fit the interaction model, or pop-ups where simpler flows probably would have worked better.

The expectation was that I’d use my judgment and recommend better UX approaches when it made sense.

I’d spent years working inside neglected internal applications in prior roles, so I knew firsthand how much bad UX could complicate someone’s day-to-day job.

The challenge wasn’t just designing screens. It was building enough operational understanding to make confident UX decisions across interconnected systems.

In familiar environments, the questions come naturally for me. But here, I didn’t always know what questions to ask yet.

The Artisanal Approach to Document Hell

Before NotebookLM, most of my workflow involved slowly reading FRDs, taking notes in Notion, sketching user flows in FigJam, and mentally reconstructing workflows across dozens of pages and varying levels of fidelity.

Important details could show up almost anywhere.

A big part of the challenge was separating operational requirements from the UI patterns described throughout the documents. Some aligned naturally with the workflows themselves. Others came from well-intentioned attempts to make the requirements more concrete, but introduced patterns that didn’t always hold up from a UX perspective.

Then suddenly, the project was put on hold due to lost funding.

Work stopped for several months, and by the time the project restarted, Google’s Gemini and NotebookLM had become available within the organization’s approved security environment.

In the meantime, I’d discovered NotebookLM and started experimenting with it for personal projects.

NotebookLM is different because it keeps responses grounded in the documentation while still allowing chat-based queries.

I didn’t realize yet how effective that would become for navigating complex FRDs.

But First, a Cautionary Tale

Before NotebookLM, I’d tried using AI to help out, via an internal AI tool that was approved for use. It allowed me to query documents instead of rereading PDFs over and over again.

It helped (I thought).

But there was a problem.

It could sometimes infer information that wasn’t actually grounded in the documents themselves. It occasionally filled in what it thought should exist.

“When you ask generative AI to answer a question, it will answer with full confidence, even though the answer can be fully hallucinated and not based on fact.”

— Guus Baggermans

Early on, I shared some low-fidelity wireframes with team members, and they started asking where certain data inputs and field labels had come from.

“Where was this in the FRD?”

Sometimes, I wasn’t fully sure myself because I was still learning the terminology and operational context behind the system.

The team was understandably strict about accuracy because details really mattered in systems like this.

Same Maze, Better Map

When the project restarted, I immediately restructured my workflow around NotebookLM, and it changed the experience of navigating the details almost immediately.

What ended up mattering most was how consistently NotebookLM stayed tied to the source material.

My NotebookLM workflow looked roughly like this:

• Upload all FRDs to a notebook by epic
• Generate mind maps to understand system relationships
• Extract UX/UI requirements from source documents
• Design in Figma while querying edge cases when needed
• Validate decisions directly against source citations

The output formats were almost unfairly useful. It could generate mind maps, audio overviews, reports, quizzes, flashcards, infographics, and structured summaries directly from source material.

Every format surfaced slightly different relationships and patterns.

Mind Maps

The mind maps were useful because they visualized relationships between backend systems and frontend workflows that previously required a huge amount of manual synthesis to piece together mentally.

It gave me a broad overview of system relationships before diving into the details.

Custom Reports

Custom reports became one of the easiest ways to isolate relevant UX details from surrounding operational logic.

Before, answering questions meant manually hunting through PDFs trying to relocate fragmented information I vaguely remembered reading somewhere.

Instead, I could ask NotebookLM to consolidate only UI-related requirements directly into a brief.

It helped isolate the signal from the noise.

Chat Interface

Because the chat interface stayed tied directly to the documentation, NotebookLM became something I interacted with constantly while designing instead of just a one-time summarization tool.

I’d constantly ask questions like:

• How do these data groupings relate to each other?
• What options are required for this dropdown?
• Are there data display examples for this field?
• What error states are required for this epic?

Now I could retrieve answers conversationally in seconds, while staying tied directly to the source material.

That mattered because the problem with enterprise systems usually isn’t lack of information. It’s too much information with uneven relevance for UX.

Citations

The source citations changed my trust level with AI pretty dramatically.

Unlike earlier GPT tools I had tried, NotebookLM consistently grounded responses in the source material itself. If I wanted more detail, I could jump directly back into the exact location in the FRDs from the citations.

The outputs stopped feeling speculative, and started feeling traceable.

How NotebookLM Changed the Job

Complex enterprise systems still require active systems thinking, careful review, and human judgment.

The project never became less complex. The workflows, institutional logic, and operational dependencies were all still there.

NotebookLM reduced the friction of connecting context across massive documents, while keeping everything tied directly back to the source material.

What changed was my ability to navigate them without constantly second-guessing whether I’d missed something important.

The Uncomfortable Math of AI-Assisted Work

There’s a lot of discussion right now about AI replacing jobs. In my case, NotebookLM didn’t directly replace the work.

It changed the economics of it.

When the project restarted, the budget was tight, so I estimated hours carefully across each epic. But NotebookLM reduced enough retrieval friction that I ultimately delivered the project months faster than I’d estimated.

The client was happy.

Ironically, it also meant I billed far fewer hours than I originally anticipated. When tools reduce friction this much, time stops being a reliable proxy for value.

That experience has changed how I think about pricing knowledge work in an AI-assisted world.

About my work

I write about AI, UX, product strategy, and the realities of working inside complex systems.

My focus is practical: where AI actually helps, where it creates new risks, and how designers can use it without outsourcing their judgment.

More at → jameswalsh.me

How NotebookLM Made Enterprise UX Complexity Navigable was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

As Gemini credits expand, what used to be free exploration is becoming paid iteration.

Most people use AI to figure things out as they go. That’s not a mistake. It’s how these tools are designed. You start somewhere rough, refine as you go, and let the system help you shape the outcome in real time.

That workflow works, until each step has a price.

Google already uses AI credits across parts of its ecosystem, and reporting suggests it may be preparing a broader credit-based model for Gemini. If that expands, it won’t just change pricing. It will make something visible that was easy to ignore before: the interaction itself is becoming a paid workspace for figuring things out.

Iteration, Meet Invoice

In the early days of Figma Make, for example, prompting felt carefree. You could start vague, iterate quickly, and watch things come together. It felt fast, almost playful, like the tool was helping you think.

Then credits were introduced.

My wake-up call came when I tried recreating a Figma prototype. After a couple of days, I checked my prompt log expecting maybe a few dozen prompts. Instead, I saw 147 — and I wasn’t even one-third of the way through the flow.

That was the first time I realized the tool wasn’t just helping me explore ideas. It was charging me to figure things out.

Curiosity Has Overhead Now

This isn’t about people “using AI wrong”. It’s about how the tools are designed. Conversational interfaces invite exploration. They feel like a place to test ideas, adjust direction, and refine intent as you go.

But when that same interaction model meets usage-based pricing, the economics change. The interaction becomes a workspace where exploration itself has a cost. In effect, you’re operating inside a metered workflow, where every adjustment becomes part of the bill.

The Ideal Prompt and the Reality

Here’s what that looks like in the real world.

Starting vague:

1. Help me write a prompt to analyze a product feedback session.

Then:

2. Make it more structured.
3. It’s for user interviews, not surveys.
4. The users are early adopters of a SaaS tool.
5. Actually focus on uncovering unmet needs, not just satisfaction.

That’s four follow-ups just to articulate what you meant in the first place. This isn’t iteration. It’s the brief being assembled, one paid step at a time.

If we were all perfectly disciplined, this is what the first prompt would look something like:

Help me write a prompt for an AI-assisted user interview guide. The product is an early-stage B2B SaaS tool for project managers. The goal is to surface unmet needs and workflow friction, not satisfaction scores. Interviews are 30 minutes, semi-structured, with 5–8 participants who are power users. Output should be a question bank organised by job-to-be-done, with probing follow-ups for each.

In reality, most of us don’t start here.

Getting to this level of specificity requires decisions you haven’t fully made yet. It means holding context in your head and structuring something that’s still evolving.

But when you do start closer to this, the model has enough context to produce something usable without multiple rounds of correction. That’s where better outcomes start to show up, without burning through unnecessary credits.

Easier Said Than Prompted

Front-loading the prompt is more efficient, but it’s also harder to do.

Most of the time, prompting is the thinking process. You start typing to figure out what you mean. You refine as you go. You remember constraints halfway through. You adjust the goal once you see the output. That’s not a bad workflow, it’s a natural one.

The prompt becomes the place to think out loud — and by the time you’ve clarified what you meant, you’ve already paid for it.

The shift isn’t about writing perfect prompts. It’s about adapting to a new kind of workflow. One where iteration is no longer free, and where cost-aware execution starts to matter.

If Your First Prompt Is Never Your Last, This Is for You

I kept running into the same pattern in my own work. Getting output wasn’t the problem. It was how many iterations it took to get something usable.

Over time, that translated into wasted credits, time, and money. So I started studying ways to solve the problem more deliberately: prompting best practices, structured briefs, and better ways to clarify intent before I hit send.

That work eventually became Universal Prompt Designer.

You can start with a rough idea or something more detailed. It helps you work through the decisions you’d normally figure out mid-prompt — using targeted follow-up questions to surface what actually matters: outcome, constraints, audience, and edge cases.

Instead of figuring that out across multiple prompts, you do it once, upfront.

Then it turns that into a structured prompt you can paste into any AI tool.

You still iterate. You just start somewhere that works — instead of paying to figure it out.

The bottom line

Casual prompting is still fine for a lot of things. If you’re exploring or pressure-testing an idea, the conversational workflow works well.

Where it starts to break down is when the work becomes part of your day-to-day workflow, when you need consistency, or when credit usage starts to have a real cost.

As AI moves toward usage-based pricing, the advantage shifts to workflows that reach alignment earlier — before you’re paying to get there. That’s the emerging reality of AI workflow economics.

About My Work

I design AI-assisted workflows where prompts aren’t just inputs — they’re part of the system. My focus is reducing iteration cost and helping teams get closer to the right output before the meter starts running.

Universal Prompt Designer is a tool I built to put that into practice. It guides you through structuring intent upfront, so you start with a usable prompt instead of refining your way there through multiple iterations.

Try it → Universal Prompt Designer
More at → jameswalsh.me

AI Is Turning Thinking Into a Metered Activity was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Four workflow fixes to reduce AI credit usage, plus what actually requires credits in Figma Make.

On my latest Figma Make project, I landed on four workflow changes that significantly reduced how many AI credits I used.

The project was a marketing page for an AI tool I built, Universal Prompt Designer. The goal was to get an MVP page live quickly, and Figma Make was a good fit for that. It’s fast, flexible, and works well for single-page builds like this.

I’ve written previously about how conversational prompting can waste credits (link below), so I won’t go into that here.

For this build, I went in with a personal goal: use credits as intentionally as possible, and avoid treating every small change like a prompt.

If you’re not careful, it’s easy to burn through your monthly credit allocation quickly.

The full page I published ended up costing roughly 1,000 AI credits to create, over 181 edits. That’s about a third of a monthly allocation, and significantly less than what I’d burned through on earlier projects.

That mostly came down to understanding what actually requires AI credits, and what doesn’t.

Not Every Edit Costs a Credit

In Figma Make, some things simply require AI credit spend. There’s no way around it, so it helps to plan for them upfront.

You have to use AI credits for:

• Creating new sections or features
• Generating new pages or files
• Uploading images or graphical assets

Everything else is optional.

You don’t need to use AI credits for:

• Layout adjustments and refinements
• Copy edits
• Spacing and alignment tweaks
• Styling and design system setup (colors, typography, tokens)

That includes defining color palettes, setting up typography scales (H1, H2, H3), and standardizing styles across the design.

In practice, this gave me more control. Instead of prompting for styling changes, I could define those decisions directly and apply them consistently, without spending additional AI credits.

Prompts are for creation. Everything else is usually better handled directly.

Once I understood that split, the workflow became much clearer.

That shift is what led to the four workflow changes below.

1. The Cheapest Step Happens Outside the Tool

If your goal is precise execution, the fastest way to burn credits is to figure things out inside the tool.

I’ve found it works better to handle that thinking outside the prompt input box first. There are two approaches I tend to use depending on the project.

Rough It Out Before You Build

First is a quick and dirty low-fi design, usually in FigJam. Nothing polished, just enough structure to think clearly. For me, that means answering three things upfront: what I’m building, what sections or features I need, and how each part contributes to the overall design solution.

For this project, it was a rough layout of the page sections and what each needed to communicate and do.

That’s usually enough to remove most of the “let me try something” prompts.

Use Credits to Explore, Not to Tinker

The other is using Figma Make to generate a quick pass, just to see what directions it suggests. It tends to average toward familiar patterns, which makes it useful for exploring common solutions quickly, especially early on.

For example, this worked well when I was exploring concepts for a before-and-after section.

It doesn’t eliminate iteration, but it pushes the messy decisions out of the main workflow, which is where they belong.

2. Don’t Decorate a House You Haven’t Built Yet

I went in knowing I needed to be more intentional with credits. From earlier Figma Make builds, I’d seen how quickly they could disappear if I wasn’t paying attention, especially when iterating conversationally. It’s easy to burn through hundreds just trying to figure things out.

For this project, two things made the biggest difference:

The More Precise the Prompt, the Less You Spend

What worked well was using more structured prompts upfront, in my case generated with Universal Prompt Designer. They cost roughly the same AI credits per prompt but produced more precise output, which reduced the need for follow-ups.

Don’t Generate the Whole Thing at Once

I already had the structure defined in my low-fi wireframe, and the goal was to generate that same structure in Figma Make from the start. Not visuals, not polish, just the scaffolding that made the file usable.

That initial pass took 20 prompts and about 146 credits, roughly 5% of a monthly allocation.

(If you want to see how that was structured, you can explore the initial Figma Make file in the Figma Community.)

From there, each section or feature could be worked on independently, and changes stayed contained instead of cascading across the page.

3. Go Section by Section

Once the structure was in place, the way I worked changed.

Instead of prompting across the entire page, I stayed within a single section or feature at a time. Hero, features, social proof, CTA. Each section independently.

In earlier builds, I noticed everything tended to live in a single TypeScript file (TSX, the React component behind the UI), even when the design had multiple sections. When I prompted changes, unrelated things would shift, spacing would change, details would disappear, and I wouldn’t always catch it until a few prompts later.

When the output was split across multiple TypeScript files, those issues showed up less. Changes stayed more isolated.

Working in sections reinforces that. Changes are easier to trace, easier to fix, and much less likely to cascade into other parts of the design.

It also makes iteration more predictable. Once a section is working, you can move on without worrying that the next prompt will undo it.

4. The Most Expensive Way to Fix a Typo

This is where I used to waste the most credits.

On earlier projects, before AI credit limits were enforced, I handled everything through prompts: copy tweaks, spacing, colors, small layout changes. It worked, but it added up quickly and often created new issues I had to fix with more prompts.

This time, I approached it differently.

For smaller changes, I’ll copy the relevant TypeScript or CSS, paste it into Claude, describe the change, then paste it back into the project. For simpler edits like copy changes, I’ll use point-and-edit or update it directly.

That shift alone made a big difference.

Lindsey Norberg described a similar shift while building a full app in Figma Make. Before understanding Tailwind, she was “fighting the output.” Once it clicked, she could read the code and make intentional changes instead of guessing.

That’s exactly what this unlocked for me: more control, fewer prompts, and fewer unintended changes.

Bottom Line

If you treat every change like a prompt, you’ll burn through credits quickly.

If you separate planning, generation, and refinement, the workflow becomes more predictable and your AI credits go further.

About My Work

I design AI-assisted workflows where prompts aren’t just inputs, they’re infrastructure. My focus is reducing iteration cost and increasing precision in metered environments like Figma Make.

Universal Prompt Designer is a tool I built to put that into practice. It helps structure prompts upfront so you get closer to the right output on the first pass, and spend fewer credits iterating after.

Try it here → Universal Prompt Designer

More at → jameswalsh.me

Further Reading

• The Promise and Reality of Monetizing AI Tools
  What happens when you try to turn an AI tool into something people will actually pay for.
• Is Conversational AI Design Quietly Wasting Your Tokens?
  A breakdown of the 8-part prompt structure and why it reduces iteration in metered tools.

How to Use Figma Make Without Wasting AI Credits was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a place for people working across UX, product, AI, and systems thinking to make sense of how those disciplines collide in practice.

That might mean structured prompting workflows, accessibility tradeoffs, AI-assisted research, workflow automation, product strategy, or just the messy reality of integrating AI into creative work.

If you’ve been thinking deeply about how AI is changing your work, not just in theory but in practice, you’ll probably feel at home here.

Topics We’re Interested In

• AI-assisted design workflows
• UX and product systems
• Accessibility and constraints
• Workflow automation
• Product strategy and decision-making
• Design leadership and career development
• Human judgment in AI-assisted work

How to Get Published

Work that gets published here is concrete, not abstract. It reflects real constraints, real assumptions, and real consequences.

It’s also written with care. Each sentence earns its place. Supporting visuals should clarify the thinking, not just decorate the page.

What gets approved is work grounded in direct experience.

That usually comes from something real:

• Something that didn’t work the way it was supposed to
• A workflow that had to be figured out from scratch
• A decision made with incomplete information
• A pattern that only became clear after doing the work repeatedly

Strong submissions don’t stop at what was built. They get into what was happening underneath:

• Decisions that shaped the outcome
• Tradeoffs that weren’t obvious at the start
• Constraints that forced a shift in direction
• Ambiguity that had to be resolved before anything worked

The goal isn’t just to describe what happened. It’s to make sense of it in a way others can use.

What We Don’t Publish

We’re not interested in AI-generated content written at a distance from real experience.

Surface-level trend summaries, generic productivity advice, rewritten LinkedIn takes, and SEO-shaped AI slop usually feel obvious within a few paragraphs. They flatten complexity instead of working through it.

AI tools are completely fine to use here. Most of the publication is deeply interested in them.

But the strongest work still comes from a person wrestling with something directly — making decisions, dealing with constraints, changing their mind, figuring something out, getting stuck, testing assumptions, and learning something specific in the process.

The personal role in the work is the difference.

A Simple Check

Before you send something through:

• Did this come from something you actually worked through?
• Is there a real insight here, not just a summary?
• Will someone else think or work differently after reading it?

If yes, please submit your work. Looking forward to reading your article!

Write for Next Era Journal was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

What does it actually take to turn an AI tool into something people will use and pay for?

A LinkedIn post about Figma Make’s new AI credit limits drove more than 137,000 impressions and hundreds of saves. The accompanying Medium article pulled in over 900 reads, with 28% of readers clicking through to try my custom GPT, Universal Prompt Designer.

People were using it. I still couldn’t turn it into a viable product.

The problem wasn’t building it or finding demand. It was turning traction into revenue.

Working as Designed, Just Not as Hoped

I tested three different platforms trying to turn my custom GPT into a real product: Pickaxe, CalStudio, and LaunchLemonade.

All of them worked. Just not in the way I needed them to.

Each platform failed in a different place:

• One introduced too much UX and deployment complexity
• One had economics that broke under real usage
• One created friction, moderation issues, and trust problems

The challenge wasn’t just getting an AI tool online. It was aligning user experience, pricing, infrastructure, moderation, and product economics without breaking the product in the process.

That’s where things became much harder than the “build an AI startup in a weekend” narrative suggests.

Pickaxe: A Platform for Every Use Case But Mine

Failure mode: complexity killed the product flow.

Pickaxe was the first platform I tried, and at first it looked like exactly what I needed.

In under an hour, I had something functional, connected, and ready to go. It felt like I was right on the edge of turning this idea into a real product.

Progress, With Asterisks

When I first tried Pickaxe, the output didn’t match what I knew my custom GPT could produce.

At the time, they didn’t offer the latest model I’d been using in ChatGPT. Instead of the version I had been testing, it was limited to GPT-5, and it showed up directly in the output.

At first, I thought it might be something I could live with. It wasn’t, so I moved on to another service.

A few months later, I came back and gave Pickaxe another shot. To their credit, they’ve improved the platform significantly. The admin interface is much improved, and they’ve since added newer AI models.

The platform clearly has momentum, and after cycling through all three tools multiple times, it’s probably the one with the most long-term potential.

More Paths Than Destinations

Pickaxe offers multiple ways to deploy a chatbot: portals, pages, embedded deployments, direct links, email bots, Slack bots on higher tiers, plus layered access groups and permission tiers.

It’s feature-rich and gives users a huge amount of control. Maybe too much.

Pickaxe also gives more pricing flexibility than some competitors. Unlike LaunchLemonade, which forces a $10/month floor, Pickaxe let me define my own pricing structure.

But I still couldn’t figure out how to create the product flow I actually wanted:

• Let users try the tool directly on my marketing page
• Give them a limited number of free chats
• Push them into an upgrade flow once they hit the limit
• Offer monthly and annual pricing at price points I control

That flow felt intuitive because users already expect immediate, low-friction access from tools like ChatGPT.

But I couldn’t get there cleanly.

Built From the Inside Out

Pickaxe’s biggest problem wasn’t capability or lack thereof.

The platform exposed too much of its underlying system architecture directly to the user. Instead of guiding users through a goal-oriented setup flow with progressive disclosure, every deployment type, permission setting, and configuration path was surfaced upfront as if it carried equal importance.

The result was high cognitive load and a setup experience that felt driven by backend logic rather than the user’s actual goals.

I spent more time than I expected trying to figure out what I actually needed to configure, what I could ignore, and whether the product flow I envisioned was even possible.

Testing also became confusing. I was never fully sure whether I was seeing the experience as the account owner or as a user inside the access tiers I was trying to simulate. At one point I was able to move freely between permission levels as a test user, which defeated the entire point of the paywall.

It’s probably the most flexible platform I tested. The recurring theme with Pickaxe was that simple product decisions started feeling unnecessarily complicated.

LaunchLemonade: So Close, So Many Problems

Failure mode: friction and trust problems killed activation.

I eventually launched publicly using CalStudio (more on that in a bit), but replaced it with LaunchLemonade the very next day.

Like the others, getting the tool configured took less than an hour. Updating everything around it — the marketing page, FAQs, positioning, onboarding flow — took significantly longer.

I hit publish, and I was live once again.

Then overnight, the platform went down.

What I initially thought was a temporary outage ended up lasting seven days. Their infrastructure was tied to data centers in the UAE, which were impacted by the early stages of the Iran conflict. The platform went down right as I put it in front of users.

That alone was enough to shake confidence.

But it also surfaced something bigger:

The challenge wasn’t just building the product. It was building trust around the product.

A Funnel With Too Many Steps

Even before the outage, I had already started noticing a pattern in the numbers.

Out of roughly 370 visitors to the marketing page over the month of March, about 14% created an account. That part was encouraging.

But most never actually started a conversation.

My theory? Friction.

My original plan was to embed the chat directly into the hero so users could immediately try the product. CalStudio supported that workflow. LaunchLemonade didn’t.

So instead, I built a mock chat UI that suggested immediate access.

The problem was that users then had to:

1. Create an account
2. Navigate to a dashboard
3. Find the tool
4. Finally start chatting

All before they experienced any value.

Each additional step is a leak in the funnel. And at this stage, you haven’t earned enough trust to ask for it.

For AI products, time-to-first-value matters almost more than anything else.

Turns Out, People Will Try Anything

Once I upgraded to the tier that enabled monetization, I discovered something I wasn’t expecting:

I could see the full text of user conversations.

I wasn’t aware of that feature when I launched, and honestly, I wouldn’t have knowingly put users in that position. The ethical implications became uncomfortable very quickly.

Some people immediately tried to jailbreak the system. Others attempted to extract the knowledge base directly. A few pushed into areas I wasn’t comfortable supporting at all.

I ended up tightening safeguards around:

• Religious content
• Self-harm content
• Weapons or harmful content
• Knowledge base extraction and jailbreak attempts

Oddly enough, this became one of LaunchLemonade’s biggest strengths.

For the first time, I had access to real user behavior, real prompt failures, and real edge cases instead of hypothetical scenarios.

Even though the visibility into chats made me uncomfortable, it gave me a much clearer picture of how people were actually trying to use — and misuse — the product.

The Economics Still Didn’t Work

LaunchLemonade also introduced moderation and monetization problems I wasn’t expecting.

Users quickly found ways around my free tier by creating multiple accounts. Surprisingly, there wasn’t a clean way to manually refresh credits for legitimate users or ban abusive accounts.

If your goal is monetization, those missing controls actively work against you.

There was also hidden complexity in the pricing itself.

What initially looked like a simple, scalable model ended up requiring three separate subscriptions just to launch and monetize the product properly. It became more expensive than I expected, faster than I expected.

And like Pickaxe, the experience still didn’t fully match what users now expect from modern LLM tools.

Even something as basic as chat history required navigating through menus instead of persisting naturally alongside the conversation like ChatGPT or Claude. It didn’t feel premium.

More importantly, it didn’t feel like something I’d personally want to rely on as part of my workflow.

That became another recurring pattern:

When tools don’t feel right, users hesitate. And when users hesitate, they don’t engage.

LaunchLemonade solved some of the problems Pickaxe introduced.

It also introduced an entirely new set of problems I hadn’t anticipated:

• Reliability
• Moderation
• Abuse prevention
• Pricing complexity
• Trust

CalStudio: The Best Experience, The Worst Math

Failure mode: success made the economics worse.

CalStudio was probably the closest thing I found to a polished, consumer-ready experience.

The interface felt modern, the performance was solid, and for the first time, it felt like something I could realistically charge money for.

I launched it. Then I replaced it the next day.

The problem wasn’t the UX. It was the economics.

CalStudio runs on a shared credit system where every interaction consumes usage credits from a common pool across your users.

At first, that sounded reasonable.

Then I realized the core value proposition of my product was unlimited iteration.

The entire point of Universal Prompt Designer was to let users refine prompts freely before taking them into tools where credits actually mattered, like Figma Make.

But CalStudio monetized the opposite behavior.

The more successful my product became, the worse the economics got.

I realized success itself would become the problem.

If users heavily engaged with the product, costs scaled too quickly. If they didn’t engage enough, they wouldn’t see enough value to keep paying.

There wasn’t a version where both the user and the business won.

So I moved on.

Your Product Fails. Their Subscription Renews.

Building the actual product turned out to be the easy part.

The hard part was making it feel worth paying for.

This wasn’t a shot in the dark. The signal was there: people were clicking through, trying the tool, and coming back to use it again.

But putting a clean paywall in front of it, letting users upgrade naturally, creating a premium-feeling experience, and making the economics work without fighting the product itself turned out to be much harder than it sounded in theory.

Unless you already have a large audience or a reliable way to drive traffic, many of these platforms still make money whether your product succeeds or not.

They promise to help you monetize your custom GPT. But if the onboarding flow, user experience, or economics don’t hold together, you can end up paying for the infrastructure long before your own business becomes sustainable.

About My Work

I design AI-assisted workflows where prompts aren’t just inputs, they’re infrastructure. I’m exploring how AI can extend product design and marketing into a more end-to-end way of building and shipping products.

Universal Prompt Designer is one example of that in practice.

Try it here → Universal Prompt Designer

More at → jameswalsh.me

The Promise and Reality of Monetizing AI Tools was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Better ways to prompt Figma Make when every run costs credits.

The Day “Just Try Again” Became Expensive

I didn’t notice it at first.

I’d generate something in Figma Make, tweak it, regenerate, adjust the layout, regenerate again. I told myself it was iterative thinking. Experimenting. Then I checked my AI credit balance.

I realized I wasn’t refining output. I was paying for indecision.

When we first started prompting, you could type a vague sentence, see what happened, tweak it, and try again. That workflow still works. But credit limits are here, and every follow-up to clarify what I meant costs me.

In Figma Make, long, detailed prompts often cost about the same as vague one-liners.

Start vague, and you’ll likely send three, four or more follow-ups just to clarify direction. Each one deducts from your credit balance — roughly 25–45 credits per prompt. Hit the limit, and you’re buying more.

There’s a time for lightweight refinements. But if you’re still shaping the core structure, that back-and-forth is where credits rapidly disappear.

That’s when it became obvious to me: if I wanted to use AI credits more deliberately, I needed to get better at prompting before I hit “send.”

The Prompt Before the Prompt: A Quick Explainer

That’s where meta-prompting comes in.

In practice, meta-prompting is a prompt-engineering workflow. You craft and refine the instructions before running them in a metered environment like Figma Make.

A conversational command asks generative AI to create something. When it’s vague, the AI has to infer intent, constraints, and what “good” looks like. In Figma Make, that usually turns into a chain of follow-ups like:

1. Create a white-paper lead capture page
2. Move the email capture above the fold
3. Add user reviews and testimonials

Each of those adjustments feels small. But that back-and-forth is iterative prompting in action: clarifying after the fact, correcting assumptions, and slowly steering the output toward what you meant in the first place.

That’s how prompt drift sets in. And in a metered tool, it’s how credits quietly disappear.

A meta-prompt works differently. It’s not about generating output yet. It’s about designing the instructions that will reliably produce the right result later.

The goal isn’t eliminating follow-ups entirely. It’s avoiding credit-draining rework by getting the prompt much closer before you hit “send.”

At that point, the obvious question becomes: why not just do this directly in ChatGPT?

Where Most People Start with Prompt Optimization

ChatGPT is the obvious starting point. It’s already open, there’s no setup, and asking it to “improve” a prompt feels intuitive.

What it does well

• Quickly adds fidelity to vague prompts
• Adds detail with minimal effort
• Solid for beginners or one-off improvements

Where it falls short

ChatGPT fills gaps by inferring intent. Those assumptions aren’t always wrong, but they’re not always right, either. Because it optimizes for a single response, you often end up clarifying constraints and correcting drift over time.

Takeaway

ChatGPT is a reasonable starting point, especially for exploration. But when you move that output into a metered AI tool where consistency matters, its inferred assumptions and unconstrained structure can lead to wasted tokens and extra iteration.

What Developers Reach for When ChatGPT Isn’t Enough

Once you start reading about prompt best practices, Claude Console comes up often, especially among developers and AI practitioners.

It takes a rough idea and expands it into a structured prompt. This was the first meta-prompting tool I tried, and the output quality genuinely impressed me.

What it does well

• Thoughtful expansion of rough ideas
• Clear structure and best-practice patterns
• Easy to build a reusable prompt library

Where friction shows up

Claude fills in details based on assumptions about your intent. When those are off, you have to be more specific up front, and calibration can take a few tries. It also outputs a prompt template that still needs review and filling before pasting into another tool.

Takeaway

Claude Console is powerful, but if your goal is fewer assumptions and fewer paid runs, its workflow can feel heavier than necessary.

A Prompt Generator That Guides Instead of Guesses

After spending time with ChatGPT and Claude Console, it became clear they work best if you already know prompt best practices and what details to include up front, an assumption that doesn’t hold for most teams.

I dug into dozens of prompt-engineering guides, frameworks, and practitioner write-ups, and the same best practices kept surfacing again and again. The question became simple:

What would a meta-prompting tool look like if it encoded those best practices, instead of expecting users to know them?

That’s how Universal Prompt Designer came together. Every prompt it generates follows the same 8-part, best-practices-aligned structure, producing a consistent, ready-to-use prompt you can paste directly into Figma Make or any other generativeAI tool.

The result is a repeatable AI design workflow that minimizes prompt drift and reduces costly iteration in tools like Figma Make.

To get there, Universal Prompt Designer uses a conversation design modeled after stakeholder interviews. It doesn’t assume you already know all the answers, and it doesn’t push the work back onto you.

When something important is missing, it suggests relevant options and asks targeted follow-ups to clarify intent (audience, constraints, edge cases). When input is already detailed, it writes the prompt and stays out of the way.

Universal Prompt Designer isn’t about replacing your thinking. It sharpens it, so you spend less time going in circles and more time getting useful output.

If you’re already working in tools like Figma Make and want a ready-to-paste prompt instead of more trial-and-error, you can try Universal Prompt Designer free with an email address, link below. Then come back to the comparison below and see how it stacks up for you.

How Other Tools Stack Up

I’m not the only person who’s built an AI tool to improve prompting.

As part of writing this article, I ran the same simple prompt through a range of meta-prompting tools that claim to generate better prompts:

Write a strategy for how I can stay motivated at work and maintain focus.

Most of them fell into one of two patterns. Some acted as prompt expanders, adding structure and fidelity by inferring intent on my behalf. Others pushed the clarification work back onto me before generating anything useful. Several also required subscriptions, downloads, or browser extensions just to get started.

Here’s what I tested:

• Make Prompt Assistant (built by Greg Huntoon, Design Manager at Figma) runs inside ChatGPT and requires a Plus subscription. It asks follow-up questions and improves structure, but the clarification work still falls on you. It prompts you to decide, rather than helping you figure out what to decide.
• ChatGPT, Claude, Gemini add fidelity to vague prompts, but that fidelity comes from inference.
• Rephrase customizes prompts for major LLMs, formatting output in each model’s preferred syntax. It requires a macOS app download.
• Prompt Genie focuses on saving and organizing prompts (“no copy-paste circus”) and requires a Chrome extension.

• GUDprompt: Packed with features and training wheels, but made prompt creation feel more like homework than help.

For me, these tools didn’t solve the problem at hand. Figma Make was already inferring a lot on my behalf, and I didn’t want more inference layered on top of that. I wanted to be guided through clarifying the idea, not have the clarification pushed back onto me.

Some Tools Raised Red Flags I Couldn’t Ignore

Several tools required payment before showing output or pushed browser extensions that triggered security warnings. That raised practical questions about data access, permissions, and where subscription fees were actually going.

When a tool sits this close to your thinking and work, uncertainty about cost, data, and control becomes friction.

The Tool I Needed, So I Built It

I built Universal Prompt Designer to navigate a specific constraint: prompt iteration in Figma Make was quietly burning through AI credits without me realizing it.

Universal Prompt Designer helps you arrive at a well-structured prompt before you paste it into a generative AI tool. Instead of expanding your idea, it guides you through clarifying it. Once the decisions are made, it outputs a ready-to-run prompt using a consistent 8-part framework grounded in prompt engineering best practices.

You can get access to Universal Prompt Designer free with an email address. You’ll unlock the tool and the 8-part prompt structure it uses to generate consistent, ready-to-run prompts for Figma Make or any generative AI workflow.

Metered AI pricing isn’t necessarily ideal, but it’s the environment we’re designing in. Try it on a real project and see whether it helps you navigate that constraint more effectively.

About my work

I design AI-assisted workflows where prompts are not just inputs but architecture. My focus is reducing iteration cost and increasing structural precision in metered environments like Figma Make.

Universal Prompt Designer is a tool I built to put that into practice.

More at → jameswalsh.me

AI supported drafting and editing. The thinking and conclusions are mine.

Further Reading

• Is Conversational AI Design Quietly Wasting Your Tokens?
  A breakdown of the 8-part prompt structure and why it reduces iteration in metered tools.
• The Hidden Cost of Forcing Users to Decide
  How stakeholder-style conversations outperform rigid step-by-step configuration flows.

Unstructured Prompting Is Costing You was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lessons from building a research-led design practice.

When I arrived, UX wasn’t broken. It just didn’t exist.

The company was a DTC beauty e-commerce business shipping hundreof hyper-custom orders every month. Every formula was personalized. Every product was mixed to order. The business itself was built on nuance.

Before I joined, design worked closely with product, but decisions were largely driven by stakeholder preferences. Research existed, but it wasn’t a consistent input into how the business made decisions.

I was hired to help shift design from execution to evidence-based decision-making.

That shift is a common inflection point for first-time design leaders. Leadership research consistently shows that the hardest transition isn’t learning how to “do less design,” but learning how to enable better decisions across the organization. The work stops being about output and starts being about decision quality, shared understanding, and trust built through evidence.

That distinction mattered more than any single screen.

Step 1: Think like a business partner, not a ticket-taker

My first assignment looked small on paper: clean up product naming inconsistencies in the checkout. Product teams suspected customers were confused by how products were labeled.

I could have just fixed the labels. Instead, I pulled analytics, ran a heuristic audit, and mapped the full checkout experience end to end. That’s when the real problem surfaced.

Users often thought they were finished, only to be met with another step, another choice, another decision.

At scale, we were bleeding users:

• Roughly one in three users dropped after seeing custom pricing
• Another quarter abandoned during profile creation
• Most drop-off happened deep in the flow, after users had already invested time and effort

This pattern is well documented in e-commerce UX research. As users get closer to conversion, unnecessary steps and decisions become more damaging, driving late-stage abandonment (Baymard Institute).

I rebuilt the flow to consolidate steps, reduce friction, and clarify where users actually were in the process.

Result: a ~4% lift in conversion.

It wasn’t a moonshot, and it wasn’t meant to be. But in a subscription-based DTC e-commerce business, small gains compound. A few percentage points at checkout don’t just affect a single purchase. They affect every renewal that follows, representing meaningful annualized revenue at our scale.

What mattered more, though, was what it changed internally. For the first time, design wasn’t reacting to stakeholder preferences or patching symptoms after the fact. It was diagnosing root causes early and fixing them once, in a way the business could understand and trust.

Design stopped being treated like polish at the end of the process and more like a strategic partner.

Step 2: Psychological safety is a risk management tool

As the work grew, I built and led the company’s first formal UX team. At our peak, I managed four designers, including myself, operating in a player-coach capacity and reporting to the VP of Product. As the team began to take shape, I made an early deliberate hire: someone whose primary strength was UX research, with enough design experience to operate inside a small team.

That decision became more important as the team matured.

About a year later, I gave her a stretch project designed to support her growth into a more senior role: enabling subscription purchases on more products, not just customized ones. On the surface, it sounded straightforward. In practice, it touched discount pricing logic, the confusing possibility of multiple subscriptions with different cadences, and a growing number of user states that the flow was never designed to handle.

As the complexity became clearer, she raised concerns in our one-on-ones and asked for help working through it. Instead of reviewing screens, we spent time whiteboarding the entire journey together, including the different entry points users could come from and the states they could already be in.

That work surfaced the real scope. What initially looked like a design problem was actually a scope and risk problem. The site wasn’t architected for subscription purchases without a customized product first, and what had been framed as a quick win was a much larger, more resource-intensive effort.

With the scope visible in user flows, she was able to articulate the real sources of complexity to stakeholders and help steer the project toward a scaled-back solution that still met the business goal.

The value wasn’t just saved resources. It was using collaboration and visual artifacts to surface hidden complexity early, before scope, cost, and expectations ran away from the team.

Strong leaders don’t solve every problem themselves. They create the conditions where complexity can be surfaced, shared, and addressed before it turns into risk. In UX, that often means visualizing the system early, before assumptions harden and scope explodes.

Step 3: Shift the debate from taste to tradeoffs

As a team, we began shifting the norm around how UX showed up in product decisions.

I set the expectation that research would be documented clearly and presented directly to stakeholders, not buried in artifacts. We paired behavioral analytics with usability testing, interviews, and surveys, working with both existing customers and anonymous users. When needed, we grounded decisions in established best practices from sources like Nielsen Norman Group and the Baymard Institute.

We reviewed work with cross-functional partners early, so feedback and alignment happened before decisions calcified. Research became an input into planning conversations, not a validation step after direction had already been set.

At one point, we proposed a free-shipping progress indicator based on established e-commerce research. Leadership killed it. They worried it might undercut subscriptions.

I disagreed, but I understood the concern.

That moment clarified something important for me. UX doesn’t win by winning arguments. It wins by changing how arguments get made.

Once research became part of the decision fabric, debates shifted from taste to tradeoffs. Even when ideas didn’t ship, the process held.

What Actually Worked When Scaling UX (Without a Big Team)

Leadership research tends to converge on a few consistent behaviors for first-time managers: earn credibility through impact, reduce ambiguity, and focus on leverage over control.

This isn’t a universal framework. It’s what worked for us, under real constraints.

1. Make research the input, not the validation. Shift debates from taste to tradeoffs.
2. Give designers ownership, not just tickets. Domain knowledge compounds fast.
3. Turn fuzzy asks into scoped, defensible problems. That’s where UX earns its seat at the table.
4. Don’t ask for headcount. Earn it with impact. One fix that moves the business buys more credibility than any roadmap.
5. Accept that not every good idea will ship. The process matters more than the artifact.

The New Normal

By the end of my time there, UX wasn’t about catering to stakeholder preferences. Research and data had become part of the norm for how decisions were made.

That was the real shift. Not a redesign. Not a framework. Just a shared expectation that problems would be matched to user needs, business goals, and evidence, and that design would show its work along the way.

If you’re stepping into your first UX leadership role, that’s the job. Build the habit of research-backed decisions, advocate for evidence over opinion, and make it easier for teams to do the right thing than to default to guesswork.

About My Work

This piece reflects how I approach UX leadership in practice: grounding decisions in research, helping teams reason through complexity, and building systems that scale judgment, not just output.

I’ve worked across product and design teams in DTC and subscription businesses, often stepping in when UX needs to shift from execution to evidence-based decision-making.

If you’re navigating that transition, or stepping into a design leadership role for the first time, I’m always open to thoughtful conversations.

More at → jameswalsh.me

This post was written with AI support for outlining and clarity checks. The perspective, examples, and conclusions are my own. AI helped accelerate the writing process, but the thinking behind it is human.

What I Learned Scaling UX as a First-Time Design Leader was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

How conversational AI is changing what we expect from step-by-step e-commerce experiences.

Rigid decision flows like quizzes, wizards, and configurators push ambiguity onto users. Conversations absorb it.

The problem rests on a subtle assumption: that people know exactly what they want when asked.

In products that rely on user input to move forward — onboarding flows, setup wizards, e-commerce paths — that assumption becomes a liability.

This is a story about a product that made certainty a prerequisite for conversion.

But it’s really about who should own uncertainty: the user, or the system.

The Case: An Unskippable Quiz

Hesitation doesn’t just affect completion rates. It shapes the data systems learn from, and the trust users place in them.

The quiz looked familiar: a step-by-step wizard with a progress bar, visual choices, and a friendly tone.

But even a quick heuristic review flagged serious mobile usability problems. Low contrast, small tap targets, inaccessible text, and misleading progress indicators introduced friction early, well before users reached the harder decisions.

Those issues mattered, but they weren’t the core problem.

The design invited the wrong mental model.

Users said they didn’t realize they were creating a customized product. They believed the quiz would recommend something premade, more like a product finder than a formulation engine. That misunderstanding shaped how every question was interpreted, and how much commitment each answer implied.

Because the quiz wasn’t optional, abandoning it didn’t just mean exiting a flow. It meant opting out of the product entirely, significant for a subscription-based business where early drop-off directly affects lifetime value.

Personalization Is Forgiving. Customization Is Not.

Customization looks similar to personalization on the surface, but it operates under a very different dynamic.

Personalization works because the system does the interpretive work. It infers intent quietly from behavior and adjusts over time.

Netflix is a prime example. Users aren’t asked to explain their taste in genres or articulate what they’re in the mood for. The system learns by observing what they watch, what they skip, and what they return to.

Users are allowed to explore, hesitate, and change their minds without penalty.

Customization flips that model.

Instead of inferring intent, customization systems ask users to declare it. Preferences become inputs. Ambiguity has to be resolved up front. Responsibility for accuracy shifts from the system to the person using it.

That shift matters because customization often involves choices that feel subjective, unfamiliar, or permanent. Users aren’t just browsing. They’re committing.

To manage that risk, most customization experiences rely on rigid, step-by-step quiz flows.

False Certainty Has a Real Cost

This kind of cost isn’t hypothetical. It shows up directly in revenue.

In a December 2025 Nielsen Norman Group podcast, Baymard Institute co-founders Christian Holst and Jamie Holtz shared examples from large-scale e-commerce testing that show how small UX decisions compound financially.

On a Fortune 500 apparel site, simply replacing dot indicators with actual thumbnail images increased conversion by 1%, translating into millions of dollars in additional revenue. In another case, duplicating the “Place Order” button at both the top and bottom of the order review page drove an additional $10 million in annual revenue.

These weren’t flashy redesigns or new features. They were small interaction details that, when overlooked, quietly suppressed revenue, and when fixed, unlocked it at scale.

The same dynamic showed up in the customization flow I worked on. Not in visual details, but in the decisions users were being asked to make.

As users move through a customization flow, the system treats each answer as progress. The quiz advances. Inputs are captured.

For users, those same moments often feel unresolved.

Often, the problem isn’t that users don’t have an answer. It’s that they’re between answers.

A choice doesn’t reflect certainty. It reflects constraint.

They’re being asked to decide before they understand the implications. The terminology may be unfamiliar. The consequences unclear. And the cost of choosing “wrong” feels difficult to undo.

So people hesitate, abandon, or choose something just to move forward. That last behavior looks like confidence to the system. But for users, it introduces doubt:

Did I just lock myself into something that doesn’t actually fit me?

In skincare and personal care, cart abandonment reaches 81% (Statista, 2025), even higher than the 70% average across all industries (Baymard, 2025). Customization flows don’t create that reality, but when they demand certainty where none exists, they do nothing to assuage it.

When systems ask users to self-diagnose, they don’t just create friction. They demand confidence users haven’t had a chance to build.

What Better UX Could Fix (And What It Couldn’t)

The redesign started with a single clarification.

From the beginning, the experience made one thing explicit: users were creating a customized product, not being matched to something premade. That reframing reset expectations about what the quiz was doing and why the questions existed.

From there, the work became more surgical.

I partnered with R&D to identify which inputs were actually required to create a viable formula. Several questions with high drop-off weren’t used in formulation at all, they existed primarily to signal customization rather than enable it.

Removing and consolidating those questions reduced the quiz from 21 steps to 9.

The remaining changes focused on clarity and timing. Copy was tightened. Contextual FAQs and “Help Me Choose” overlays provided detail only when users asked for it. Questions were rewritten in users’ language and explained why information was being collected. User testing confirmed that understanding improved without slowing people down.

This redesign predated the current wave of generative AI tools like ChatGPT, when ambiguity had to be absorbed manually, through UX structure, sequencing, and copy.

It worked. But only within the limits of a static flow.

The Opportunity Is in Asking Better Questions

Today, there’s a better way to solve this problem: replace the quiz entirely with a conversational, agentic AI-driven flow. One that takes the ambiguity we previously handled by hand and turns it into a first-class part of the system.

Not a chatbot layered onto an existing experience to signal “we’re doing AI.” Not an “assistant” sitting off to the side.

A system that is the experience.

Conversational systems handle uncertainty differently. They can start from incomplete or fuzzy input, ask follow-up questions only when clarity is needed, and adapt their path based on confidence instead of treating every decision as final.

Consider a moment like this:

“My hair is kind of in between straight and wavy.”

In a traditional quiz, that’s a failure state. The system forces a choice.

In a conversational system, it’s usable input.

The system can ask a targeted follow-up to clarify what “in between” means, or infer intent from a prior description instead of demanding precision up front.

That shift benefits users, but it also benefits the business.

Instead of collecting brittle, guessed-at answers, the system gathers higher-quality signals. Instead of pushing everyone through the same path, it varies depth and pacing. Instead of forcing commitment early, it earns it.

This isn’t an “AI-powered” feature bolted onto broken UX. As Nielsen Norman Group has warned, “powered by AI” is not a user benefit.

This works because the user problem already exists: people struggle to describe themselves accurately. The system needs structure. The mismatch is visible and repeatable.

That’s where conversational, agentic AI earns its place.

This Works Under Real Constraints

In the original quiz, the system asked 21 questions, but only about a dozen inputs were actually required to generate the customized product.

More recently, I designed a conversational system with a similar constraint: a universal prompt builder that required specific structured inputs to produce reliable output. Instead of asking for everything up front in a linear path, the system analyzed context, identified what was missing, and asked targeted follow-ups only when needed.

The result wasn’t fewer questions. It was better ones.

The intelligence isn’t in asking less. It’s in knowing which inputs matter, and when to ask for them.

Adaptive Systems Raise the Bar for UX Research

As AI allows systems to become adaptive, UX work expands.

You’re no longer just designing screens.

You’re designing signal confidence, for both the human and the system, so research has to uncover not just where people struggle, but which signals are safe to automate.

That means understanding:

• Where users are uncertain
• Which decisions feel risky
• When the system should probe, explain, or wait

Without that foundation, AI doesn’t reduce friction. It just automates the same bad assumptions, faster.

Designing for Ambiguity Is the Real Work

The most valuable UX work I’ve done hasn’t been about refining interfaces.

It’s been about clarifying what the product actually is.

And increasingly, that means designing systems that can think with users, not just ask them to self-diagnose. Not with certainty. But with ambiguity.

Not to eliminate it, but to understand how to share the load, and build systems that help users get there instead of asking them to pretend they already have.

About my work

This article grew out of real product work and deeper research into how AI is reshaping e-commerce, onboarding, and decision-heavy systems.

I work on problems where users are asked to decide before they’re confident, and where systems need to do more than collect inputs. My focus is on designing products that handle ambiguity responsibly, whether that’s through better UX structure, adaptive systems, or agentic AI workflows.

More at jameswalsh.me

This piece was written with AI support for outlining, phrasing, and clarity checks. The research synthesis, product analysis, and point of view are my own. AI helped accelerate the writing process — but the thinking behind it (and the conclusions) are human.

(The em dashes are not.)

The Hidden Cost of Forcing Users to Decide was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

A reflection on judgment, sensemaking, and why execution is no longer the bottleneck.

TL;DR

As AI accelerates execution, many UX roles are discovering that judgment, not output, is what actually drives progress. The gap between what’s hired for and what moves work forward is widening.

UX is the label, sensemaking is the job

In practice, UX work often starts before the screens, in the decisions that shape everything that follows.

Sometimes that means standing up a design practice from scratch. Establishing shared language, introducing rituals, and helping teams understand the difference between output and decision-making. Other times, it means being asked for something narrow. Heuristic feedback, UI execution, design cleanup. All while quietly doing the upstream work required to make any of that effective.

A common pattern I’ve seen is being brought in for a narrowly defined role when the underlying problem is broader. The ask is framed around polish, but the real need is shared understanding. Flows that haven’t been defined. Tradeoffs that haven’t been surfaced. Decisions that haven’t been made yet.

Research increasingly describes this kind of work as sensemaking. Continuous reframing in the face of uncertainty, where judgment in UX design matters as much as craft.

I can do the work that’s asked. But the value I bring most consistently shows up earlier, in the work that shapes the problem before it ever reaches the screen.

Execution is where the work becomes visible.

This upstream work is what makes it coherent.

Exhibit A: When requirements meet reality and someone has to referee

In one recent role, I was brought in as a Lead Product Designer to support a large academic system with complex requirements, where systems thinking mattered more than surface polish.

By the time I joined, the team had extensive documentation, but lacked a practical, shared picture of how the system would actually be used day to day. Design reviews had started but stalled, and progress was limited.

The issue wasn’t lack of effort or poor documentation. The work was unfolding without a grounded view of how staff actually operated. Without that perspective, feedback naturally gravitated toward surface-level UI decisions because there was nothing sturdier to react to.

Before meaningful design could happen, someone had to connect dense requirements with real user needs and apply UX best practices to simplify, prioritize, and defend those decisions.

My first step wasn’t to redesign screens. It was to help the group understand how my role could support the work already in motion by improving decision-making, not just deliverables. I set expectations for a more structured, collaborative process, using workshops as checkpoints where requirements, workflows, and user realities could be examined together.

Through interviews with the staff who relied on the system day to day, a key pattern emerged. The requirements accurately listed the data fields the system needed to support, but couldn’t describe how that information was used moment to moment.

Staff consistently referenced a small set of critical data points while performing tasks. What they needed wasn’t new data, but persistence: the ability to compare information across actions without losing context.

That insight didn’t come from requirements alone or from UI execution in isolation. It came from connecting documentation with lived workflows.

From there, the work accelerated.

Workshops were a turning point; they shifted reviews away from subjective debate and toward shared problem-solving.

The conversations weren’t frictionless. They involved reconciling existing data pipelines and prior commitments with how the system was actually used day to day.

That tension mattered. It surfaced decisions that had been embedded in documentation and clarified where UX could add value. Not by redefining requirements, but by aligning them with real user behavior.

Over time, discussions centered on whether workflows supported real tasks, whether critical data appeared when needed, and whether the system reduced cognitive load rather than preserving design patterns that no longer fit how people actually worked.

The visible outcome was a cleaner, more usable interface.

The less visible work was the accumulation of sensemaking: aligning people, constraints, and decisions so execution could finally move forward.

In environments where this work shows up, the results aren’t just better designs. They’re fewer costly reversals, clearer product direction, and faster momentum across teams.

That pattern, being hired for design and doing the connective work that makes design effective, is one I’ve encountered repeatedly.

The work has a name, and it’s not in most UX job descriptions

After doing this kind of work repeatedly, it was grounding to see it described plainly in research on UX practice. Not as “good UX,” but as judgment under uncertainty, the work required when the problem itself isn’t stable yet.

“Designers often confront situations where goals are ill-defined, scope shifts midstream, or success criteria remain unsettled. Rather than executing on a stable brief, they must engage in continuous reframing — interpreting shifting inputs, reconciling conflicting priorities, and redefining what the design problem even is.”

— Coping with Uncertainty in UX Design Practice: Practitioner Strategies and Judgment

That description mirrors the work beneath the work I’ve been pointing to. Not refining screens against a fixed brief, but helping teams operate when the brief itself isn’t stable yet.

It’s a normal condition of real-world product work, even if roles rarely name it.

This is also why execution alone rarely unlocks progress in these environments. As Simon Robinson puts it:

“The deepest leverage is not in the artifacts themselves but in the operating logic behind them.”

That operating logic is where decisions get made, tradeoffs are surfaced, and competing interpretations are resolved.

The screens come later. They’re evidence of the work, not the work itself.

If judgment is what stabilizes the problem before execution, what happens when execution becomes radically easier?

When AI can generate anything, judgment becomes everything

AI is making it easier to produce output at scale.

What it doesn’t do is decide what should be built, why it matters, or how the pieces fit together once they’re in use.

Those decisions still belong to people.

AI can generate options. It can’t resolve uncertainty, reconcile competing constraints, or tell you whether a system will hold together beyond the first release.

Judgment, the human layer AI can’t replace, determines which options make sense, which risks matter, and which tradeoffs are acceptable.

As execution gets easier, the cost of poor judgment rises.

That’s why the work beneath the work matters more now, not less. And why the fingerprint I’ve been describing has only become more valuable in an AI-shaped environment.

Your professional DNA that transcends titles

Over time, I’ve come to see this pattern as something deeper than any single role. A kind of professional DNA that shows up regardless of tool, title, or team.

A skills fingerprint is the pattern behind the problems you keep being trusted with, especially in nonlinear UX careers. Hard skills matter, but the fingerprint is mostly shaped by judgment, communication, and how you operate when the path forward isn’t clear.

That fingerprint is shaped by:

• the constraints you’ve learned to navigate
• the tradeoffs you know how to make under pressure
• how you reduce ambiguity when goals are unstable
• the situations people instinctively pull you into when progress stalls

This pattern accumulates across roles, industries, and experiences. Often long before the UX title ever appears, and often in work adjacent to it.

The same underlying fingerprint can show up very differently depending on the context. In some environments, it looks like untangling requirements and workflows. In others, it’s mediating between product, engineering, and leadership. In others still, it’s reframing the problem before execution accelerates in the wrong direction.

What stays consistent isn’t the industry or the deliverables. It’s noticing when the work no longer fits cleanly inside a role, and doing what’s necessary to move it forward anyway.

Many designers develop a similar fingerprint over time, even if it shows up differently across teams, products, or stages of growth. Especially in places where the challenge isn’t a lack of skill or effort, but a lack of shared direction.

If you’ve seen a similar fingerprint emerge in your own work, especially in places where UX isn’t clearly defined, I’d love to hear how it shows up for you.

The kind of work I’m saying yes to in 2026

UX has always been one tool in my kit, not the entirety of it.

What’s mattered most across my career is the work underneath. Making sense of complex systems, reconciling competing constraints, and helping teams reason through decisions when there isn’t a clear path forward.

That often shows up as careful validation along the way. Tactfully asking uncomfortable questions, surfacing edge cases early, and ensuring the logic behind the work holds together before it scales.

As AI has emerged over the last few years, it’s become another tool I’ve added to that same toolkit.

I use it as a strategic layer threaded through the work itself, helping explore alternatives, stress-test ideas, surface signals I might otherwise miss, and support better decision making at multiple points.

Used this way, AI reinforces the same pattern I’ve relied on throughout my career: maintaining coherence as complexity increases rather than simply accelerating output.

That’s the full fingerprint I bring with me.

UX is one expression of it. AI is another. Both serve the same aim: helping teams reason clearly through complexity, from first framing through validation and execution.

About my work

If this way of working resonates, I’m always open to conversations about roles, collaboration, or experiments worth building.

I help teams reason through complexity and make smarter decisions before scaling execution. My work lives at the intersection of UX, systems thinking, and AI-enabled workflows.

More at jameswalsh.me

This post was written with AI support, primarily for outlining, phrasing, and stress-testing clarity. The story, research, and perspective are my own. AI helped speed things up, but the thinking behind it is all human.

What Your UX Career’s Fingerprint Reveals About Real Value in an AI-Driven Market was originally published in The Next Era Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.