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.

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.