Alessandro Zulberti

Blueprint every AI conversation for the reader nobody sees

Alessandro Zulberti — Fri, 13 Nov 2026 10:16:21 +0000

The Material of Teaching · Cross-functional working session

In this article

The decision: when AI joins a customer service conversation, design for whoever reads it next, not only for the people in it.
The method: map each conversation on seven swimlanes, so you can see where AI sits and who reads the record later.
The scenarios: twenty patterns in four groups, each with a blueprint and one question to ask.
Who does what: customer service, store operations, digital product, data protection and accessibility each own part of the chain, and someone has to own all of it.
The instrument: a blank blueprint template for a working session.

A model to adapt, not a fixed list. The scenarios describe patterns that are already common in retail service. Start from your own tickets, calls and chats, and use these to recognise what you find.

The decision this article is about: when AI joins a customer service conversation, design for the person or system that reads it next, not only for the people in it.

The situation

At a shop counter, the person you spoke to was your audience. That is no longer true. A chat becomes a log, a headset exchange becomes a transcript, a call becomes a summary, and a returns page becomes the source for a public AI tool. Each of these has a second audience: a manager, the next shift, an analytics system, another AI.

People change what they say depending on who they think is listening. When the second audience is invisible, they can’t, and neither can the service.

The field note Who’s listening? The two audiences of AI conversations sets out the argument and its sources. This article turns it into material for a working session.

The trap

Teams map the visible exchange, the chat window or the call script, and stop at the line of interaction. The reader that matters most usually sits below the line of visibility, or outside the company altogether.

How to read the blueprints

Each scenario is drawn on the same seven lanes. The order matters: every AI lane sits between the people it connects.

Lane	What it holds
Customer	The person being served.
Customer’s AI	Agents, apps and assistive tools working for the customer.
Company’s AI, facing the customer	The chatbot, voice bot or agent that stands between the customer and staff.
Staff	Colleagues the customer deals with, in store, on the phone or by email.
AI tools for staff	Transcription, summaries and suggested answers that sit between colleagues. The customer never sees them.
Team	Managers and colleagues backstage.
Company systems	Orders, logs and automated decisions.

Two scenarios add an eighth lane, outside the company: a staff member’s personal AI tool, and a recording seen by people beyond the shop.

A filled dot is a person and a hollow dot is an AI. Numbers show the order of steps. A dashed ring marks the hidden party: whoever reads, writes or listens unseen. The dashed line is the line of interaction; the solid line is the line of visibility.

The model starts from Sarah Gibbons’ Every AI System Is a Service (Gibbons & Moran, November 2026), which gives each side of the service a row for people and a row for agents. Here the lanes are reordered so each AI sits between the parties it connects, and the company’s AI is split in two: AI that faces the customer, and AI that colleagues use with each other.

Customer to company

The customer, or the customer’s own AI, speaks to the company.

The site assistant

Customer > Company’s AI

Customers tell a chatbot things they would not tell a person: the real budget, the real fitness level. They hold back once they think it keeps a record.

Company’s AI. The hidden party is the CX team reviewing chat logs. The steps are listed below the image." class="wp-image-2566" srcset="https://alessandrozulberti.com/wp-content/uploads/2026/11/ai-blueprint-site-assistant.png 1920w, https://alessandrozulberti.com/wp-content/uploads/2026/11/ai-blueprint-site-assistant-300x140.png 300w, https://alessandrozulberti.com/wp-content/uploads/2026/11/ai-blueprint-site-assistant-1024x478.png 1024w, https://alessandrozulberti.com/wp-content/uploads/2026/11/ai-blueprint-site-assistant-768x358.png 768w, https://alessandrozulberti.com/wp-content/uploads/2026/11/ai-blueprint-site-assistant-1536x717.png 1536w" sizes="(max-width: 1920px) 100vw, 1920px" />

Steps as text

Who’s listening? The two audiences of AI conversations

Alessandro Zulberti — Fri, 06 Nov 2026 11:58:18 +0000

A note on method: before publishing, I ran this piece through a peer review using the free plan of Elicit, an AI research assistant. It checked the claims against sources, flagged where the argument outran the evidence and suggested what to soften. I kept what held up and pushed back where it was wrong. An article about who reads our words, reviewed in part by a machine, felt like the right test.

Scenario under analysis

A customer is preparing for a winter walk in the hills and needs the right equipment. A few years ago that meant one conversation, between them and someone in a shop.

Now the conversation is spread across several. They start with a site assistant, typing questions late at night. In the store, they talk to a sales associate, who asks a colleague for help over a headset. That exchange, about the customer, is turned from voice into text for a manager to read. The associate answers partly from a suggestion on a screen. A week later, the customer’s own shopping agent places the follow-up order with the retailer’s system. Behind the scenes, the associate’s shift ends and the next colleague reads a summary of what happened. And when the jacket leaks a month later, the complaint and the photo that follow may have been written and made with AI too, and so may the company’s reply.

Every step is a conversation. Few of them are between the same two parties, and nobody involved can see the whole chain. The journey is a composite, built from patterns rather than from one observed case.

The chain also runs in two directions. Some conversations go from the customer to the company: a question, an order, a complaint, a claim. Others come back from the company to the customer: an answer, a decision, a call, a label on a shelf. This note follows both, and stays with service: customer service, staff on the shop floor, the conversations people have when they need something. Marketing is a different conversation, and it is left out.

Two audiences

At each step there are really two questions. Who am I talking to now? And who will read this later?

At a shop counter, the two answers were almost the same: the person in front of you, and whatever they remembered. In this chain they come apart. The listener you can see is often not the audience that matters most. That audience is whoever reads or processes the record next, and nobody in the conversation can see them. Two audiences is a lens rather than a complete map: there are often more, from a colleague within earshot to the company that runs the system. But the split between now and later is the one that changes what people say.

The roles in the conversation

The customer

We shape what we say for whoever we think is listening. Linguists call this audience design: we speak one way to the person in front of us, another when we know someone else can hear, and another again when we don’t know they are there. The customer speaks differently depending on who they think is listening, and in this chain that listener keeps changing. So does the company.

The associate (customer to staff, and back)

The baseline. A person reads the pause before the answer, the hand that goes back to the jacket the customer just said they didn’t like, the gap between what is said and what is meant. Nothing is kept word for word. But this baseline was never neutral. Reading the room works best for people whose signals match what the reader expects, and less well for a blind customer, a colleague who communicates differently, or anyone whose face and voice don’t follow the usual patterns.

Customer to company

Half the chain runs from the customer towards the company. More and more often, the customer brings their own AI to it.

The site assistant (customer to company’s AI)

If nothing here seems to judge them, the customer can be franker: the real budget, the real fitness level, the doubt they wouldn’t admit in front of someone who knows more than they do. But that openness depends on what they think happens to their words. Research on service AI finds people share more sensitive information when they believe the system can’t judge them, and that the preference weakens when they want support or expect what they say to be passed on. A machine is not automatically a safe listener. It only feels like one when both the judgement and the record seem to be absent.

The shopping agent (customer’s AI to company’s AI to staff)

The customer’s intent is compressed into a request, interpreted by the retailer’s system and handed on to staff. Umberto Eco (the Italian semiotician and novelist, author of The Name of the Rose) argued that every text is written for a Model Reader: the reader it expects, and quietly teaches how to read it. Here the idea applies directly: the retailer now writes its product data for a new reader, the customer’s agent, which reads structured fields rather than shop windows. Two translations later, it is hard to say what the customer actually authorised, what the agent inferred and what the retailer carried out.

The agent on the phone (customer’s AI to staff)

The phone rings, and a pleasant voice asks whether the waterproof version is in stock. The associate answers as they would answer anyone, without knowing they are talking to a machine. The rule that an AI must say it is an AI was written to protect the people it talks to. Here, the person who needs to know is the member of staff.

The complaint (customer with AI to staff)

The jacket leaks, and the customer writes to complain, with help. The email is long, confident and full of references, some of them wrong. For a customer who struggles to write, the AI is what makes the complaint possible at all. For the person reading it, the problem is buried somewhere in the length. So the company asks to speak by phone: not to hear more, but to hear the customer without the machine. The call is a check on who is speaking. It also excludes the customer who chose writing because speaking is harder for them.

The photo (customer with AI to company’s AI to staff)

The refund request arrives with a photo of the damage. A photo used to be evidence; now it may be generated. The retailer’s system checks the customer’s image for signs of AI, and the customer is quietly treated as a suspect. Honest customers pay for the dishonest ones: another photo, a video, a trip back to the shop.

The review (customer’s AI to company and the next customer)

The customer asks an AI to write the review. The company reads it, and customer service may reply, often with a draft written by AI. Months later, another customer asks an AI to summarise the reviews before buying. Machines write for machines, and the people at either end may never read a word of it. Reviews belong here because the reply is a service conversation: it is often the only answer a dissatisfied customer gets in public. Fake reviews have been banned in the UK since April 2025, and a review drafted by AI about a genuine experience is probably not fake in law. But nobody reading it can tell whose words they are.

Company to customer

The other half of the chain runs back. Some of what the company says to the customer is first said about them, among colleagues. Some of it reaches the customer through machines, the company’s or their own.

The transcript (staff to staff, about the customer)

The associate turns away and asks a colleague over the headset: is the waterproof version in stock, and can we refund a jacket bought last week? The conversation is about the customer, but the customer isn’t in it. It is turned from voice into text, and a manager can read it.

Eco built his idea of the Model Reader for written texts: a writer can’t see the reader’s face, so the text has to imagine one. When we talk, we check each other constantly, through a nod, a pause, a change of tone. A transcript turns talk into text, and the speakers lose that check without noticing. The two colleagues are now, in effect, writing for a reader they can’t see: the manager, and whoever opens the record later.

The talk also changes medium. Most of the words survive, though not all, and not equally for every voice. What doesn’t survive is everything that was never a word: tone, hesitation, the half-sentence abandoned midway. Knowing the transcript exists changes the talk itself. In one study of meetings, hearing participants changed how they spoke once their words were being captioned automatically for Deaf colleagues. That study measured how people spoke, not what they chose to say. Research on workplace monitoring points further: people under monitoring shared less. Whether colleagues on a transcribed channel stop asking the questions that make them sound unsure is a question for fieldwork, and an important one.

The customer, meanwhile, has become the subject of a record they never spoke into, and nothing in the shop tells them it exists.

The handover note (staff to AI to staff)

The next colleague reads the summary, not the conversation. They are not overhearing the original talk. They are the record’s future audience, reading something already transformed. Whatever the summary dropped never reaches them, and nothing in it shows that anything was there. In one evaluation of AI note-taking tools in primary care, omissions were by far the most common error. And whatever the next colleague says to the customer starts from that summary.

The prompted answer (staff with AI to customer)

The customer hears a person but receives the machine’s answer. In Erving Goffman’s terms, the associate is the animator who speaks the words, the system is the author who wrote them, and the retailer is the principal who answers for them, though often nobody makes that clear. The trust the associate has earned is lent to the system, and when the answer is wrong, it is the associate who loses it.

The reply (customer service with AI to customer)

The complaint gets an answer, and the answer was drafted by AI too. It is polite, complete and slightly too smooth: it apologises for things the customer didn’t say and misses the one thing they did. Two machines have now exchanged letters on behalf of two people. If each side’s AI is summarising the other’s, a complaint can be closed on paper without anyone having properly read it.

The decision (company’s AI to customer)

The photo is checked, and the refund is refused. The customer receives the outcome, often without knowing whether a person ever looked at it. A refusal with no one behind it is hard to argue with and harder to accept. What the customer needs is not only the answer, but who gave it and how to ask a person to look again.

The call (company’s AI to customer)

The phone rings about the delivery, and a voice asks the customer to confirm a time slot. It sounds like someone from the shop. In the EU, it now has to say that it isn’t. The customer has a few seconds to decide how much to tell it, and whether anyone will hear it later.

The customer who records (staff to customer’s AI)

Here the roles reverse. A customer wears glasses with a camera, or holds up a phone that transcribes the conversation. Now the associate is the one speaking to a listener they can’t see, and the second audience belongs to someone else: a video, a feed, a summary in an app. The staff member gets none of the notices this note asks retailers to give customers.

The customer’s AI reading the shop (shop to customer’s AI to customer)

A blind customer points their phone at the shelf, and an app reads the labels aloud. This is the role where AI most clearly opens a door. It also gives the shop a new reader. Shelf labels, packaging and price tickets were designed for a glance from a person; now they are also read by a machine on someone’s behalf. A label a camera can’t read is a label that customer can’t read either.

The translated counter (staff to AI to customer, and back)

A customer and an associate who don’t share a language talk through a translation app. Each hears a fluent version of the other. Neither can tell what was smoothed, softened or lost: the joke, the hesitation, the “I think” before a promise. The fluency hides the gap, which may be exactly why both of them trust it.

The interface is the listener’s face

Nobody sees the listener directly. They see an interface: a chat window with a name and a friendly avatar, a screen the customer can’t see, a microphone with no light, a summary card with no source. Each one is a sign that tells people who is listening, and people believe it.

Clarisse de Souza (a Brazilian computer scientist who founded semiotic engineering, a theory of interface design) describes every interface as a message from its designers: here is who we think you are, and here is how to talk to us. In this chain, that message is often silent about the one thing people most need to know, which is the second audience.

It helps to separate three things. The signal: the light is on. The inference: it is listening to us. The ground truth: what is actually stored, for how long, and who can open it. Most of the design problems in this chain sit in the gaps between the three. A friendly chat window can suggest a private conversation while the log is kept for months. A recording light can be on while nobody says who reads the transcript.

The law has started to catch up with the first audience. In the EU, from August 2026, an AI system that talks to people must tell them it is an AI, unless that is obvious, and the notice must meet accessibility requirements. The law says much less about an AI that is only listening in on a conversation between two people.

Tensions

Openness versus memory

The same quality that makes a machine easy to talk to can make it hard to trust. Feeling unjudged invites disclosure, including things like a disability someone would rather not explain to a stranger. Expecting a record invites caution. Customers may open up to the assistant while colleagues go quiet once their words become a transcript. It is the same technology, imagined as two different listeners: one that hears without judging, one that keeps everything.

Authority versus accountability

Fluent output arrives with more authority than it has earned. The colleague who raised a problem months ago loses to the answer that sounded finished. Trust here comes in three kinds that rarely move together: it hears me, its answer is right, and my words will be handled properly. A system can win the first and fail the other two. When it is wrong, nobody quite owns what it said, except the person who happened to relay it.

Authorship versus authenticity

Once the customer’s words, photo or voice may be made by a machine, the retailer starts to doubt the customer’s own signs. The complaint may not be in their words, the damage may not be real, the caller may not be a person. The usual response is a more demanding channel: a phone call, a video, a visit. The Financial Ombudsman Service has said it is phoning more complainants because AI-written submissions bury the real problem, and public bodies face the same problem with AI-written information requests. But the more demanding channel costs most for the people who relied on AI to get in touch in the first place.

The doubt runs the other way too. A customer who receives a smooth, complete reply, or a refusal with no name on it, starts to wonder whether anyone at the company read their complaint at all. Each side now asks the same question of the other: is there a person behind this?

Compression versus context

Each pass through AI compresses. The customer’s situation becomes a query, the conversation becomes a transcript, the transcript becomes a summary. Each step is meant to save time, and the context lost along the way is cumulative and invisible.

Eco would say that meaning depends on an encyclopedia: the shared knowledge a community draws on to make sense of what is said. There is a general one, which everyone shares, and smaller local ones, which only insiders have. A machine trained on the world carries much of the general encyclopedia. What it mostly lacks is the local one: how far you go for a customer when the policy says no, which exception is fine, what a regular means by “the usual”. Where it lacks the local, it fills in with the general, and it sounds just as sure.

Access versus accuracy

For some people the transcript isn’t a loss; it is the conversation. A Deaf customer reading live captions, a colleague who takes in written information more easily than speech, someone who prefers typing to speaking: for them, text is the way in. But speech recognition doesn’t hear everyone equally. It makes more mistakes with some accents, with stammers and with speech affected by disability, and it rarely says where it struggled. The people who most need the text are often the ones it gets wrong.

Speed versus formation

The informal talk a transcript discourages, and the conversation a handover note replaces, are where colleagues used to learn from each other: the aside, the honest “I’m not sure”, the workaround passed on at the till. Faster communication can mean slower judgement. That is the same debt I wrote about in The abstraction debt, seen from the side of conversation rather than work.

Design opportunities

Each of these separates what the interface shows from what the system actually does. One without the other is decoration.

1. Make both audiences visible when they matter

Label the assistant as AI before the first message. Beside the place where the customer types, show whether the conversation is saved, until when, and who can read it. Do this before asking for anything sensitive, and offer a route to a person at the same point.

2. Decide what the transcript is for, and tell both audiences

Tell staff plainly what is transcribed, who reads it, for how long and why. Give them a channel, or a moment, that isn’t kept, for the questions they would rather not have on record. Agree what can be said about customers on a transcribed channel: the jacket and the refund, not the customer’s name or circumstances. Where a customer’s own voice could be captured, there is no screen to tell them, so tell them in layers: a sign at the entrance and at the counter, a word from the colleague, a visible cue on the headset and a link to the full notice. Each layer reaches someone the others miss. And tell staff what they can do when the customer is the one recording.

3. Show where the answer came from

Mark AI-drafted answers on the associate’s screen before they are read out, with the policy or source beside each claim. Ask the associate to check, edit or reject the draft, and record who approved what was finally said. Do the same for written replies and automated decisions: say when a reply was drafted with AI or a refusal was made by a system, and tell the customer how to reach a person who can look again.

4. Confirm what the agent is about to do

Before the customer’s agent places an order, show the customer exactly what will be submitted and what data will be passed on. Record what they authorised separately from what the agent inferred. This stage has the least evidence behind it, so pilot it before rolling it out.

5. Let the summary carry its doubt

Label handover summaries as AI-generated, link each claim to its source, and separate what was observed from what the model inferred. Let the outgoing colleague correct the summary before the next shift reads it.

6. Give every voice the same chance of being heard correctly

Test transcription and summaries with the people most likely to be misheard: Deaf and hard-of-hearing staff and customers, people with regional accents, people who stammer. Show where confidence is low, and let people check and correct the record of what they said. The same applies to what the shop says back: test labels, packaging and translated answers with the apps customers use to read and hear them.

7. Check who is speaking without closing the door

When a complaint, a photo or a call needs checking, offer more than one way to do it: a phone call, a captioned video call, a visit or a few written questions answered without AI. Ask the customer which suits them. A check that only works by phone is a barrier, not a safeguard.

Behind all seven sits the same groundwork: short, defined retention periods, limits on who can open a transcript or summary, and a log of who did. A visible indicator is a promise. That groundwork is what keeps it.

The listener we design for

Service design has always listened to what people say: the interview, the complaint, the question at the counter. That was never the whole of what they meant, but it was said to someone they could see, and that person was, more or less, the audience.

That is no longer true. People now speak to one listener and are read by another. We design for the listener people can see. The harder problem is the audience they can’t: whoever reads the record next.

Sources

Bell, A. (1984) Language style as audience design. Language in Society, 13(2).
de Souza, C. S. (2005) The Semiotic Engineering of Human-Computer Interaction. MIT Press.
Digital Markets, Competition and Consumers Act 2024: ban on fake reviews, in force from 6 April 2025.
Draper, T. C. et al. (2025) Clinical AI scribes in primary care: accuracy, error severity and implications for clinical practice. BMJ Digital Health & AI. doi:10.1136/bmjdhai-2025-000092
Eco, U. (1979) The Role of the Reader; (1984) Semiotics and the Philosophy of Language.
EU Artificial Intelligence Act, Article 50(1) and 50(5). Regulation (EU) 2024/1689
Financial Ombudsman Service (2026) Embracing AI’s transformational impact on consumer complaints. financial-ombudsman.org.uk
Financial Ombudsman Service, comments by chief ombudsman James Dipple-Johnstone, reported in Insurance Business UK, October 2026. insurancebusinessmag.com
Goffman, E. (1981) Forms of Talk. University of Pennsylvania Press.
Holton, C. F. and Fuller, R. M. (2006) The impact of electronic monitoring on hazard communications. HICSS ’06. doi:10.1109/HICSS.2006.467
Kim, T. W. et al. (2022) Do you mind if I ask you a personal question? How AI service agents alter consumer self-disclosure. Journal of Service Research. doi:10.1177/10946705221120232
Koenecke, A. et al. (2020) Racial disparities in automated speech recognition. PNAS, 117(14). doi:10.1073/pnas.1915768117
Mujtaba, D. et al. (2024) Lost in transcription: identifying and quantifying the accuracy biases of automatic speech recognition systems against disfluent speech. NAACL 2024. aclanthology.org
Seita, M. et al. (2018) Behavioral changes in speakers who are automatically captioned in meetings with Deaf or hard-of-hearing peers. ASSETS ’18. doi:10.1145/3234695.3236355
Urqueta Alfaro, A. et al. (2026) Automatic speech recognition underperforms with diverse accents as measured by word error rate and a semantic similarity measure. Disability and Rehabilitation: Assistive Technology. doi:10.1080/17483107.2026.2716598

The post Who’s listening? The two audiences of AI conversations appeared first on Alessandro Zulberti.

The abstraction debt: what happens to the time AI gives back?

Alessandro Zulberti — Thu, 05 Nov 2026 15:21:24 +0000

These notes follow on from the panel AI and the future of retail at The Retail Bulletin’s Retail Technology Summit in London on 4 November, and from the Q&A after it.

Start backstage

How do retailers make sure AI solves real customer problems rather than adding more technology? My answer is that the real problem usually isn’t where the AI is pointed.

Much of the visible conversation about AI sits in front of the customer: the chat assistant, the personalised feed, the agent that will one day shop on someone’s behalf. But a customer-facing AI inherits everything behind it. If a return depends on a handover between two teams that don’t share a case history, the assistant will explain the process fluently and the customer will still repeat themselves. If the stock data is wrong, the agent will confidently recommend a product that isn’t there. In service-blueprint terms, what happens in front of the line of visibility depends on work behind it that nobody on the front stage can see.

So my instinct is to start backstage, with the repetitive, rule-bound work of reconciling, routing, tagging and checking, where AI can be genuinely useful and where failures are easier to contain. Backstage is also where an organisation keeps what it has learned: in its processes, its exceptions and its workarounds. That matters later.

What the model forgot

The argument of this piece started at my own desk.

I was using an AI to triangulate several studies inside one long conversation: usability tests, tree tests and card sorts. The synthesis that came back was convincing. It had structure, it had themes, it cited findings across the studies. At some point, though, the model had quietly stopped drawing on the earlier tests. Nothing in the output said so.

I noticed because I had read the raw reports before feeding them in, and because I already had doubts about the quality of some participants. That doubt existed outside the synthesis. Nothing in the synthesis could tell me it was missing.

My role in that session wasn’t to check the AI. It was to carry into the conversation something the conversation could no longer tell me it had lost.

It changed how I use these tools. I now spend more time asking them to falsify what they have synthesised. Synthesis asks what the data says; falsification asks what it forbids. A model can be asked to challenge its own conclusion, and it will. What it can’t do is restore evidence that has already fallen outside its frame. And when you ask it to critique its synthesis, the critique arrives in the same fluent, confident register as the synthesis did. The frame defends itself.

Using these tools has another cost I didn’t expect. To get them working, I have to write out things I used to do without thinking. I become the documentation of my own expertise.

Many AIs, no overview

Now scale that conversation up to an organisation.

Every team now has tools with AI built in, and not only the digital ones: the warehouse system, master data, store operations, finance, analytics, session replay, the CRM, site search, customer service, the research repository. Each produces its own summary inside its own frame, and those frames rarely line up. The customer exists whole only in the space between them: the behavioural pattern in one tool, the hesitation in a recording in another, the complaint in a third, the stock that never reached the shelf in a fourth.

What’s missing is the triangulation across those summaries. The risk is that nobody owns it: each team trusts its own tool’s summary, and the overview falls between them. The tempting answer is another AI to summarise the summaries. But each additional layer can hide what fell outside the frame before it, so a summary of summaries risks compounding the loss. The work belongs to a person, assisted by AI: using it to retrieve and line up the raw material behind each summary, not to merge them. Deciding what conflicts and what is missing stays human.

There is a second problem, about pace rather than knowledge. AI doesn’t arrive evenly. One team adopts it early and becomes much faster: more campaigns, more product pages, more analysis. If the teams further along the flow haven’t moved at the same speed, that gain doesn’t reach the customer. It piles up at the next handover, in product data waiting to be enriched, or in a warehouse receiving demand it can’t fulfil. A local improvement becomes a bottleneck for the whole service. Seen one team at a time, every AI project looks like progress. Only a view across the whole flow, a service blueprint rather than a team roadmap, shows where the speed is actually going.

The more AI each team has, the more valuable the person who reads across all of it becomes, and the less likely the organisation is to have named that role.

The colleague who told you months ago

I’ve caught myself trusting a tool over a person. A colleague raises a problem. Months later I put the same question to an AI, and I take its answer more readily than I took theirs. Only when I dig into the output do I find what’s wrong with it, and realise it’s exactly what the colleague had pointed out. Then they say: I told you that months ago.

The knowledge was in the room. It just carried less authority than a fluent paragraph. There is a name for leaning too hard on automated output, automation bias, but nobody needs the literature to recognise that moment. The cost isn’t only the months lost. It’s a colleague learning that their warning counts for less than an answer from a tool.

So a team needs at least one route to a conclusion that didn’t start from the same model, prompt or data: pen and paper, raw data read directly, customers observed, an expert view taken before anyone sees the synthesis. Someone has to be allowed to argue the contrary. The usual condition for dissent is that it brings concrete logic, because a contrarian by habit gets tuned out. The uncomfortable part is that the colleague who told you months ago usually had the logic. They lost to the answer that sounded finished.

Human judgement belongs on both sides of the model: context, data and doubt before it; validation against real customers after it.

That second side is where the difference between a transcript and a person shows. A transcript preserves what was said. Someone in the room also has access to the pause before the answer, the hand that goes back to the product the customer just said they didn’t like, the gap between what people say and what they do. Much of what research is for lives in that gap, and it never reaches the transcript.

The time AI gives back

The store is where the time AI saves becomes concrete, and the rota is the clearest example.

Scheduling is an obvious optimisation problem for AI: matching staff to predicted demand while respecting constraints around hours, availability and cover. The hard question is what it optimises against, and who decides what a store’s performance actually is.

Here is a hypothesis rather than a case. Take an experienced sales associate who sells more than anyone else. The optimiser, reasonably, schedules them against every peak. The newer colleague gets fewer quiet hours working alongside them. Productivity goes up. What the newer colleague would have learned by standing next to them goes down. Six months later the experienced associate leaves, and the store’s numbers fall for reasons nothing in the rota explains.

The optimiser improved the metric while weakening the thing that produces future performance. It would just as happily do the opposite, moving the best people off the peaks so others can learn from them, if the business told it that was what performance meant. The tool doesn’t make that choice. Whatever the business feeds back to it as success does. That is the line I’m trying to find: where an AI judging people’s work should stop, and where a person has to decide what counts.

Some knowledge moves as instructions. Other knowledge moves through contact: watching someone handle an awkward customer, noticing the moment they stop explaining and start listening, seeing how they recover when the process doesn’t fit. None of that is in the manual. It passes between people who work side by side.

AI can document the procedure. The harder question is whether we keep the conditions in which judgement develops.

The abstraction debt

Junior roles are not cheaper versions of senior ones. The years between junior and senior are the formation of judgement: mistakes made near someone who reads the situation differently. Much of the work AI now absorbs is the work through which that judgement used to form: first-pass synthesis, tagging, drafting, the checking before and after a model runs.

There is a tension here with where I started. The backstage work I’d hand to AI first is exactly the work through which people used to learn how an organisation really runs: where the exceptions are, which workaround holds the process together. Automating it can still be the right decision. But removing work and removing learning are not the same decision. If the work disappears, the learning has to be designed back in somewhere else.

If it isn’t, nothing fails dramatically. The procedures are still there, the outputs keep arriving, the slide decks look like research. What goes is the capacity to read what those outputs can’t show. That is what I mean by abstraction debt: the organisation keeps the appearance of a capability after the experience that produced it has started to disappear.

It also changes what an organisation has to know about its own knowledge. There used to be two places to look: what people know, and what is written down. Now there is a third: what the AI can retrieve and act on. Learning teams now write for employees and for the AI systems, agents and skills those employees use or build. The question is no longer only whether knowledge is written down. It is whether a machine can retrieve it, whether the machine’s version is faithful, and whether people still know enough to notice when it isn’t.

And some knowledge was never written down at all. Every company has unwritten rules: how far you go for a customer when the policy says no, what the brand would never say, which exception is fine and which one isn’t. Nobody can hand those to an AI yet, because nobody has put them into words. People learn them by working inside the company, from the people who already know them. That shared experience is where a brand actually lives, and it is the first thing an abstraction debt erodes.

What leaves with the employee

What happens when an employee leaves? More precisely: what happens to the way they used AI?

I don’t think anyone has a good answer yet. The obvious one is to keep their prompts, agents and documentation. We can keep the prompt. We can keep the agent, the repository, the process, the training material. None of it necessarily keeps the judgement that made them useful: knowing why they were right, when they were wrong, and when the situation needed something else. The employee leaves the documentation behind and takes with them the judgement that made sense of it.

That is the debt coming due.

AI does give time back. The question is what we do with it. Spend all of it on more output and the debt grows. Spend some of it letting people learn from customers, from each other and from the colleague who disagrees, and the time saved becomes something the organisation can keep.

The post The abstraction debt: what happens to the time AI gives back? appeared first on Alessandro Zulberti.

Accessibility: The shape of Access

Alessandro Zulberti — Tue, 07 Jul 2026 12:52:04 +0000

Equitable Use

A father & daughter · Place of Reflection

Arrival

They arrived just after noon. A father and daughter. She pushed the wheelchair with easy rhythm, used to the incline of pavements, the friction of gravel. The site was marked on the map with a small star: Place of Reflection. They had driven two hours to see it. At the front: a wide, angular staircase. Framed in shadow. Designed, clearly, to be noticed.

The Long Way Round

She paused at the base of the stairs and looked around. No signs. No alternate path in view. They walked left, tracing the edge of the structure. Then right. The gravel changed to patchy grass. A narrow strip behind a low hedge opened up and there, hidden near a service corridor, was a metal gate. Slightly ajar.

Not Quite In

Inside, the space opened beautifully. Water. Silence. A rhythm to the stone. But the path they found themselves on did not align with the others. There were no cues, no signage. Visitors emerging from the main entrance looked at them with mild curiosity, as if they had come from the wrong direction.

A Question Left Behind

They left through the same side gate. That evening, she wrote an email. Not a complaint. Not a request. Just a question:

Have you ever tried entering your building in a wheelchair?

Design that is useful and marketable to people with diverse abilities. The same means of use for all users: identical whenever possible; equivalent when not.

The entrance was architecturally celebrated, the alternative hidden and unmarked. Beauty was designed for those who could climb. Access was an afterthought.

What does a space say about who it imagined would enter before a single person arrives?

Flexibility in Use

Mina · grant application · 10:47pm

Deadline

When Mina first opened the form, she was already behind schedule. The grant application was due by midnight. She had the documents ready: CV, portfolio, proposal. The site was minimalist. Clean lines. A single progress bar at the top. She took a deep breath and began.

No Option Given

The second question asked her to drag and drop documents into a blank square. She hesitated. Drag and drop had always been awkward with her voice software. She tried to move the file by voice. Nothing happened. She looked for a Browse button. There was none.

Workaround

Mina checked the time: 10:47pm. She knocked on the wall. Her sister, next door, opened the door. Mina asked for help dragging three files into a box. Her sister smiled, opened Mina’s laptop, and followed her voice step by step.

Forward, Together

When they reached the final page, a bright green banner appeared: Thank you. Your application has been submitted. No one would ever know how the submission was completed, or that it took two people to do what the system assumed one person could.

A good design meets you where you are. A better one does not assume you are alone.

Design accommodates a wide range of individual preferences and abilities. It provides choice in methods of use and adapts to the user’s pace.

A single interaction method blocked an entire workflow for a user with voice software. No fallback. No Browse button. No flexibility.

When we test our interfaces, whose hands are on the keyboard?

Simple and Intuitive Use

Marcel · screen reader user · appointment portal

Clean Design

Marcel liked doing things himself. He had never needed much help online, until the new appointment portal launched. He needed to book his booster shot. The link opened a clean, modern page. Select a time and confirm. That is what it said.

What Is Missing

He chose a time. Then nothing. No Next button. No confirmation. He tabbed forward. Group. Button. Clickable. No label. He clicked. Nothing happened. He tried again. Same thing.

Call for Help

A support worker told him there was a little checkmark in the bottom corner, a floating icon. Marcel asked what it was labelled as. It was not labelled.

Not Forgotten

A friend booked the appointment for him. Not because he could not, but because the system had made him feel like he had missed something obvious. But he had not. The button simply had not introduced itself.

Simplicity is not what we leave out. It is what remains clear when nothing is explained.

Use of the design is easy to understand, regardless of the user’s experience, knowledge, language skills, or current concentration level.

A visually elegant floating icon was invisible to a screen reader. The interface looked simple, but simplicity without accessibility is exclusion with better typography.

Is the interface simple for you, or simple for everyone?

Perceptible Information

Mira · Glasgow train · Platform 3

Quiet Interface

The station had been renovated last spring. Concrete, quiet signage, hanging screens. Mira liked the stillness. Until she missed her train. She had checked the board: 16:48 to Glasgow, Platform 3. She returned seven minutes early. The train was gone.

A Missing Signal

The display still said On Time. Inside, behind the help desk, a smaller screen showed that the train was now departing from Platform 5. There had been no announcement. No flashing notice. No push notification. Just silence.

The Unspoken

A staff member said that most passengers check their apps now. Mira nodded. She did not feel upset. Just uninvited.

Lines That Do Not Speak

That evening she wrote that good design speaks in more than one voice. It tells you again, in another way, when the first time did not reach you.

I can read. I can hear. But I cannot be everywhere at once.

The design communicates necessary information effectively to the user, regardless of ambient conditions or the user’s sensory abilities. Multiple modes matter.

Critical information existed, but it was not broadcast in a way that reached the user when it mattered.

When information changes, how many channels carry that change, and who falls through the gaps?

Tolerance for Error

Jonah · banking app · two reversed digits

The Click

The invoice had been paid. Jonah opened his banking app to reimburse Lila: £42.50 for the shared Zoom licence. He typed in her account number and clicked Confirm. A second later, he noticed two digits reversed.

The Wall

He looked for a cancel button. There was none. He searched for help and found a message saying mistaken payments are the responsibility of the sender. The line was clean. Absolute. No space for regret.

The Reflection

Walking home, he passed a construction site. Red tape. Yellow markers. Warnings everywhere. The structure did not assume perfection. It accounted for error.

A Line Too Straight

At his desk, he wrote that a mistake should slow you down, not lock you out.

A good system lets you turn around. A better one helps you before you realise you are lost.

The design minimises hazards and the adverse consequences of accidental or unintended actions. Warnings, fail-safes and recovery paths matter.

The system confirmed without review, executed without pause and provided no undo. The moment of error became the last moment of agency.

Does your confirmation step slow the user down, or does it only add another click?

Low Physical Effort

Callum · clinic intake form · tightening wrist

Settling In

Callum sat at the intake desk. The adviser handed him a tablet and said the form was all digital now. He nodded and began.

Every Tap Measured

Each screen required typing. Address. Medications. Emergency contacts. His wrist began to tighten. He tapped slower. Switched hands. There was no autofill, no save button, no progress indicator. Just field after field.

The Push

He asked whether there was a way to pause and return. The answer was that he could start over if it timed out.

Slowing the Loop

He asked for a paper version. The adviser hesitated, then printed it. Callum took it home, filled it out in the quiet of his kitchen, paused when his hand ached, and continued the next day.

Sometimes I just need less friction. Not help. Not adjustment. Just a system that does not assume I can go on forever.

The design can be used efficiently and comfortably and with a minimum of fatigue.

The form was technically accessible but continuous, unbreakable and timed. It assumed infinite capacity.

Whose fatigue did you account for when you designed the form’s length?

Size and Space for Approach and Use

Elena · wheelchair user · morning gallery visit

First Light

The gallery had just opened. Elena preferred mornings. She entered easily, rolled through the first room, paused by a series of photographs, then turned towards the corridor.

The Angle

It curved sharply. She entered slowly and pivoted. The arc was too tight. Her wheels caught the wall. She reversed and tried again. It was not impossible. But it was not measured for her.

Still and Small

A staff member said that room was added later and that they knew it was not ideal. Elena smiled and said she had not expected choreography.

What Does Not Move

She later said it was not really about the corner. It was about how the space never imagined she would be in it.

Design for pause. For turning around. For not hurrying.

Appropriate size and space is provided for approach, reach, manipulation and use regardless of body size, posture or mobility.

The room was added later, and later is often when access gets forgotten.

When was the last time you moved through your design in a body other than your own?

Alessandro Zulberti is a UX researcher and accessibility lead. More about my work.

The post Accessibility: The shape of Access appeared first on Alessandro Zulberti.

Blueprint Grammar

Alessandro Zulberti — Sat, 04 Jul 2026 12:57:46 +0000

Working Framework

What it is

A diagnostic language for naming service conditions precisely — reading what kind of problem a service has, rather than calling it “confusing,” “fragmented,” or “broken.”

The problem it addresses

Most service diagnosis collapses into loose vocabulary. A journey is “disjointed,” a flow “needs simplifying,” a touchpoint is “a pain point.” These words feel like analysis but carry almost no diagnostic weight — they describe a feeling of wrongness without naming its kind, and two very different failures end up with the same label. When the diagnosis is vague, the response is vague: teams redesign the whole journey in broad terms instead of fixing the specific condition that’s actually failing.

Blueprint Grammar exists to make the naming precise enough to act on. It gives a bounded set of conditions — singles and pairs — so that “the repair journey is confusing” becomes “a transfer failure between triage and the contractor, with repeated effort on the tenant’s side.” The second reading tells you where to look and what to fix. The first doesn’t.

When to use it

Use it when you already have something to read and the remaining problem is interpretation — you can see something is wrong but can’t yet say what kind of condition it is.

Service journeys with repeated hand-offs, where the person keeps carrying continuity themselves.
Flows where prerequisites stay hidden until too late — eligibility, documents, approval, or another actor required all along.
Support-heavy experiences, where staff repeatedly step in to recover, explain, or manually carry people through.
Cross-touchpoint situations, where effort reappears as people move between channels and rebuild progress.
Workshops where friction is visible but the conversation collapses into “pain point” or “confusion.”

If the main gap is evidence, the next step is research, not the grammar. If the main gap is naming what the evidence already shows, the grammar becomes useful.

How it works: the grammar

The grammar has two layers. Singles name one condition when it explains most of what’s going wrong. Pairs name two conditions working together when a single term would be too blunt. A reading uses at most three conditions — the discipline is to resist naming everything.

Each condition below carries a usage rule (“use this when…”) and the mistake it’s most often confused with. The confusion note is the evidentiary gate: it tells you what the condition is not, so the name isn’t applied loosely.

Singles

Indirect access — a service says access is available, but the person still needs another person, permission, or a hidden step to get through. Use when entry depends on help, approval, or a condition the service doesn’t show up front. Often mistaken for poor wording — but the issue is hidden mediation, not explanation.

Threshold — the hard part is getting over the line into the next step. Use when the key question is entry: what must happen before a person can move forward. Often mistaken for general onboarding trouble — but the pressure sits at the crossing itself.

Route — the service only works if the person can keep track of the sequence. Use when the problem lives in the path between steps, not one screen or form. Often mistaken for one broken touchpoint — but the issue is the sequence as a whole.

Dependency — the visible service depends on hidden work elsewhere. Use when the person-facing experience relies on another team, queue, or system they can’t see. Often mistaken for delay or staff error — but the real issue is the hidden support work the service depends on.

Exchange — the service depends on something important being handed over well. Use when information, trust, responsibility, or case state has to pass between people or teams. Often mistaken for bad content — but the failure is in the handover.

Interruption — the process breaks and the service doesn’t help the person recover. Use when a pause or break leaves people unsure how to restart. Often mistaken for a one-off disruption — but the issue is weak recovery.

Repeated effort — the same small piece of work keeps coming back. Use when re-entry, restating, or chasing becomes part of the service burden. Often mistaken for a minor nuisance — but the repetition has become structural.

Return — coming back is part of how the service really works. Use when retrying or looping back is normal rather than exceptional. Often mistaken for failure to get it right first time — but the service actually runs in cycles.

Three further singles are provisional — published but still under review:

Directed effort (provisional) — progress is possible only if someone pushes far harder than the task should require. Under review to confirm it’s a distinct condition rather than a consequence of another failure.

Ambiguity (provisional) — a person can continue but still can’t tell what the situation means. Under review to keep it from becoming a loose container for every unclear moment.

Shelter (provisional) — the service needs to give pause or reassurance before movement can restart. Under review to clarify when shelter is primary rather than better read through a pair.

Pairs

Indirect access + Threshold — access looks open, but the real gate is hidden (permission, proof, or reassurance surfacing only at the crossing).

Route + Interruption — the path exists, but breaks in it are hard to recover from.

Dependency + Exchange — the experience depends on hidden coordination and a handover that isn’t holding. Both are needed: the hidden dependency and the failed transfer.

Two pairs are provisional: Shelter + Return (safe pause and re-entry together, after a setback) and Route + Shelter (a path that only works if it contains places to pause and regroup).

A worked reading

Situation. A resident — John — finds a sticker on his recycling bin telling him it won’t be collected. He follows the online replacement process: registers an account, verifies his email, expects to pay, and is surprised to find replacements are free. He then receives a confirmation email from a no-reply address that tells him, in the language of compliance, what won’t happen if he fails to leave the old bin out correctly. A crew placed the sticker; a separate process makes John re-request what the crew already identified; a crew is then sent again to deliver the replacement.

Usual reading. The sticker is talked-down-to in tone, the email is unfriendly, the process is laborious. Fix the copy and simplify the form.

Grammar reading. The clearest reading is Dependency + Exchange. The resident-facing process only exists because two functions that already share the case — the collection crew who identified the broken bin, and the council system that holds John’s account and address — were never connected. The crew know the bin is broken; the service makes John re-enter that knowledge from scratch. Repeated effort runs throughout: John supplies information the institution already holds. Route matters too — the case passes crew → sticker → resident → online form → crew again, and no single actor carries continuity. John carries it himself.

What the grammar clarifies. It separates a tone problem from a structural one. The unfriendly email isn’t a copywriting failure — it’s a symptom of a workflow in which the resident is the connective tissue between disconnected functions. Naming the condition as Dependency + Exchange moves the diagnosis from “rewrite the sticker” to “why is John in this loop at all?” The repeated-effort reading shows the labour isn’t incidental friction; it’s built into a process that never used what the council already knew.

Why it matters. The precise reading changes the next move entirely. A tone reading produces a kinder sticker. The Dependency + Exchange reading asks whether the crew who place the sticker could carry a replacement and swap it on the spot — dissolving the resident-facing process rather than improving it. One is a better solution; the other questions why the solution takes this form. The grammar is what makes the second question sayable.

What remains uncertain. The material is one resident’s account, not the service’s operating data. It doesn’t show whether this path is typical or an edge case; whether the crew-to-swap model is blocked by cost, legacy systems, or organisational silo rather than oversight; or whether the disconnect sits in one hand-off or across the whole waste service. The reading is a bounded interpretation of one public post — a strong hypothesis about organisational fragmentation, not proof of it.

What it doesn’t do

It’s not a replacement for research. It works once there’s something to read; it doesn’t substitute for gathering evidence.
It’s not a journey-map format. It’s a diagnostic language, not a way to document every service.
It’s not a workshop gimmick. It sharpens interpretation; it doesn’t relabel every sticky note.
It’s not an answer machine. It narrows readings; it doesn’t remove the need for evidence, reasoning, and editorial restraint.
It’s not for problems working as designed against the user. Deliberate cancellation friction, dark patterns, and manufactured obstacles are not service conditions to diagnose — they are governance and ethics problems. Reading intentional adversarial design as “Threshold” or “Repeated effort” sanitises a business decision as a design defect. When a service is failing the user on purpose, the grammar’s job is to hand the problem off, not absorb it.

Alessandro Zulberti is a UX researcher and accessibility lead. More about my work.

The post Blueprint Grammar appeared first on Alessandro Zulberti.

Dropped Ideas: Working Frameworks

Alessandro Zulberti — Sat, 04 Jul 2026 12:29:40 +0000

I built five working frameworks, then removed them. This is the record of why.

The idea was reasonable. I had a set of half-formed instincts about research practice, and I thought that naming them — turning each into a small three-move framework — would sharpen them into something teachable and distinct. Working with an LLM made the building fast. Too fast: it let me generate the appearance of insight quicker than I could notice its absence. A three-move framework with a principle under each move reads as thinking. The act of naming something confers a sense of having understood it. And a model will produce as much of that as you ask for, fluently, without ever telling you that the thing you’ve named was never unclear in the first place.

So I applied the test I apply to anyone else’s work: what, specifically, is this — and where is the evidence it’s mine? Five of the frameworks failed it. Not because the ideas were wrong, but because they were already common practice wearing a new name, or my own framing added nothing the concept didn’t already carry. Keeping them would have weakened the frameworks that are mine, by association: a reader who spots that one is repackaged standard practice starts doubting the rest.

Below, each dropped framework as I built it — its three moves, stated as the assumption they encoded — and the specific reason it didn’t survive.