Boagworld: UX, Design Leadership, Marketing & Conversion Optimization

This week, Paul and Marcus dig into why traditional user research repositories fail almost everyone in an organization, and how AI is quietly changing the game. There's also an App of the Month pick that's a little too on-the-nose, some pointed Google bashing, and a sheep-based punchline.

AI-Powered User Research Repositories

The pattern in most organizations is depressingly familiar: user research gets done, a PowerPoint gets presented to stakeholders, everyone nods along or ignores it entirely, and then the research disappears. It might prompt some short-term action, but the knowledge evaporates. Nobody references it again six months later.

The traditional solution has been to build a research repository: a central place to store everything from interviews and surveys to usability tests and diary studies. The problem is that these repositories almost always become what Paul generously describes as "dumping grounds." Dense folder structures, difficult navigation, and search tools that require you to already know what you're looking for make them practically unusable for anyone outside the UX team. And who ends up using them? Other UX professionals, the people who already understand the research anyway. Everyone else ignores them.

AI changes this in three meaningful ways.

First, it makes the initial build far less painful. You can throw everything at it, PDFs, old PowerPoints, interview transcripts, survey exports, and AI will structure and organize that material into something coherent. What used to be a daunting, months-long project becomes manageable.

Second, it makes the repository accessible to people who aren't UX specialists. Instead of requiring a precise search query, a conversational interface lets anyone ask vague, natural questions. A product manager can ask "what do our users think about the checkout process?" and get a synthesized answer drawn from five different studies they never knew existed. That's a genuinely different kind of value.

Third, and this is the part Paul finds most compelling, it can identify gaps in your research. When someone asks the repository a question and there's no relevant research to draw on, a well-configured AI won't fabricate an answer. It flags the gap and notifies the UX team that this is an area worth investigating. Over time, the questions people ask become a demand-driven research roadmap, shaped by what people in the organization actually need to know rather than what the UX team assumes they need.

Marcus pushed back on the reliability question, which is fair given AI's well-documented habit of confidently inventing things. Paul's response: proper setup matters enormously. You instruct the AI explicitly not to fabricate, you add a quality gate that checks answers before they're returned, and you can even have it verify claims against source material. Even with pessimistic assumptions, say one in ten answers being wrong, that's still more useful than having nothing at all. And the failure mode is reassuring: if the AI can't find relevant research, it defaults to generic best practice rather than making something specific up about your users.

Paul then connected this to something he's discussed before: AI-powered virtual personas. The repository feeds the persona generation. AI analyzes the accumulated research and builds queryable personas from it. Unlike static persona documents that go stale almost immediately, these update as new research is added. And here's the detail Paul is clearly delighted by: put a QR code on your printed persona posters. Scan it, and you're now having a conversation with a virtual version of that persona. Marcus had recently written about the value of physical personas on walls as simple reminders of who you're designing for, and this neatly bridges the physical and digital.

The upshot: organizations that invest in an AI-powered research repository end up with something that prevents duplicate research, makes user insights accessible to everyone, identifies gaps in what's known, and gives the whole organization a quick way to gut-check decisions against actual user data. The reason more organizations aren't doing this, Paul notes with characteristic subtlety, is that UX teams are too small and too busy. "Hire me to do it" being the conclusion he arrived at, live on air.

App of the Month

Notion

Paul's pick this month is Notion, which he acknowledges he's almost certainly recommended before, given that he runs his entire business on it and describes its potential failure as roughly equivalent to his own. The recommendation here is specific though: Notion as the platform for building AI-powered user research repositories.

Two things make it well-suited for this. First, structural flexibility: you can organize a repository however your organization needs, and bring in almost any format of research artifact. Second, Notion has a powerful built-in AI agent that can reference, search, and synthesize across everything stored in it.

That said, Paul mentioned conversations with the RNLI, who use SharePoint and Copilot to achieve essentially the same thing. The principle works across platforms. Notion is Paul's preference, but he'd be the first to acknowledge the bias.

Interesting Reads

"Google is quietly rewriting headlines with AI in search results"

Dan at Headscape surfaced this one. Google has been quietly rewriting the titles of content in its search results, not a new practice, but one that has apparently accelerated significantly with the arrival of Gemini. The example from the article: a piece originally titled "I used the cheat on everything AI tool, and it didn't help me cheat on anything" was shortened to "cheat on everything AI tool." The meaning flips completely. Paul's view: this isn't really an AI problem so much as a "no human in the loop" problem. Remove human judgment from the process and you get outcomes like this.

"Testing suggests Google's AI overviews tell millions of lies per hour"

This one prompted a longer and more genuinely interesting conversation. The article references New York Times analysis suggesting Google's AI overviews are incorrect around 10% of the time. The illustrative example: AI Overview cited three sources to answer a question about when Bob Marley's home became a museum. Two of the sources didn't address the date at all. The third, Wikipedia, listed two contradictory years, and AI confidently picked the wrong one.

Paul and Marcus ended up in partial agreement. Paul's argument: we don't hold websites to a higher standard of accuracy than we hold AI, and the expectation of AI infallibility is inconsistent. The real issue is the word "confidently." AI states things with a certainty it hasn't earned, and the interface doesn't adequately signal uncertainty. Marcus's counter: AI summaries have effectively removed the click-through step, so an error now goes unchecked in a way a traditional search result didn't. They concluded it's largely a user interface problem, acknowledged that Google isn't going to remove the feature, and briefly proposed a BBC-funded public search engine before moving on.

Marcus' Joke

I'm entering the annual Give Helium to a Sheep contest again, and I'm a bit nervous. Last year the bar was very high.

Find The Latest Show Notes

There's a scene in the Steve Jobs biopic where Steve Wozniak asks Jobs what he actually does. Wozniak understood his own role clearly: he was an engineer. He wrote code. He built things. But Jobs? Jobs described himself as the conductor of an orchestra.

I've been thinking about that exchange a lot lately, because I think it captures exactly where we're all heading. AI isn't turning us into supercharged doers. It's turning us into conductors, and that requires a completely different mindset.

The problem nobody talks about

I've been coaching a number of people on integrating AI into their workflows recently, and I keep running into the same pattern. The people who aren't getting time savings from AI aren't failing because they don't understand what it can do. They're not failing because they lack access to the right tools. They're failing because they're fundamentally disorganized.

AI is only as useful as the foundation it's built on. If your work processes are messy, your context is scattered, and your task management is a loose collection of mental notes and sticky tabs, AI can't do much for you. It needs structure to work from.

I hear this complaint constantly: "AI has been mis-sold to me. I'm not saving any time." But it hasn't been mis-sold. It's just that AI can only deliver on its promise if there's an organized workflow underneath it. Build that first, and the time savings follow.

That's why I've written before about building AI playbooks and developing proper AI skills. These aren't nice-to-haves. They're the infrastructure that lets AI actually work.

The conductor problem

But here's the deeper shift, the one that's genuinely harder to adapt to.

When you're doing tactical work, you're usually focused on one or two tasks at a time. You go deep, you finish a thing, you move on. It's cognitively manageable.

A conductor doesn't work like that. A conductor holds the entire orchestra in mind simultaneously: what the strings are doing, where the brass comes in, what the percussion is building toward. They're not playing any of the instruments. They're managing the relationships between all of them.

In a world of AI agents, we're going to be managing multiple projects running in parallel, all moving faster than any human team would. We're task-switching constantly. We're accountable for outputs we didn't directly produce. And we have to resist the urge to dive in and do the work ourselves, because that's precisely where we get bogged down.

The design leader parallel

This isn't a new challenge, as it happens. Design leaders face exactly this transition when they move from senior practitioner to managing a team.

I've watched a lot of talented designers struggle with that shift. They get promoted because they're brilliant at the work, and then they spend the next year quietly sneaking back into Figma because they can't let go of doing. They micromanage their reports. They redesign things that were already fine. They can't operate at the level of abstraction that leadership requires.

Working with AI agents is going to feel very similar. The temptation to wrestle with the AI until it produces exactly the output you had in your head, rather than accepting a good result and moving on, is going to be real. Learning to let go of that control is a skill in itself.

The good news is that unlike a team of designers, you can't upset an AI agent by micromanaging it. But you can waste enormous amounts of time doing it, and that defeats the whole point.

AI burnout is already real

There's one more aspect of this I want to flag, because I don't think it gets talked about enough.

When you're managing a team of agents all moving at AI speed, the cognitive load is significant. You're context-switching constantly across multiple workstreams. Things are completing faster than you can review them. It's relentless in a way that managing a human team simply isn't.

This is what's increasingly being called AI burnout. Learning to pace yourself, to batch your reviews, to build in breathing room: these are the organizational skills that will separate people who thrive in an AI-augmented world from those who burn out in it.

Where to start

If I had to distill this to one practical thing: start building the habits of a manager now, before the agents fully take over.

Get organized. Build the infrastructure that AI needs to work from. Practice delegating, even to imperfect tools, rather than doing everything yourself. Work on your ability to hold multiple projects in your head without losing the thread on any of them.

If you want help working through that transition, I offer coaching specifically for this. It's something I'm increasingly focused on, because I think it's one of the most valuable things I can help people with right now.

I'm also running a workshop with Smashing Magazine in July. Modern UX Practitioner covers a lot of this ground in a more structured way, if that's more your style.

The shift from doer to conductor is coming whether we prepare for it or not. The people who handle it best will be the ones who start thinking like managers now.

Find The Latest Show Notes

UX is under pressure. A proactive maturity audit gives you a voice before leadership makes decisions about your team without you.

Something uncomfortable is happening in organizations right now. UX teams are being quietly reassessed. AI has disrupted the field, leadership expectations have gone unmet, and there's a growing sense that UX hasn't delivered what it promised. The conversations are happening, but often not with the people who actually do UX work.

If you're in a UX role, decisions about your team's future might be forming in rooms you're not in.

That's the situation I've been thinking about lately, and it's why I want to talk about UX maturity audits. Not as a defensive measure or a tick-box exercise, but as a genuinely useful tool for getting ahead of a conversation that's already underway.

The expectation gap is real

A lot of the cynicism toward UX right now traces back to one thing: overselling. Leadership was told UX would deliver a hundredfold return on every dollar spent. That figure gets thrown around a lot, and someone took it seriously enough to hire one UX person and wait for the magic to happen.

It didn't.

That disappointment is partly our industry's fault, though it's not something we often admit openly. We've marketed UX with promises that assume a level of organizational change nobody warned leadership they'd have to make. Hiring one person doesn't transform an organization into a user-centric one. It never did. There's a certain naivety in the idea that a single hire will magically produce amazing experiences, without understanding the breadth of change required for an organization to truly become user-focused. But plenty of people implied it would.

The result is a leadership team that feels, not unreasonably, like they were sold something that didn't arrive.

Why waiting is a bad idea

The natural response to this situation is to keep your head down and hope things settle. Understandable, but a mistake.

If leadership is already souring on UX, the absence of any structured conversation about what UX is actually delivering gives that skepticism room to grow unchallenged. Decisions start getting made. Quietly, and without much input from the people who understand what's actually happening.

A proactive UX maturity audit changes that dynamic. Instead of waiting to be judged, you're shaping the conversation. You're the one bringing evidence, framing the questions, and defining what success looks like. That's a considerably better position to be in.

And it's not just damage control. Even mature, well-functioning UX teams benefit from this kind of review. There's always a next stage. Whether it's wider adoption, better integration with product teams, or moving toward something more democratized, an audit helps you see where you are and decide where to go.

What a solid audit covers

A UX maturity audit should cover five areas. Not exhaustively, but enough to give you a real picture.

Strategy and leadership. Does UX have a seat at the table? Is there genuine sponsorship from someone with budget and influence, or is UX being practiced in a corner while real decisions happen elsewhere?

Culture and capability. How widely does the organization understand what UX actually involves? Are there training pathways and career development? Or is it just a job title a few people happen to have?

Research and design processes. Is UX practice consistent, or does it depend entirely on who's available? Are designers and researchers involved early, or called in after the big decisions are already made?

Outcomes and measurement. Can the team point to specific improvements in user outcomes? Are there agreed definitions of what success looks like, and is anyone actually tracking it?

Cross-functional integration. Is UX embedded across teams, or sitting in its own silo waiting for people to come to it?

None of these are particularly complicated questions. The hard part is being honest about the answers.

The difference between a real audit and a survey

An audit that just collects opinions tells you what people think, which is interesting but not necessarily accurate. A good audit looks for evidence.

That means checking whether research plans actually exist. Whether findings get used or disappear into a folder. Whether design systems are maintained or quietly falling apart. Whether the team can point to specific recent changes that improved user outcomes rather than just shipped features.

But the more revealing question is often why these things aren't happening, because the answer usually points straight to the organizational problems that stop UX from gaining traction in the first place. A missing research plan isn't just an admin gap. It's often a signal that no one with authority has made space for it, or that the team has learned it wouldn't be taken seriously anyway.

The questions worth asking aren't simply "how good is our UX?" They're "how well is UX supported here? How consistently is it practiced? What would move us forward?"

This shifts the audit from a performance review to a diagnostic tool. Diagnostics are much easier to have productive conversations about.

Where to start

It's worth being honest about one thing before you dive in: this isn't something you can do half-heartedly. A UX maturity audit that gets treated as a side project, or squeezed into the gaps between real work, tends to produce polite summaries that nobody acts on. It needs management buy-in from the outset, not as an afterthought once the findings are ready.

There's also a strong argument for bringing in someone external to run it. Not because your internal team lacks the ability, but because independence matters here. People will say different things to an outsider. And an external reviewer is less likely to be seen as someone with a stake in the outcome, which means their conclusions carry more weight when they land on a senior leader's desk.

The right person for this isn't someone who will sit in judgment of the UX team's output. The question isn't whether the work is good. The question is whether the organization has created the conditions for good work to be possible. That's a different kind of assessment, and it requires someone who understands enough about how UX actually functions to read the environment accurately rather than just counting deliverables.

Given where things are right now, that feels like a fairly important prerequisite.

Find The Latest Show Notes

So this month Marcus and I get into a slightly uncomfortable question. If AI can knock out decent interfaces from a text prompt, where does that leave the people whose day job is opening Figma and making screens look nice?

We start with Google Stitch, which has been getting a lot of attention lately. Then we zoom out into something I have become mildly obsessed with, which is building AI skills. Not prompt snippets, but reusable, documented processes that let you get consistent work out of AI without drowning it in context.

App of the Month

This month’s tool is Google Stitch (v2), Google’s AI UI generator. You describe what you want, it produces an interface, and you can do some light manual tweaking.

It is not a full replacement for Figma. The editing controls are basic. The bigger story is what it represents. We are now at the point where a decent, usable UI can be generated fast enough that the real value shifts from "can you draw the screens" to "can you judge what good looks like." That is where experience, and yes, taste, starts to matter.

If you want to compare approaches, I mentioned Figr again, which I still prefer for the quality of what it produces.

Are UI Designers Becoming Vinyl?

The question Stitch raises is not "can AI design interfaces". It clearly can. The question is what happens to the job market when "good enough" becomes cheap, fast, and widely available.

I found myself telling 2 different clients recently that they could probably skip hiring a UI designer. They had tight budgets, tight timelines, and already had solid brand guidelines or a design system. In those situations, I could push the work through AI, iterate it a bit, and get something perfectly serviceable.

That line of advice made me feel a bit grubby. Not because it was wrong for those clients, but because it hints at a bigger shift.

My worry is that UI design becomes like vinyl records. Most people will not need it. A small number will care deeply and pay for it. The middle ground shrinks.

Marcus made the important caveat here. Some designers will still be in demand because they bring something AI cannot easily fake. A distinctive visual style. Creative judgment. Brand thinking. The ability to make something feel like it came from a real point of view, not a model averaging the internet.

We also talked about where UI designers can expand their value, because "I make pretty screens" is not a great long-term career plan.

Broaden into UX and problem solving. Look past the interface and into the business problem, user needs, and research.

Own the stuff between screens. AI still tends to think screen by screen. Humans are better at flows, journeys, and the messy reality of how people actually get from A to B.

Lean into information architecture. For websites especially, the structure and content model matter as much as the visual design.

We used a music analogy that will probably annoy some people, which makes it perfect. AI tools can generate "background" output that is fine for low-stakes use. They will not replace great musicians. But they will reduce the number of gigs available.

AI Skills As a Career Asset

After we finished terrifying UI designers, we moved on to something more useful. I think a lot of roles are going to need an AI toolkit. Not a handful of clever prompts, but a proper library of reusable skills.

When I say "AI skills," I mean documented processes that an AI can follow reliably. Think SOPs you can run repeatedly, not prompt snippets you copy and paste.

I now have around 60 skills in my library, and it is growing constantly. Outside of the Boagworld website, it might be the most valuable business asset I have.

The reason is consistency and context management. AI can produce terrible output when you dump too much information on it at once. Skills let you break work into focused chunks and chain them.

We talked about 3 levels of skills:

Company-level skills

Standard processes that keep things consistent. Proposals. Expense claims. Holiday booking. The sort of stuff that should not depend on one person remembering every step.

Team or discipline skills

For example, UX teams can create skills for personas, journey mapping, surveys, and top task analysis. That helps remove bottlenecks and lets colleagues do decent work without reinventing the wheel.

Individual skills

This is where it gets interesting for your career. These are the skills that capture how you do something, including all the weird little bits you have learned over the years.

A key point here is that the value is not only in having the skill. It is in creating it. Writing down a process forces you to surface assumptions and explain what "good" looks like.

We also got into AI agents. If you describe your skills well, an agent can chain them to complete bigger jobs. I gave a sales example where a meeting transcript can be turned into a CRM entry, follow-up tasks, company research, and a draft proposal with very little manual effort.

That is exciting. It is also mildly terrifying if you are attached to the idea of being indispensable.

For more on AI Skills read: Your AI Toolkit Is Your Competitive Edge

Read of the Month

I mentioned an article that helped me connect a few threads in my own work. UX, conversion rate optimization, and design leadership can look like 3 different things until you realize they all operate on the same system.

The piece is called "How CRO and UX Work Together to Increase Website Conversion".

It frames CRO and UX as two sides of the same coin. CRO asks, "Did they convert?" UX asks, "Was it easy and enjoyable?" I would add that UX also cares about what happens after conversion, because retention is often where the real money is.

The shared foundation is data. Analytics, event tracking, heat maps, session recordings. The same signals can tell you where people struggle and where the biggest conversion wins are likely to be.

It also reinforced something I believe strongly. CRO and UX should not sit in separate silos. Both work best when they cover the entire journey, not just one page at a time.

Marcus’ Joke

"I just purchased an original Van Gogh coffee table. I know it’s original because there’s a bit of veneer missing."

Find The Latest Show Notes

This month, Paul and Marcus get into a tool that has made Paul cancel his Figma subscription, walk through how Paul has completely changed the way he approaches website rebuilds thanks to AI, and round things off with the latest thinking from Nielsen Norman Group on where UX is heading in 2026.

App of the Week: figr.design

Paul has been road-testing AI design tools as part of a workshop he ran on AI and UI, and after going through dozens of them, one stood out: figr.design.

What makes it work where others fall short? A few things. It lets you feed in a significant amount of context upfront, things like style guides, design systems, and personas, which means the output is far more tailored than the generic average you often get from AI design tools. Iteration is also genuinely fast. You can queue up a whole list of changes and it processes them all in one go, rather than making you wait between each tweak.

The prototypes it produces are more realistic than what you would typically get out of Figma. Text fields you can actually type in, accordion states that open and close, button states, fully responsive layouts. Not exactly revolutionary in theory, but refreshingly functional in practice. Export to Figma is available when you need it.

The main limitation is that you cannot manually adjust elements yourself. Everything goes through the conversational interface. Paul has also been looking at a tool called Inspector, which runs locally and connects to the Claude API so you pay as you go rather than a flat monthly token allocation. It has been a bit fiddly to set up but worth keeping an eye on.

For anyone regularly using Figma for wireframing and prototyping, it is worth giving figr.design a proper look. The shift Paul describes, from hunching over Figma to leaning back and having a conversation with the tool, is a fairly good summary of where this kind of work is heading.

Rebuilding a Website in 2026

Paul has fundamentally changed how he approaches website rebuilds, and the shift is largely down to AI making a genuinely hard problem, getting good content onto a website, a lot easier.

The old problem

Website rebuilds have traditionally meant migrating existing content into a new design. Which sounds fine until you remember that most of that content was written by subject matter experts who know their field but have never thought about writing for the web.

The result is pages that lecture rather than help, that bury the things users actually want to know, and that rarely arrive on time, because the content phase is almost always where projects stall.

Why things are different now

AI has changed three things meaningfully.

First, generating content is no longer the enormous manual effort it used to be.

Second, doing the research that informs good content, finding out what users actually ask, worry about, and need, is much simpler with tools like Perplexity.

Third, AI-powered search engines are pushing toward a more question-oriented approach to content anyway, which makes getting this right more important than it used to be.

How Paul works now

Here is the process Paul walks through for a rebuild project.

1. Online research

Using Perplexity, Paul researches the audience. For a well-known client, he'll ask specifically about them. For a smaller or niche client, he looks at the sector. He is looking for the questions people are asking, the tasks they are trying to complete, their objections, goals, and pain points. This takes about 10 minutes.

2. Personas

The research output goes into AI, which identifies patterns and segments it into a set of personas. A couple of hours of back and forth to get these right.

3. Company overview

Paul records his kickoff meeting with the client and points AI at the transcript. Out comes a clean summary of what the company does, its products and services, and how it talks about itself. An hour for the meeting, plus 10 minutes for the summary creation.

4. Top task analysis and information architecture

If time and budget allow, Paul runs a formal top task analysis, collecting and prioritizing the questions users most want answered. For card sorting, he uses UX Metrics. If there is no time for that, AI brainstorms the top tasks from the personas and company overview. Either way, those tasks get fed into an AI-generated information architecture.

5. Building out the IA

Paul builds the IA in the CMS or in Notion, assigning the relevant tasks and questions to each page. Stakeholders can see the structure and understand what each page is there to do before a word of copy is written.

6. Getting stakeholders to contribute

Rather than asking stakeholders to write content (a recipe for delays), Paul asks them to do two simpler things for each page: bullet-point answers to the questions assigned to that page, and any other talking points they want included. Bullets only. No pressure to write.

7. Writing the content with AI

This is where it all comes together. Paul sets up an AI project with four inputs:

A web copywriting best practice guide covering readability, structure, and scanning

A company-specific style guide built from existing brand materials

The audience personas

The company overview

For each page, he drops in the questions and stakeholder bullet points, and the AI drafts the content using all of that context. Paul recommends Claude for writing tasks. The result is copy that actually reflects the company's voice and addresses what users need, rather than generic filler.

8. Review and refinement

Stakeholders review the draft and leave comments, ideally directly in Notion where AI can read the page, take in the comments, and rewrite accordingly. One more pass by stakeholders and it is ready to go.

Paul has been using this approach on half a dozen projects and reckons you can work through a full site's worth of content in about a week (depending on size) once the setup is done. For clients, it is a service worth paying for because it takes the content burden off them while producing noticeably better results than migrating whatever was already there.

One thing Paul is careful to flag: this does not mean starting from absolute scratch every time. Old articles, compliance pages, event databases, templated content that just has to be there, all of that can still come across. The point is to treat migration as the exception rather than the default.

Read of the Week: State of UX 2026

The Nielsen Norman Group article Design Deeper to Differentiate confirmed, in Marcus's words, most of what Paul has been saying for the past year. Paul took this as further evidence he is always right!

A few of the key points from the article:

UX has stabilized after the 2023-24 downturn, but teams are leaner. UX practitioners are now expected to cover more ground and demonstrate business impact rather than just shipping deliverables.

AI fatigue has set in, both among designers tired of the "you're being replaced" narrative, and among users who have grown skeptical of AI features that add sparkle without actually improving anything. The article argues that trust is now the central design problem for AI-powered products, covering transparency, control, consistency, and what happens when things go wrong.

UI quality is becoming commoditized. If your value is primarily in making interfaces look good and work correctly, the ceiling on that work is dropping. Real differentiation lives in service design, content strategy, complete user flows, and the connective tissue that links everything together over time.

The hard-to-automate skills, taste, contextual understanding, critical thinking, and judgment, are where humans still add the most value. To thrive, the article suggests UX practitioners need to position themselves as strategic problem-solvers with a broad toolkit rather than deliverable-focused specialists doing what it calls "design theater."

Paul agreed with all of it. Marcus mostly agreed too, while noting that it must be genuinely difficult to be a UX specialist inside a large organization right now, particularly in teams that have cut so far back that one person is expected to cover the entire discipline. The answer, in Marcus's entirely unbiased view, is to hire Headscape!

Marcus' Joke

I stole a neck brace from the hospital. I feel kind of bad, but at least I can hold my head up high.

Find The Latest Show Notes