In this article

• The decision: when a scan flags a pile of documents, sort them by what each is for before repairing anything — most shouldn’t stay documents at all.
• The method: route each document to where its job belongs — a web page, a form, an inline answer, a repaired PDF, or the bin.
• Who does what: the researcher runs the triage; content, engineering, design, and compliance own the work it routes to them.
• The rule: nothing is deleted until its content is confirmed to exist elsewhere.

A way of thinking, not a fixed recipe. Ownership, your CMS, and your team’s capacity all bend the routing — for example, a third-party manual you can’t edit doesn’t route to “rebuild as a page.” Treat the sheet as a model to modify, and adjust it to your environment as you go.

The decision this article is about: when an accessibility scan lights up a pile of PDFs, the first move is not to repair the files. It is to sort them by what each document is for, and send each type where it belongs. Some get rebuilt as web pages. Some get deleted. Only a minority actually get repaired as documents. Deciding which is which — before anyone touches a file — is the researcher’s job, and it sets where every other team spends its effort.

The situation

A mature website, especially one selling many vendors’ products, collects documents over years: care instructions, assembly guides, FAQ sheets, returns forms, terms, conformity declarations, reports. Each was added for a good reason. Most were made in Word or a design tool, saved as PDF, and linked from a page. Nobody owns the pile.

Then a scanner is run against the site, and the pile turns red — no tags, no titles, no language set, missing alt text, no reading order. Several teams are now involved whether they planned to be or not. Content owns most of the documents. Engineering owns the site they sit on. Design owns whatever replaces them. Compliance owns the risk the scan just surfaced. And someone has to decide what actually happens — that someone is the researcher, and what they decide first matters more than how fast anyone fixes anything.

The trap

The reflex is to treat the scan report as a task list: the files are broken, so repair them one by one in the order listed. This feels like progress. It’s the wrong first move.

The scanner is a thermometer. It tells you there’s a fever, not what the illness is, and certainly not the cure. Treating the report as a to-do list assumes every flagged document should stay a document and become an accessible one. For most of the pile that’s false — and acting on it spends the most effort on the files that deserve it least.

A second wrong assumption hides underneath: that length should decide a document’s fate — short ones become pages, long ones get a fancier viewer. Length is easy to read off a file list, which is why it tempts. It’s also the wrong key. A fifty-page report read once, top to bottom, is a different object from a two-page sheet someone checks with one question in mind. Length doesn’t tell them apart. Function does.

For a junior researcher, the lesson worth keeping: a scan tells you what failed, not what to do about it. The judgement lives in the gap between those two.

Sort by function, then route

Replace “how do I fix this file?” with “what is this document for, and where does that job belong?” Sort the pile by function rather than file type or page count, and the right destination for each group becomes close to obvious. Six functions cover most piles:

• Tells someone how to use, clean, assemble, or maintain a product → a structured web page, with a print version generated from it. People search for this and read it one task at a time, often on a phone. It needs to reflow, be findable, and be translatable. A page does all three; a download does none.
• Answers a question the site already asks → published inline, on the page where the question appears. The document is an answer pretending to be a file.
• Collects structured input (a form, a checklist) → a web form that produces a printable summary. The interaction is the point.
• States fixed, dated, citable terms (legal, regulatory, governance) → stays a PDF, repaired in place. Here the document is the right object: signed, dated, formally referenced. Converting it loses the fixity that gives it authority.
• Read linearly for an overall impression (a report) → stays a tagged PDF, with a presentation layer over it only if wanted. Length is real, but the duty sits on an accessible version, not a decorative viewer.
• Markets, with content that already lives elsewhere → removed, once you’ve confirmed the substance is genuinely on a page.

Read that against the red report and watch it shrink. The legal and regulatory documents get repaired in place, cheaply, because they were authored as text and tag well. Another share gets deleted, not repaired, because the content already exists on a page. The genuine conversion work — the part that costs real effort — turns out to be a minority of the pile, not the majority the scanner implied.

That is the orchestration move: the researcher isn’t fixing documents, but deciding which function each serves and routing it to the team that owns the destination. The decision is upstream of the repair, and it’s what stops four teams spending a quarter on the wrong work.

Who does what

• Researcher — runs the triage: sorts by function, sets each destination, sets the order of work, and owns the parity check before anything is deleted. Does almost none of the hands-on work; the contribution is the routing.
• Content — rewrites instructional and FAQ documents as pages, confirms each page carries everything the old document did, and flags the marketing duplicates that can go.
• Engineering — builds the page structures, forms, and print generation; repairs the PDFs that stay; removes deleted files and their links cleanly.
• Design — handles structure and reading order of new pages and forms, so they’re accessible by construction, not by later repair.
• Compliance / legal — confirms which documents are genuinely fixed-and-citable, and signs off the parity checks on anything retired, since retiring a document is a risk decision as much as a content one.

One thing this division makes visible: clearing the pile is not the cure. The files failed because the way they were authored never treated structure as content — headings styled to look like headings instead of marked as headings, meaning in images that was never written down, reading order left to chance. Fix everything and change nothing about authoring, and next year’s scan turns red again. The work that means you don’t repeat this is getting content, design, and engineering to treat structure as content from the start.

The rule that prevents the expensive failure

One failure mode hides inside the work that looks most like progress. When instructional content moves from a document to a web page, the rewrite is an act of judgement — and judgement drops things. A safety warning, a caveat about one model, a note that mattered to a small group: exactly the details a confident rewrite leaves behind, because they look marginal until the person they protect is the one reading the page.

So the page looks modern, passes the scanner, and is quietly less complete and less safe than the document it replaced. The score went up while the information available to a user went down — the worst outcome in the exercise, because every surface signal says it went well.

The rule is one sentence: nothing is removed until its content is confirmed to exist elsewhere. The old document retires on the day someone confirms, line by line, that the new page carries everything it did — not the day the page launches.

For a stakeholder, that’s the question to ask in every status meeting: has parity been confirmed, or just assumed?

The instrument

This article comes with a document triage sheet — a spreadsheet that takes a scan export and walks the team through the sort: function, destination, owning team, order of work, and a parity-check column that must be ticked before a deletion row can close. Headers are written for the whole team, so a content owner or developer can work in it directly.

Download Excel Template

The post When an accessibility scan flags your documents, don’t fix them first appeared first on Alessandro Zulberti.

In this article

• The decision: deliver the audit as a workbook the team works in, not a PDF they read once — the format determines whether the findings ever get fixed.
• The method: five sheets that separate what changes (findings, progress) from what doesn’t (evidence, scope), with progress computed, never typed.
• Who does what: the auditor builds and owns the structure; developers, content, design, and stakeholders each work a defined part of it.
• The rule: progress is derived by formula from the status field, so the workbook can’t lie about how far along it is.

A starting point, not a fixed system. If your team works in Jira, Azure DevOps, or Asana, treat the register as the audit and planning layer and export findings into your tracker — keep the systemic layer and dashboard here. Adapt the sheet to your environment; that adaptation is part of the work.

The decision this article is about: an accessibility audit’s value is decided by its format before anyone reads a word of it. A PDF report is read once, summarised in a slide, and then ages while the product keeps changing. A workbook designed as the working surface of the remediation stays current, because the team fixes, verifies, and closes findings inside it. Choosing the workbook over the report is the call that determines whether the audit changes anything.

The situation

A WCAG 2.2 AA audit of a reasonably large site produces hundreds of findings across many pages and several teams. The findings have to be understood, assigned, fixed, retested, and closed — over weeks or months, by developers, content owners, and designers who were not in the room when the audit was run.

That is the real job, and it starts the moment the audit ends. So the question that should govern the deliverable is not “does this present the findings clearly?” It is “can the team work in this — assign, fix, verify, close — without the auditor in the room?” A sixty-page PDF fails that test on contact. A developer cannot filter it, a stakeholder cannot see progress in it, and nobody can record that a finding has been fixed and retested.

The trap

The reflex is to make the audit thorough and readable — and to optimise it for the moment of delivery. That produces three formatting habits that all read well and all fail the team afterwards.

Grouping findings by WCAG success criterion reads well to auditors and to nobody else: a developer doesn’t fix “1.1.1”, they fix a component on a page. Writing findings as prose paragraphs makes them impossible to filter, count, or assign. Expressing severity as adjectives — “significant”, “moderate” — makes them impossible to sort. Each habit serves the handover and works against every day after it.

The lesson worth keeping: a deliverable that is finished when it’s handed over is a deliverable nobody can work in. The audit is the cheap part. The format has to carry the months that follow.

The method: five sheets

A workbook of this kind settles into five sheets. The point is the partition — each sheet answers a different question, changes on a different rhythm, and is read by a different person.

• Findings register — the layer where work happens. One row per issue, never per criterion: where it occurs, what fails, which criterion, severity on a defined scale, the user impact in plain behavioural terms, and a status. Everything must be filterable. The discipline is granularity — “alt text inadequate across product imagery” is a category pretending to be a row. Ten thousand images with one shared failure become a single systemic finding pointing at the cause, plus a small sample that proves the pattern.
• Evidence — screenshots by finding ID, the assistive technology used, reproduction steps. Separated from the register because it’s written once and read rarely — but when it’s read, it’s read under challenge (“is this really a failure?”), so it has to settle the argument on its own.
• Systemic layer — the recurring causes behind clusters of findings, and the rule that prevents each from regenerating. This is what separates an audit of symptoms from an audit of causes: individual findings close one by one, but a systemic failure closes only when its source is fixed.
• Progress — counts and proportions derived entirely by formula from the register’s status field. The moment progress is typed rather than computed, the workbook holds two versions of the truth and the optimistic one wins. This is the sheet stakeholders open; it must never be hand-editable.
• Scope and method — what was tested, with what, on which dates, against which target, and what was excluded. This sheet exists for the reader two years away — possibly a lawyer, possibly you.

Who does what

• Auditor / researcher — builds the workbook, writes the findings at the right granularity, defines the severity scale and the status vocabulary, and owns the structure. The contribution isn’t finding problems; it’s making the remediation legible and trackable for everyone else.
• Developers — work in the findings register: pick up issues by component and page, fix them, move each to “fixed”, and link the change. They never edit the progress sheet — it follows their status changes automatically.
• Content — owns findings on copy, alt text intent, link text, and reading order in content, working the same register rows.
• Design — owns findings on contrast, focus order, target size, and anything that has to be corrected at the component level so it doesn’t recur per instance — i.e. the systemic-layer fixes, not just the instances.
• Stakeholder / programme owner — reads the progress sheet, and asks the one question the status vocabulary exists to answer (below). Doesn’t work in the register; relies on it being honest.

The division only holds if the status field is honest, which is the next point.

The rule that keeps the workbook honest

The single highest-leverage decision is the status field, and it’s a precision problem, not a project-management one. “Done” is fatal, because it flattens at least three different conditions: a fix has been made, a fix has been verified by retest, and a finding has been consciously accepted as a known limitation. The status vocabulary needs a distinct value for each — because the gap between “fixed” and “verified” is exactly where accessibility programmes quietly fail. Changes ship, nobody retests with the assistive technology that surfaced the issue, and the register fills with closures the next audit reopens.

Because progress is computed from this field, the vocabulary is also what stops the workbook lying. If “fixed” and “verified” are the same value, the progress sheet will always look better than the product is.

For a stakeholder, that’s the question to ask in every status meeting: how many findings are verified, not just fixed?

The instrument

This article comes with the audit workbook itself — the five sheets pre-built, with the status vocabulary defined, the progress sheet wired to the register by formula, and the severity scale set. Drop in findings and it tracks itself. Sheet and column headers are written for the whole team, so a developer or content owner can work in it without a walkthrough.

Download Excel Template

The post Deliver your accessibility audit as a working spreadsheet, not a report appeared first on Alessandro Zulberti.

In this article

• The decision: audit product names as part of the interface, not as copy — the usual failure is structural, not a vocabulary problem.
• The method: score names on consistency criteria (attribute order, label matching, descriptor presence), not just clarity and tone, so the real fault becomes visible.
• Who does what: research owns the naming structure; category owners own what the structure prioritises; content, PIM, and engineering apply it.
• The rule: when the same attribute is labelled differently across products, users miss it entirely — as if it weren’t there.

A model to adapt, not a fixed rule. The criteria, weights, and naming template here are a starting point. Different categories weight them differently, and your portfolio will need its own structure — deciding how it bends to your catalogue is part of the work.

The decision this article is about: in ecommerce, a product name isn’t copy — it’s part of the interface. So a naming audit shouldn’t be run like a copy review, asking whether each name is clear and on-brand. It should be run like an interface audit, asking whether names are structurally consistent across the listing, so users can scan and compare without opening anything. Almost always, the problem you find isn’t the words. It’s the structure.

The situation

A listing page works when users can compare and shortlist without ever opening a product page. They scan down the column, recognise the attribute that matters — size, type, finish, quantity — and eliminate options. That only happens if the same attribute appears in the same place, with the same label, on every name.

When naming is inconsistent, that breaks. The user opens one product page, then another, goes back, forward again — doing the work the listing page should have done. The product page becomes the workaround for a broken listing page. Baymard Institute’s research on product lists points the same way: hard-to-scan product information slows users almost as much as having no information at all, and titles in list views have to support comparison at a glance.

Several teams already shape these names, usually without coordinating. Category and product managers nominate what goes in a name. The content team owns wording and naming conventions. The product-data (PIM) team owns which attributes exist and how they’re stored. Engineering renders the name in the listing. Each optimises its own field, and the structural consistency — the thing the user actually needs — is owned by no one.

The trap

The reflex is to audit names the way you’d review copy: is each name clear, is it on-brand, does it read well? Score names this way and most of them pass. They are clear. They are on-brand. The audit comes back mostly green, and the scanning problem is still there — because clarity was never the failure.

The failure is structural, and it’s invisible at the level of a single name. Attribute order varies between collections. Size labels don’t match — “12-piece” in one place, “set of 12” in another, “large” in a third. A descriptor is explicit in one name and implied or missing in the next. None of it looks wrong when you read one product. All of it becomes visible when you step back and read the column.

For a junior researcher, this is the lesson worth keeping: when names don’t scan, audit the structure across products, not the words within one. The fault lives in the relationships between names, not inside any single name.

The method: score structure, not just words

The fix is to audit names against criteria that separate structural quality from linguistic quality, and to weight the structural ones properly. A workable criteria set:

• Clarity of meaning — does the name communicate what the product is? (Linguistic. Usually already fine.)
• Alignment with user language — does it match how users describe the thing? (Linguistic. Usually already fine.)
• Structural consistency — does this name follow the same attribute order and labelling as its neighbours? (Structural. This is where the failures hide.)
• Distinctiveness — can a user tell this product from the one next to it on text alone? (Structural in effect — identical names create a comparison dead end.)
• Scalability — will the structure still hold when the range grows?

Score a portfolio this way and a pattern emerges that a copy review would never surface: names lose almost no points on the linguistic criteria and most of their points on the structural ones. That gap is the finding. It says, in numbers, that the problem the team keeps trying to fix with better wording is actually a problem of inconsistent structure — and no amount of rewording will fix it.

The structural diagnosis also produces a concrete target: a naming template the whole portfolio can follow. Something like collection + function + material + quantity + size, applied in a predictable order. The exact slots are yours to define; the point is that there is an order, and every name obeys it.

Who does what

The naming structure is a shared object that no single team currently owns, which is exactly why it drifts. The audit’s job is to assign that ownership.

• Researcher — owns the naming structure: runs the audit, defines the criteria, sets the template (attribute order and labelling rules), and identifies where scanning breaks. Owns the system, not the individual names.
• Category / product owners — own what the structure prioritises. A name’s job differs by category: some categories need the name to fully describe the object, others need it to anchor a collection identity with specs handled elsewhere. Category owners set that weighting within the shared structure — the one place category-specific judgement belongs.
• Content — applies the template to wording, owns the naming conventions, and removes duplication so each attribute has one canonical form.
• PIM / product data — confirms the attributes the template needs actually exist and are stored consistently, so the structure can be populated rather than improvised.
• Engineering — renders names in the listing so the structure survives into the interface the user actually sees.

This is the orchestration point: the structure is one decision, owned by research; the weighting of what matters within it is a category decision. Separating those two — a shared system, with category-specific priorities inside it — is what stops five teams each optimising a different answer. Baymard’s research supports exactly this shape: consistency and predictable attribute order, with category-appropriate density, rather than one rule applied flatly everywhere.

The rule that prevents the expensive failure

The failure that costs the most is also the quietest, because it doesn’t look like a failure at all. When the same attribute is labelled differently across products — “12-piece” here, “set of 12” there — users don’t see two versions of the same thing. They miss the attribute entirely, as if it weren’t there. The information is present, technically, and functionally absent.

So the rule is one sentence: an attribute the user can’t find by scanning is an attribute that isn’t there. Consistency isn’t tidiness — it’s the difference between information that exists in the database and information that exists for the user. A name that’s clear in isolation but inconsistent with its neighbours has failed at the one job a listing-page name has.

For a stakeholder, that’s the question to ask of any naming review: did we check whether the same attribute is labelled the same way everywhere — or only whether each name reads well on its own?

The instrument

This article comes with a naming consistency scorecard — a spreadsheet that scores a set of product names against the structural and linguistic criteria separately, weights them, and shows the gap between the two. It surfaces the structural failures a copy review hides, with category-specific weighting built in so different parts of a portfolio can prioritise differently within one shared structure. Drop in your names and it shows you where scanning breaks.

Download Excel Template

The post Audit your product names for structure, not words appeared first on Alessandro Zulberti.

A case study on expanding research from isolated insight into a strategic function that supports prioritisation, direction, and business decisions. Focus: Research, Strategy

The post Scaling Research for Strategic Decisions appeared first on Alessandro Zulberti.

I ask the model to synthesise across all three.

It does. Fluently. Coherently. With the kind of quiet confidence that makes you want to believe it.

Then I ask it to challenge its own conclusions. To find what the data forbids, not just what it supports.

It does that too. Fluently. Coherently. With the kind of quiet confidence that makes you want to believe it.

The problem is not that the second response is wrong. The problem is that I have no way of knowing whether it is right — unless I already know the answer. And if I already know the answer, I did not need the tool.

The distinction that matters

Synthesis asks: what does the evidence support?

Falsification asks: what would the evidence rule out?

These are not the same operation. In research practice, in strategic decision-making, in risk assessment, the difference between them is the difference between a map and a terrain. Synthesis builds the map. Falsification walks the terrain and notices where the map is wrong.

Large language models are extraordinarily capable at synthesis. They can hold multiple sources in tension, identify convergent threads, surface patterns that would take a researcher hours to assemble manually. Used well, that capability is genuine — it saves time, extends reach, surfaces things you would have missed.

But falsification requires something synthesis does not. It requires doubt that arrives from outside the frame. It requires a question the model cannot generate from its own outputs, because generating it would mean reaching beyond the statistical distribution of language it has been trained on — toward the thing that does not fit, the participant whose account does not cohere, the metric that pulls in the opposite direction from everything else.

When I ask the model to challenge its own synthesis, it produces challenge. But the challenge arrives in the same register as the synthesis. Same fluency. Same coherence. Same confidence. It is wearing the shape of resistance without the substance of it.

I started calling this performed rigour. The form of stress-testing, without the function.

The chameleon problem

I spent several months trying to engineer my way out of this. If the model defaults to coherence, I thought, prompt it toward incoherence. Ask it to argue the opposite case. Ask it to play devil’s advocate. Ask it to find the three things most likely to be wrong.

Some of this is useful. Devil’s advocate prompting produces responses I would not have reached alone. Asking for alternatives — framed as competing hypotheses rather than elaborations — pushes the model somewhere more generative than consensus.

But none of it solves the underlying problem. Each time I ask the model to resist its own conclusions, it produces resistance in the same medium as the conclusions. The critique is fluent and well-structured. It sounds like challenge. It has the grammar of intellectual opposition.

A chameleon changes colour to match its environment. Ask it to stop, and it changes to a colour that looks like stopping.

This is not a failure of the model. It is the model working exactly as designed. Coherence is not a bug. But coherence at the point where you need incoherence — where you need the thing that does not fit to refuse to fit — is a structural problem, not a prompting problem.

What Euler understood

In 1736, Leonhard Euler was presented with a puzzle from the city of Königsberg. The city was built across a river, with seven bridges connecting its parts. The question: was it possible to walk across all seven bridges exactly once, returning to the starting point?

People had tried. No one could do it. But no one could prove it was impossible — until Euler recognised that the question itself was wrong.

The impossibility was not navigational. It did not matter which bridge you started from, which route you took, how carefully you planned. The topology of the system — the number of bridges connecting to each landmass — made the complete traversal structurally impossible regardless of how you moved through it.

Euler’s insight was not a better route. It was a different question: not how do I cross all seven bridges but what kind of system makes that crossing possible at all.

The falsification problem has the same shape.

Writing a better prompt does not solve it. Rephrasing the challenge, adjusting the instruction, asking more precisely — these are navigational moves inside a system whose topology makes certain traversals impossible. The model will respond to each prompt from within its own frame. Ask it to critique that frame, and the critique arrives wearing the frame’s grammar.

You cannot walk out of Königsberg by choosing a different bridge.

What organisations are actually removing

This matters at the individual level — for every researcher who believes they have stress-tested a synthesis because the model produced something that looked like resistance. But it matters more at the organisational level, because the structural decision is being made there, and it is being made on the basis of an incomplete understanding of what AI can and cannot carry.

Organisations are cutting junior analyst and researcher roles. The reasoning is coherent on its surface: AI handles synthesis adequately, senior judgment remains at the top, the cost line comes down.

What this misses is what junior roles were actually doing.

It was not primarily output. A junior researcher reading raw interview transcripts is not performing a task that AI cannot perform. They are doing something more specific: they are building the capacity to carry doubt into a room before the synthesis begins. They have read the thing. They have noticed the participant whose account didn’t quite fit. They have felt the friction between what the data says and what the framing wants it to say.

That friction is not recorded anywhere. It does not appear in the synthesis document. It lives in the person who sat with the material — and it is the condition under which falsification becomes possible at all.

A Dominican philosopher I interviewed for the Disciplina project described the master/disciple relationship in terms drawn from Aquinas: understanding arrives not by instruction from above but by living contact. The hot stone does not make the cold stone warm by explaining heat. It makes it warm by proximity. The cold stone changes because it was in the room.

The junior researcher is the cold stone. Not because they are less expert — they become more expert precisely through this contact — but because they are the presence in the room that carries the heat of independent encounter with raw material. Remove them, and the senior researcher is left with AI synthesis on one side and their own prior frameworks on the other. The feedback loop that would have interrupted drift no longer arrives.

You have not reduced cost. You have removed the structural condition under which falsification was possible.

The frame defends itself

McLuhan argued that the content of a medium blinds us to the character of the medium itself. We attend to what is said and stop noticing how the saying shapes what can be said.

The extension I want to make is this: the frame does not merely obscure itself through carelessness. It defends itself. When you ask the medium to critique the medium, the critique arrives in the medium’s register. It performs transparency. It sounds like what stepping outside the frame would sound like, from inside the frame.

This is why the chameleon problem is not solvable by prompting alone. The better the model — the more capable, the more fluent, the more sophisticated its simulation of resistance — the harder it becomes to distinguish performed challenge from genuine challenge. The failure mode scales with capability.

For a practitioner who has carried independent doubt into the session — who has read the raw material, noticed the friction, built the uncertainty before the tool was opened — this is manageable. The independent doubt is the external ground. It is what allows you to evaluate whether the model’s resistance is real or performed.

For a practitioner who has not — or for an organisation that has removed the roles through which that independent doubt would have formed — the performance of rigour is indistinguishable from rigour itself.

That is the risk. Not that AI gets facts wrong. That it gets the synthesis right while making genuine challenge structurally impossible.

The honest position

I am still working on the falsification prompt.

I have a version that produces something closer to genuine resistance than the default. It involves framing the request not as critique of the synthesis but as a search for the participant or data point the synthesis would most need to be false — the specific, concrete case that would break the argument rather than qualify it. It involves doing this before the synthesis is complete, not after. It involves bringing my own independent reading into the prompt explicitly — naming what I noticed before I opened the tool — so the model has something to push against that did not come from the model.

This is not a solution. It is a partial mitigation that works when I have done the prior reading, and fails when I have not.

Euler’s actual contribution was not a better route across the bridges. It was a proof that the question of routes was the wrong question, and a new framework — graph theory — that made a different class of questions possible. The topology of the problem had to be understood before it could be worked around.

What the equivalent framework looks like for the falsification problem — what kind of human/AI relationship makes genuine challenge possible, and what structural conditions organisations need to preserve to make that relationship viable — is the question the field has not yet asked clearly enough.

I do not know the full answer. That is not a weakness in the argument. It is the most credible thing a researcher can say right now.

What I do know is that the answer is not a better prompt. The bridge you are trying to cross does not exist inside the medium. The topology has to change.

The post How Do You Ask a Chameleon to Stop Changing Colour appeared first on Alessandro Zulberti.

I teach UX research as a practical discipline, not as a list of methods. The work starts before the framework, with a person trying to understand a page, complete a task, compare options, trust a service, or decide whether to continue. Sometimes the problem is explained clearly; more often, the evidence arrives in fragments: a pause, a repeated question, a skipped section, a hesitation before clicking.

That is the material students need to learn from. My teaching focuses on the movement from messy evidence to responsible action, using a simple sequence: listen, frame, map, and test. It is the same movement I use in professional research across ecommerce journeys, service experiences, accessibility reviews, behavioural analytics, and product decision-making.

Listen

Students begin with raw participant evidence, not polished insights or final recommendations. They work with real comments, contradictions, and moments of uncertainty, learning to separate what the participant says from what the behaviour may reveal.

A comment about unclear costs may also be about trust. A positive reaction to a visual explanation may not be about the image itself, but about confidence. A complaint about too much content may signal that the page is asking the user to work too hard. This is where research begins: in attention before interpretation.

Frame

The next step is to turn evidence into a better question. Students move from quote to structure by translating observations into a problem, an objective, and a How Might We question. This prevents the common mistake of jumping directly from one user comment to one design fix.

A weak response is to say, “make this clearer.” A stronger response asks what the user needed at that moment, why the current experience failed to provide it, and what the team needs to learn before deciding on a solution. Research becomes direction when it starts with the right question, not the nearest fix.

Map

Students then place the evidence into a journey. They identify the moment, the content block, the user action, the emotion, and the opportunity, so the problem becomes concrete rather than abstract.

Most UX issues do not live inside one isolated component. A trust signal, delivery message, review count, image, form field, or content module can change meaning depending on where it appears in the journey. Mapping shows where confidence builds, where it breaks, and where the system creates unnecessary effort.

Test

The final step is to turn an insight into a testable hypothesis: if we change this part of the experience, then this metric may improve, because the research showed this behaviour or risk. This is where teaching becomes close to real product work.

Not every insight should become a recommendation. Some ideas need to be tested. Some need more evidence. Some should be deprioritised because they are interesting but not consequential enough to act on. In digital commerce and service design especially, a change can increase engagement while failing to improve the outcome that matters.

What students learn

The aim is not to teach students to make research look tidy. The aim is to teach them how to handle evidence without flattening it. They work with participant quotes, behavioural signals, journey maps, hypotheses, and prioritisation frameworks, while understanding that qualitative and quantitative evidence can support each other but can also disagree.

Good UX research requires judgement. Judgement means knowing when a quote is a symptom, when a metric is misleading, when a journey map reveals a structural issue, and when a design idea needs to become an experiment rather than a recommendation. That distinction does not come from method. It comes from practice.

Why this matters

In real projects, evidence is incomplete, stakeholders need decisions, teams want clarity, and metrics can point in one direction while interviews point in another. Accessibility issues may be invisible until someone tests the journey differently. A service can look simple on the surface while creating operational pressure behind it.

Students need to practise that complexity — not a cleaned-up version of it. They need to learn how to slow down, structure the material, and move forward without pretending the evidence is cleaner than it is. That means tolerating ambiguity long enough for the real problem to become visible, and being precise about what is known, what is inferred, and what still needs to be tested.

The post The Material of Teaching appeared first on Alessandro Zulberti.

This is why I think of UX research as a material practice — not only a process for collecting evidence, but a way of working with attention, language, structure, and judgement. The material of design is found in the small moments where a system meets real use: a hesitation before checkout, a skipped content block, a service step that feels disconnected, an accessibility barrier, a page that explains too much while clarifying too little.

These moments are not noise. They are where the work begins.

The fold

A fold appears when the designed flow and the user’s reality stop aligning. It may happen when someone pauses where the interface expects speed, ignores content the team considered important, or reaches a service step that sends them somewhere else to complete what should have been simple.

The fold is not always a bug. Sometimes it is a contradiction, a missing signal, or the moment where the user reveals what the organisation has stopped seeing. In research, I try not to resolve the fold too quickly. Naming it too early can reduce it; leaving it untouched can make it disappear. The work is to hold it long enough for its meaning to become useful.

Listening

Research is often described as asking questions, but much of the value comes from listening. Listening means noticing what people repeat, what they avoid, what they assume, and what they do when the interface stops supporting them.

This connects with photography as much as UX. In both practices, the first discipline is observation: learning to look before explaining, understanding that framing changes meaning, and noticing that what sits at the edge of the frame may matter as much as the subject. In UX research, the important evidence is not always in the answer. Sometimes it is in the pause before the answer.

Method

Methods are not neutral. An interview stretches meaning, a survey compresses it, analytics shows behaviour at scale, and a usability test reveals friction inside a task. An A/B test can show impact, but it does not always explain why that impact happened.

Each method gives something and removes something, which is why I rarely trust one signal alone. I look for the relationship between what users say, what they do, where they struggle, how often it happens, and what business or service consequence follows. Research becomes useful when it helps a team understand which problem matters, why it matters, and what should be tested or changed first.

Language

Research changes when it becomes language. A user may say, “I clicked here because it felt safer,” but in a report that can easily become “users want clearer navigation.” The summary may be true, but something has been lost: uncertainty, emotion, risk, instinct.

This matters because language assigns responsibility. “Users were confused” makes the problem sound as if it belongs to the user. “The interface did not provide enough reassurance at the decision point” makes the system visible. Good research writing should help teams act, but it should not erase the conditions that produced the evidence.

Service

Some of the most important UX problems are not interface problems. They are service problems, where the visible screen is only one part of a larger experience involving communication, operational process, timing, expectation, and trust.

A journey may look acceptable on one page but fail across the full experience. A customer may understand the next step and still feel uncertain because the system around that step is not aligned. The question is not only whether the user can complete the task, but what effort the system creates, where responsibility moves, what the user needs to trust, and what happens after the visible interface ends.

Accessibility

Accessibility sharpens this way of working because it makes hidden assumptions visible. It shows where design depends too much on vision, speed, precision, memory, confidence, or familiarity, and it reveals whether a system is genuinely structured or only visually arranged.

Accessibility is not a final check. It is a way of asking whether the experience can hold different bodies, contexts, technologies, and levels of certainty. When it is treated as part of design practice rather than a compliance layer, it improves the whole system — making content clearer, journeys more robust, decisions easier, and responsibility more explicit.

What remains

Most research fails before the report. Teams mistake visibility for understanding. Dashboards replace observation. Metrics become more important than the behaviour behind them. Workshops create alignment without changing the service, content, or process causing the problem.

I have seen teams optimise journeys users still do not trust. I have seen accessibility treated as compliance while people struggle to complete basic tasks. I have seen organisations celebrate engagement while increasing effort for the customer. The issue is rarely lack of data. The issue is that interpretation requires something data alone cannot supply: a willingness to sit with the problem long enough to understand what it is actually about.

Research becomes useful when teams connect evidence across the full experience — behaviour, language, accessibility, operational constraints, commercial pressure, and user intent. That work is slower than producing slides. It requires judgement, disagreement, and the willingness to face problems that sit beyond the interface itself. None of that is comfortable. It is, however, the part that changes anything.

The post The Material of Desgin appeared first on Alessandro Zulberti.

Reducing Cognitive Load During Peak Traffic

The Company approached its holiday campaigns with a clear ambition: convert seasonal traffic into meaningful engagement and confident purchasing decisions.

Earlier campaigns assumed that high holiday intent meant users already understood the product value and needed only visual appeal and refreshed layouts to convert. In reality, users required reassurance, guidance, and clearer differentiation, especially under time pressure.

I led UX research and usability testing across successive holiday campaigns, guiding their evolution from surface-level optimisation toward behaviourally informed experiences.

01 / CHALLENGE

Challenge

The initial goal was direct: understand why a visually refined landing page failed to convert during high-stakes holiday moments.

Usability testing revealed that users were not lost; they were unconvinced. Under time pressure and emotional load, behaviour changed markedly. Users became more risk-averse, scanned less, and relied on quick heuristics.

These hesitation points reappeared across successive holiday seasons, particularly around uncertainty about product suitability, shipping timing, and gift appropriateness.

Quantitative data confirmed limited engagement beyond the first scroll. Qualitative sessions explained why: unmet expectations and delayed reassurance.

03 / SURFACE CLARITY

Surface Clarity

Primary Methods

– Remote usability testing, including five-second tests

– Targeted user interviews

– Scroll-depth and click data analysis

– Prototype evaluation of new layout variations

Diagnosing Misalignment Through Usability Testing

The same pattern emerged repeatedly: users were not confused enough to stop, but not confident enough to convert.

One participant captured the tension clearly: after filtering, they felt mostly confident they had found the right product, but still worried there might be a better option they had missed.

05 / DESIGNING FOR DECISION

Designing for Decision

With baseline issues identified, the focus shifted from diagnosis to intentional redesign.

One design direction was deliberately deprioritised: a visually dominant, hero-first layout that pushed explanatory content further down the page. Testing showed that users needed clearer value framing and decision aids earlier, not more visual emphasis.

Using behavioural principles, the journey was reshaped to reduce cognitive load, strengthen salience, and align content order with how decisions are made under pressure.

The landing page evolved from a static presentation into a sequence of deliberate decision moments, separating inspiration from commerce, elevating the Gift Finder, clarifying support pathways, and rewriting copy for rapid scanning.

06 / VALIDATING IN MOTION

Validating in Motion

Primary Methods

– Scenario-based usability testing

– GA4 behavioural data review

– ContentSquare heatmaps

– A/B test planning

– Device-specific observations

– Feedback analysis from live prototypes

Real-Time Research During Campaign Rollout

Before launch, we conducted pre-live validation to refine nuance rather than uncover major flaws.

At one point, analytics suggested improved click-through on promotional elements. However, usability sessions revealed that many of these clicks were driven by uncertainty rather than true engagement.

The tension was resolved by restructuring the hierarchy so promotional elements supported, rather than replaced, decision-critical content.

07 / REFLECTION

Reflection

A small change produced a disproportionate effect: introducing concise, high-salience value statements such as warranty, gifting suitability, and delivery certainty directly above the product grid. This reduced early-journey hesitation and restored confidence.

This project was not about redesigning a landing page. It was about learning how people decide when attention is fragmented and stakes are high.

Clarity, in these moments, is not aesthetic. It is functional.

The post Clarity in High-Season Sales appeared first on Alessandro Zulberti.

The post Accessibility as a Strategic Foundation in the D2C Ecosystem appeared first on Alessandro Zulberti.

The post Agentic AI Reading Instrument appeared first on Alessandro Zulberti.