DEV Community: Josue Perez

What a $200 Product/UX Diagnostic actually contains

Josue Perez — Mon, 02 Nov 2026 20:30:34 +0000

Most "UX review" offers describe the outcome and hide the document. This is the document, section by section, so you can decide whether it is the right first decision before you pay for it.

The Product/UX Diagnostic is the smallest engagement I sell: one user goal across up to five screens or states, 5–10 prioritized findings, and the three actions worth taking first, delivered next business day as a written report. No meeting, no revision round. Every report is written from the same template, and Josue reviews every deliverable before it is sent. Here is what that template forces the report to contain.

1. Client and scope

The report opens by restating what was agreed: the product, the one user goal, the screens or states inside the boundary, and the outcome you said matters. This is not filler. It is the contract the findings are judged against. If a finding is outside that boundary it does not appear, and if the boundary turned out to be wrong, the report says so instead of stretching.

2. Executive summary

Two things, and only two: a one-sentence diagnosis, and the three actions worth taking first. A founder or head of product should be able to read this section and act without reading the rest. Everything below it exists to justify these three lines.

3. Method and limits

This section states plainly what the diagnostic is and is not. It is an expert review of the supplied experience. It is not user research, usability testing, an accessibility certification, a legal or compliance review, or a guarantee of commercial results.

It lists the evidence that was used: the supplied URL, prototype or screenshots; the user goal and business outcome you gave me; direct inspection of the agreed experience. And it lists what was not assessed: analytics or behavioural data, competitor research, engineering feasibility or estimates, and any screens, roles or flows outside the agreed scope.

Why this matters to you: a review that hides its limits is asking you to trust its confidence. A review that states them is asking you to trust its evidence. Only the second kind is worth paying for.

4. Prioritized findings

Between five and ten findings, never more. Each one is written in the same four-part block:

Observation — what happens, described as your user would meet it.
Evidence — where in the supplied experience it is visible, so your team can go and look rather than take my word.
Why it matters — the cost to the user goal or the business outcome, in plain terms.
Recommended action — a concrete next move, bounded by what the evidence supports.

The cap is deliberate. A list of forty issues is a way of avoiding the ranking. Five to ten, in priority order, is a decision.

5. What to do next: Now, Next, Later

The findings are regrouped into three horizons. Now is what to fix in the current sprint. Next is what to plan for. Later is what to keep in view but not act on yet. This is the section your team actually works from.

6. Final quality gate and honesty footer

Before a report goes out it passes a written checklist, and it closes with an honesty footer that repeats the limits in one paragraph. If something could not be assessed because access was missing or the scope changed, that footer says it. The report never implies more coverage than it had.

How this relates to the deeper audits

The diagnostic answers one question: what should I fix first? If your question is different, the document is different. The \$350 teardown walks one complete booking, onboarding or checkout flow and returns the five leaks costing you most, ranked, in 48 hours. The \$550 critical-flow audit is the full single-flow review: every finding with severity, evidence, cost, fix and effort, an annotated walkthrough with timestamps, a "stop doing" list, and a recorded call. The sample report shows that format on a composite AI assistant. If you are not sure which depth you need, the diagnostic is the cheap way to find out, and the report will tell you honestly if it should have been something else.

Find the problems worth fixing first.

One user goal, up to five screens, next business day. Read the full offer and the intake before you decide.

See the diagnostic — \$200 → Compare all four engagements →

Originally published at perex.design.

How I audit an AI assistant flow: disclosure, pace, handoff

Josue Perez — Mon, 19 Oct 2026 19:34:54 +0000

A conversation is not a screen. The failure modes are different, the evidence is different, and a heuristic checklist alone will pass a product that is quietly losing its users' trust. This is what I do differently when the flow under audit is a chat, a voice agent or an autonomous assistant.

Walk the flow in more than one posture

A screen behaves the same for everyone who reaches it. An assistant does not. Its behaviour depends on what the user says, how they say it, and what they expect. So a single happy-path walkthrough tells you almost nothing.

In the sample critical-flow report, the assistant flow from signup to first prompt to first escalation is walked in three separate sessions as three user postures: curious, task-driven, and hostile. Every path is walked, including the ones the product team did not draw. The curious user asks "what can you do?" The task-driven user arrives with a job and no patience for a tour. The hostile user is testing whether the thing will lie, stall, or dump them. Each posture surfaces a different class of leak, and a finding that appears in all three is a different severity from one that appears in one.

Score against heuristics and against probabilistic-UX principles

Standard usability heuristics still apply to an assistant: visibility of status, error prevention, recognition over recall. But they were written for deterministic interfaces. An assistant that is right most of the time needs a second set of principles for the times it is not. In the audit I score against four of them alongside the heuristics:

Disclosure — does the user know what they are talking to, and what it can and cannot do, before they need to know?
Trust calibration — does the confidence the assistant shows match the confidence it has? Fluent prose with no provenance is a leak, not a feature.
Error as a fork — when the assistant cannot help, does the conversation branch to a next step, or end in an apology?
Handoff — when a human is needed, does the person, the context and the transcript travel together, or is the user dropped at the boundary?

Every finding then carries the same five fields as any other audit: severity, evidence, trust cost, fix, and effort. Findings are ordered by impact against effort, not by where they sit in the flow.

Three constraints that live in the architecture, not the copy

The reason a copy-level review is not enough is that the three decisions that decide whether an assistant is trustworthy are made before the first message is sent. I wrote them up as three reusable AI-trust patterns after building them into NuvAI, an assistant that helps human real-estate agents qualify and follow up with leads.

Disclosure: the right to know

The user should not have to work out that they are talking to a machine, or what it is authorised to do. Regulation is moving the same way: the EU AI Act treats "you are interacting with a machine" as a baseline. In an audit, I look for where disclosure happens, whether it happens early enough to matter, and whether the product's tone later contradicts it.

Pace: respect as a mechanic

An assistant that moves faster than the person it serves is taking control, not offering help. Pacing is a consent mechanism. In voice surfaces this is even sharper, which is why the Voice Agent Lab instruments treat pacing as consent as one of four things to observe, alongside disclosure, a post-task interview, and a handoff rubric. That study has not been run yet: no sessions, no findings, no results. The instruments are what I bring to an audit, not data from them.

Handoff: never drop the person

Every assistant has a boundary where it stops being useful. The audit question is not whether the boundary exists but what happens at it. Does the conversation escalate with its context intact, or does the user start again with a human who knows nothing? The dead-end apology, where the assistant says sorry and offers no fork, is one of the most common findings in this kind of flow.

Access is not permission

One more thing I check that a screen audit never has to: what the assistant is allowed to do on the user's behalf, and whether the interface makes that boundary honest. The permission board project exists to make that argument concrete. An agent can have access to a capability and still not have permission to use it, and a capability that was never built cannot be permitted at all. In an audit this becomes a set of questions: what actions can this assistant take alone, does the user know, and does the product ever imply an ability it does not have?

What you get at the end

The same deliverable as any critical-flow audit: a one-page executive summary, the full findings ordered by impact and effort, an annotated walkthrough with timestamps, a "stop doing" list of features actively costing trust, a 45-minute recorded walkthrough call, and two rounds of async questions over the following two weeks. The sample report shows the format on "Aria", a composite assistant assembled for demonstration. No client is implied; the format, depth and honesty are the real thing.

The status of the work behind this: the AI-trust patterns are defined on NuvAI's real stack, with validation as the next step. The Voice Agent Lab study has not been run. I say this on the source pages and I say it here, because an audit that scores your product on disclosure had better disclose its own limits.

Chat, voice and agent surfaces are home turf.

One critical flow, five business days, written report plus walkthrough call. Or start smaller with the \$350 teardown of one flow in 48 hours.

See the critical-flow audit — \$550 → See the teardown — \$350 →

Originally published at perex.design.

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.