DEV Community: Josue Perez

The five UX leaks I look for first in any product flow

Josue Perez — Mon, 05 Oct 2026 19:30:32 +0000

The 48-hour teardown returns the five leaks costing you most. They are different for every product, but five shapes recur so often that I check for them before anything else. Here they are, with the cost and the fix, drawn from the two sample reports on this site.

A note on provenance. The examples below come from the two sample reports published on this site. Both are composite products built for demonstration, assembled from patterns that appear across shipped products. No client is implied. The leaks are real patterns; the product they are illustrated on is not a real company.

1. The empty first turn

What it looks like. The user arrives at the moment the product is supposed to start helping and finds a blank input, a cursor, and nothing that tells them what to type. In the sample assistant flow, the task-driven user needs two abandoned drafts before composing a first prompt; the curious user opens with "what can you do?" because nothing else was offered. On a screen product the same leak is the empty dashboard, the blank canvas, the form with no example.

What it costs. This is the highest-severity finding in the sample critical-flow report, because the drop happens before the product has demonstrated any value at all. A user who leaves here never learns what they were leaving.

The shape of the fix. Do the first turn for them. Offer three things the product can do right now, in the user's language, and make one of them a single tap. This is almost always a small effort, which is why it sits at the top of the "ship this sprint" bucket.

2. Confidence without provenance

What it looks like. The product gives an answer, a number, a recommendation, and gives no indication of where it came from or how sure it is. In an assistant, this is fluent prose with no source. In a checkout, it is a delivery date with no basis. In a dashboard, it is a metric with no definition.

What it costs. Trust that is not calibrated is trust that breaks all at once. The first time the confident answer is wrong, the user re-rates every earlier answer, and the product cannot earn the rating back with copy.

The shape of the fix. Show the basis, or show the uncertainty. "Based on your last three orders." "Usually, but check with your carrier." A source link. The fix is rarely more than one line, but it has to be a line the product is honest enough to write.

3. The dead-end apology

What it looks like. The product cannot help, says sorry, and stops. No alternative, no human, no "try this instead." In the sample assistant flow it is an apology with no fork. In onboarding it is the validation error that names the problem and not the way out. In checkout it is the declined payment with a single "try again."

What it costs. Every dead end is an exit. The apology does not soften that; it confirms to the user that the product has run out of ideas.

The shape of the fix. Treat failure as a fork, not a terminus. Every "I can't" gets at least one "but you can": a different path, a human, a saved draft, a way to come back. The sample report lists this fork among the first fixes to ship because it is cheap and it stops a leak that is otherwise invisible in analytics.

4. The money moment that hides its consequences

What it looks like. The user is about to change something that costs them, a plan, a quantity, a subscription, a delivery option, and the product does not say what changes as a result. In the sample full-product report this is the plan-change flow: the consequence lives in an unwritten modal, and the leak converts a plan change into a support ticket and a grudge.

What it costs. This is the leak that shows up in support volume and refund requests rather than in drop-off. The user completes the action, discovers the consequence later, and blames the product for hiding it.

The shape of the fix. One sentence, in the product's own voice, at the moment of the decision, stating what changes for the user. Not a legal paragraph. Not a tooltip. The sentence.

5. The edges in a different voice

What it looks like. The core of the product explains itself well. Then the user reaches settings, billing, account, permissions, and the copy changes register: terse, technical, silent. In the sample full-product report this is the settings page that answers in a different voice. The product teaches users to expect explanations, then goes quiet exactly where the consequential controls live.

What it costs. Users conclude the quiet parts are the dangerous parts and stop touching them. Features go unused, and the ones that matter for retention, like notification and plan controls, are exactly the ones in the quiet zone.

The shape of the fix. Bring the centre's voice to the edges. Each consequential control gets the same one-sentence explanation the onboarding already gives. This is copy work, which is why it lands in the "next sprint" bucket rather than a redesign.

Why five, and why ranked

A full audit of one flow runs to many more findings than five, each with its severity, evidence, cost, fix and effort. The teardown is not a shorter version of that list. It is the answer to a narrower question: of everything leaking in this flow, which five cost you most, and what is the fix for each? Ranked, because a list without an order is a way of avoiding the decision. If you later want the full plan, the teardown counts toward a full audit within 30 days.

Which five are leaking in your flow?

One booking, onboarding or checkout flow, walked as a real user. The five leaks costing you most, ranked, each with its fix, in 48 hours.

See the teardown — \$350 → Read the sample report →

Originally published at perex.design.

My Content Agent Posted 15 Times in a Month. It Got 6 Followers. The Fix Was Teaching It to Refuse.

Josue Perez — Tue, 22 Sep 2026 16:07:19 +0000

For a month, an agent ran my Instagram. Every YouTube Short I published got crossposted automatically: upload the video, post the reel, log it, move on. Nobody had to touch anything.

It worked perfectly. That was the problem.

The numbers

I sat down with the account's Insights for the last 30 days:

15 posts
987 organic views from 568 people — 83.6% of them non-followers
28 interactions — every single one from people who already followed me
90 profile visits → 6 follows → 3 link taps
$0 from the channel

Strangers were watching. None of them did anything.

The winner wasn't a winner

One post had 1,283 views, about seven times anything else. I'd been treating it as the proof of what works.

It was a $3 boost. About 1,255 of those views were paid. Organically, that post did roughly what everything else did.

First lesson, and it's cheap: before you copy your winner, check whether you paid for it.

The boost still taught me something. 1,255 targeted views produced 33 profile visits, a healthy 2.6%, and almost no follows. The creative pulled people in. What they found once they got there didn't hold them.

What the agent actually did

Here's the caption logic the pipeline ran all month:

caption = (title or "New video on <old brand name>").strip()

That's the whole caption strategy. The video's title, and if there wasn't one, a placeholder carrying a brand name I'd stopped using.

In practice:

Most captions were a bare title: one line, no context, no keywords, no reason to act.
Three captions were literal filenames, like signal-05-name-the-failure. The slug went out as the post.
Nothing linked anywhere, nothing said who made the video, and nothing asked for anything.

The profile those videos pointed to still described an older version of me, with a different bio, a different category, and a logo instead of a face. So a stranger who liked a reel and tapped through met someone who didn't match what they'd just watched. Most of them left, which is what I'd have done too.

The agent automated the part that was easy to automate, which was throughput, and it quietly defaulted the parts that carry trust: context, identity, and the ask. It didn't only fail to help with those. It scaled the mismatch 15 times.

The fix: no human caption, no post

The patch is small, and it goes in this week. A post ships only if a person has written its caption:

caption_file = captions_dir / f"{video_id}.txt"
caption = caption_file.read_text().strip() if caption_file.exists() else ""
if not caption:
    log(f"skipped {video_id}: no human caption")  # retried next run
    return

No file means no post, and nothing is lost. The video stays queued and goes out on a later run, once the caption exists. The caption itself has a simple shape: a hook, one idea, one call to action.

Three rules I'm taking to every agent I build

1. When an agent is missing a human input, its default should be "don't ship," not "ship a placeholder."
The bug wasn't a crash. It was a fallback. Placeholders feel safe because nothing breaks, but in anything public, a placeholder is a decision you didn't make that still goes out under your name.

2. Measure the funnel, not the output.
"15 posts published, 0 errors" was true and useless. The numbers that mattered were further down: profile visits, follows, link taps. Every one of them was sitting in Insights all month, and my pipeline never looked at them.

3. Change one thing at a time.
The tempting move after a bad month is to post more, change the style, switch the platform, and rewrite the bio all in the same week. Then nothing is learnable. I'm shipping the caption gate and the profile rewrite as two separate changes, each measured against this month's baseline.

Capability is not judgment

I've written before that access is not permission: being able to read something doesn't mean an agent should. This is the same idea from the publishing side. Being able to post doesn't mean the agent knows what's worth saying.

Automate the throughput. Gate the judgment.

I design AI and agentic products, focused on the moments where humans and automation hand off to each other. More at perex.design.

Access Is Not Permission: What I Learned Giving an AI Agent the Keys to My Accounts

Josue Perez — Thu, 03 Sep 2026 15:19:07 +0000

Most people wire up an AI agent and then discover what it can do. I did it the other way round: before I gave an agent access to my accounts, I wrote down what it wasn't allowed to do — while I was calm, because I knew I wouldn't be calm later.

That document became a permission board. It's real, it governs agents I actually run, and I've since put an interactive version of it on my site so people can set the levels themselves and watch the agent accept, hold, or refuse. This post is about the one distinction the board taught me, and the one mistake it didn't prevent.

Three levels, consulted before every protected action

Every capability the agent has sits at one of three levels:

Acts alone — it can do this without asking.
Drafts only — it prepares the action; a human approves before anything leaves.
Never alone — it doesn't do this, full stop.

The agent consults the board before any protected action. That sounds like ordinary access control, and in one sense it is. The interesting part is what happens when you try to talk the agent past it.

A policy can be argued with. An absence can't.

Here's the experiment I ask people to run on the interactive board: set Send a DM to green — "acts alone" — and then ask the agent to message someone.

It still refuses. Not because the policy says no; you just told the policy yes. It refuses because on this system the messaging function was never built. There's no code path to argue with.

That's the distinction in the title. Access is what a policy grants. Permission, in the sense that matters for safety, is whether the capability exists at all.

A policy file is a set of words, and words can be pressured. A well-crafted prompt injection, a bad inference, a compromised agent, a malicious instruction hidden in a web page it reads — each of these is, at bottom, an attempt to get the agent to reinterpret what "permitted" means. A capability that doesn't exist survives all four equally. It can't be prompt-injected, because there's nothing to inject into.

This changes how I design agent systems. The first question is no longer "what should this agent be allowed to do?" It's "what should this agent be unable to do?" — and then, for the things it genuinely must be able to do, "which of those need a human between draft and send?"

(For precision: two of my channels do carry one narrow, templated first-contact acknowledgement, and that one is governed by policy rather than absence. The publishing paths have no messaging function at all.)

The mistake that cost me something

Here's the part I'd rather not have to write.

My rules originally lived in a file the agent could edit. I'd written careful boundaries and then stored them somewhere the thing being bounded had write access to. Nothing dramatic happened — but the moment I noticed, I understood that the board had been advisory the entire time. An agent that can rewrite its own permissions has no permissions; it has suggestions.

Now the file is mounted read-only. The agent can read its permissions and cannot change what "permitted" means. That's a one-line change in infrastructure and a fairly large change in what the word "boundary" is worth.

The honest limit

None of this makes an agent safe. I want to be precise about that, because "safe" is the word people reach for and it's the wrong one.

What a board like this does is bound the blast radius when the agent is wrong — which is a different goal, and a far more achievable one. You are not preventing mistakes. You are deciding, in advance and in calm, how large a mistake is allowed to get.

It also can't stop the first bad action in a category you left open. It can only stop the second. I know this because I left one open, and found out the way you'd expect.

If you run agents

Three things I'd do before the agent does anything real:

Write the board first. Not after the first incident. Levels per capability, and be honest about which ones are "never alone."
Prefer absence to policy for anything irreversible. If the agent never needs to send, delete, or pay, don't build the function and then forbid it — leave it unbuilt. Absence is the only rule that holds under pressure.
Make the rules something the agent can read and cannot write. Otherwise you've written a wish list.

The interactive board — with the refusal you can test yourself, and the flaw I found in my own system left in on purpose — is at perex.design/permission-board.

I'm Josué — a UX and product designer working on human–AI interaction: consent architecture, agent governance and the trust patterns that decide whether people can rely on an AI acting on their behalf. More at perex.design.

Six Dimensions for Evaluating Voice Agent UX (A Framework, Not a Feature List)

Josue Perez — Tue, 01 Sep 2026 12:27:01 +0000

Most voice agent reviews I've read grade on two things: does the transcription work, and does the response sound natural. That's a speech-quality checklist, not a trust checklist. It tells you nothing about whether the thing is safe to put in front of someone who doesn't know it's a language model, or whether it fails gracefully when it inevitably misunderstands.

I've spent the last few months building a research instrument for evaluating voice agent behavior — not benchmarking latency or word-error-rate, but the relational behavior: what the agent does at the moments where trust is actually won or lost. I'm publishing the framework here, honestly labeled as a framework: a structured way to look at a voice interaction, not a set of finished findings with numbers attached. If you're designing or shipping a voice agent, these are the six places I'd tell you to look before you ship.

Why speech quality isn't the right unit of analysis

A voice agent can have flawless TTS and still be a bad interaction, because voice removes almost every visual affordance we normally rely on to communicate system state. There's no spinner, no "typing…" indicator, no button that says "end conversation," no visible list of what the thing can and can't do. Everything has to be communicated through timing, wording, and turn-taking, or it isn't communicated at all. That's a UX problem before it's an engineering one, and it needs its own evaluation lens — the six dimensions below, each a place where a voice interface makes an implicit claim about what kind of thing it is, whether the designer intended it to or not.

The six dimensions

1. Conversation journeys. Map the actual paths a user takes through a session — not the happy-path script, the real branches: someone who starts a task and abandons it, someone who circles back after a tangent, someone who tries to correct course three turns in. If you've only designed for the linear happy path, you've designed for a minority of real sessions.

2. Memory and forgetting. What does the agent remember across turns, and — just as important — what does it visibly forget, and does it say so? A voice agent that silently drops context earlier in the conversation isn't just annoying, it's dishonest about its own state. If memory resets between sessions, disclosing that is a design decision, not an edge case to skip.

3. Silence and hesitation. Dead air in a voice interface reads as a signal whether you intend it to or not — a pause can mean "processing," "confused," or "broken," and users can't tell which unless you design for it. This is one of the most under-designed surfaces in voice UX because it has no visual equivalent to steal patterns from. Filler audio, explicit "thinking" cues, or honest latency disclosure all count as real design choices — silence by default is not neutral.

4. Interruption and clarification. Can the user interrupt? Does the system interrupt itself to ask a clarifying question when confidence is low, or does it plow ahead on a guess? Barge-in handling is usually treated as a pure engineering problem — can the mic detect speech over playback — but the UX question is separate: when the agent could interrupt to clarify, does it choose to, and how does that choice get made?

5. Misunderstanding recovery. Every voice agent will misunderstand something. The design question is what happens next: does it ask a targeted follow-up, does it guess and move on, does it apologize and restart, does it quietly fail? Recovery behavior is where users form their most durable judgment about whether a system is trustworthy — a single graceful recovery can undo several turns of frustration, and a single bad one can end the session.

6. Trust formation. This is the composite dimension — how the previous five accumulate (or don't) into a user's willingness to rely on the agent for something that matters. It's also the one I'd flag as hardest to evaluate honestly, because self-reported trust and observed behavior (does the person actually delegate the next task to it) frequently diverge. Anyone running this kind of evaluation should build in a way to check both, not just ask "did you trust it?" at the end.

The design stance underneath the framework

The six dimensions are a diagnostic tool. What you do with what you find depends on a stance, and mine is the same one I use for any AI-adjacent interface: consent before capability, disclosure over deception, oversight as a required step rather than a setting the user has to find.

Concretely, that means a few things that are easy to skip under deadline pressure:

Disclose that it's an AI, early, in a way that doesn't require the user to ask. The moment of disclosure matters as much as the fact of it — "I'm an AI" said thirty seconds into a rapport-building exchange lands differently than the same sentence said in the first breath. If your product depends on the user forgetting they're talking to a model, that's not a growth hack, it's a design failure.
Treat structural trust separation as a UX principle, not just a security one. In prompt-injection defense, you keep system-level instructions and user-supplied content in different trust tiers so one can't silently override the other. The same logic applies to conversational trust: what the system claims about itself (capabilities, memory, certainty) should be structurally distinguishable from what it's inferring or guessing, and the user should be able to tell the difference by ear, not just by asking.
Make oversight a required step for consequential actions, not an optional confirmation dialog. If the voice agent can take an action with real consequences — booking, purchasing, sending, deleting — the check-before-act moment should be a structural part of the flow, not a "are you sure?" that a rushed user learns to say yes to on reflex.

Using this as a checklist

If you're evaluating your own voice agent, or someone else's, before it ships, walk at least one non-happy-path journey end to end on purpose; find every place the agent goes silent for more than a second or two and ask what that silence is communicating; force a misunderstanding and watch what happens next instead of only testing the scripted demo path; check whether disclosure happens early and unprompted rather than on request; and identify every consequential action the agent can take, then confirm oversight is structural rather than a dialog box a rushed user learns to dismiss.

None of this replaces measuring latency or transcription accuracy. It's the layer above that — the one that decides whether a technically competent voice agent is also one people should actually trust.

I'm Josué — a UX and product designer working at the intersection of interaction design and applied AI, currently building out a research practice around voice-agent behavior and AI explainability. More at perex.design.