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?

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

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.

The post Blueprint Grammar appeared first on Alessandro Zulberti.

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.

Productivity Decision Compass

The assumption, in three moves.

1. Scan the surplus — when unexpected time appears, survey what could be done with it.
2. Choose the highest-leverage move — commit to one use rather than diffusing across several.
3. Close the loop — capture what the choice produced so the next decision is better informed.

Why it was dropped. It’s a personal-productivity tool, not a research method. It answers “what to do with spare time,” not any question about users, evidence, or service conditions. A framework belongs in a body of work only if it addresses that work’s actual domain — a good tool in the wrong section weakens the section. Category coherence is a bar, not a formality.

Triangulation Lens

The assumption, in three moves.

1. Gather across types — hold quantitative, qualitative, and observational evidence side by side.
2. Read the disagreement — treat conflict between sources as information, not a problem to resolve away.
3. Notice the absence — ask which type of evidence is missing before trusting the picture.

Why it was dropped. It is triangulation. Mixing evidence types and noticing which is absent is foundational method, taught everywhere. The name added nothing the concept didn’t already carry. Renaming a standard practice isn’t authorship — if the idea survives without my framing, my framing wasn’t the contribution.

Stakeholder Listening Compass

The assumption, in three moves.

1. Attend before extracting — listen for what a stakeholder means before converting it into requirements.
2. Translate into layers — separate the stated ask from the underlying concern and the organisational pressure behind it.
3. Reflect back — return your reading to the stakeholder to test whether it holds.

Why it was dropped. It’s active-listening technique applied to stakeholders — competent, generic, and available in any facilitation guide. “Applied to stakeholders” is not a differentiator. Porting a common technique to a new audience doesn’t make it a new framework.

Heuristic Plus

The assumption, in three moves.

1. Apply the heuristics — evaluate an interface against Nielsen’s ten.
2. Ask what each misses — for every heuristic, name what it can’t see in this context.
3. Record the gap — treat the blind spot as a finding in its own right.

Why it was dropped. The substance is Nielsen’s, verbatim. The additive move — “ask what it misses” — is a single question standing on someone else’s framework, not a framework in itself. Building a small extension onto a well-known model invites the obvious question of what I actually added. If the answer is one prompt, it’s a note, not a framework.

Ethnographic Lens

The assumption, in three moves.

1. Enter with curiosity — let the field surprise you before categories lead the encounter.
2. Describe before interpreting — record verbatim and physical action before assigning meaning.
3. Frame as partial — present the reading as true of these people, in this context, seen from here.

Why it was dropped. It’s a competent summary of applied ethnography — true, useful, and indistinguishable from a methods-handbook page. Accuracy is not distinctiveness. A correct summary of an existing discipline is teaching material at best, not an original instrument.

What the discarding was actually for

The five failed on two bars: distinctiveness (does it contribute something beyond established practice?) and category coherence (does it belong in this body of work at all?). Neither bar is about the idea being bad. Triangulation is good practice; ethnographic discipline is good practice. They’re just not mine to name, and publishing them as frameworks would have claimed authorship I hadn’t earned.

The useful part isn’t the drop. It’s the test. The check I apply to everyone else’s work — what, specifically, is this, and where is the evidence — is the check I stopped applying to my own the moment the output started arriving fast and looking finished. Obvious words are easiest to generate when they’re yours. Keeping this record public is a way of keeping the test switched on.

The post Dropped Ideas: Working Frameworks appeared first on Alessandro Zulberti.

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 Company is best known for its iconic Swiss Army Knife, but its digital ecosystem had grown into something far more complex: multiple eCommerce platforms, service portals, and brand-led websites operating across markets and systems.

As the ecosystem expanded, delivery speed increased faster than shared clarity. Platform and feature decisions were increasingly driven by internal opinion, legacy assumptions, and isolated performance metrics. The risk was not slow delivery, but accelerated launches without validating user impact or accessibility implications.

The Company was undergoing a major transformation: a move from a monolithic commerce platform to a composable, headless architecture; the launch of new digital platforms; and an ambition to increase eCommerce performance globally.

At the same time, accessibility requirements were rising, internal ownership was fragmenting, and teams were under pressure to deliver quickly.

I led a research-led transformation focused on turning fragmented signals into shared evidence, structured around four pillars.

Approach

Continuous Discovery

I embedded mixed-method research across web properties to surface behavioural friction early and create a steady flow of decision-ready insight.

Across platforms and over time, one pattern remained consistent: persistent friction around navigation clarity and content hierarchy. Users repeatedly struggled to understand where they were in the journey and how to progress, particularly in product exploration and service flows.

These observations reinforced that the issue was not visual design, but semantic precision and hierarchy.

Approach

Cross-functional Enablement

I worked closely with eCommerce, Development, and Marketing to translate research findings into prioritisation inputs, ensuring insights informed roadmap, content, and feature decisions.

Approach

Operationalising Accessibility

I acted as a point of escalation for digital accessibility, embedding WCAG requirements into delivery processes so compliance became a design and development concern rather than a late audit.

Approach

Platform-First Thinking

During the SAP Commerce Cloud migration, I supported the evolution of the design system to meet new development constraints, enabling consistency across Community Online, B2B, and brand platforms while preserving flexibility.

In practice

Revenue Optimisation via UX Research

I combined behavioural analytics with usability testing on key product subcategories to understand where personalisation and navigation workflows broke down.

These signals helped distinguish genuine engagement from uncertainty-driven interaction and guided targeted adjustments to structure and content.

In practice

Service Blueprint for Repairs

I mapped the end-to-end journey for the Repair Service, connecting frontend interactions with backend processes. The service blueprint exposed misalignments between user expectations and internal workflows, creating a shared reference for operational and experience improvements.

In practice

Platform Migration Support

During the transition to a headless architecture, I partnered with development and content teams to maintain UX coherence across releases. Documentation and design-system updates helped balance speed, branding, and consistency during parallel launches.

In practice

Accessibility as a Cultural Shift

Recurring failures in semantic structure, contrast inconsistencies, and keyboard-navigation traps clearly indicated systemic design-system issues rather than isolated defects. This evidence proved decisive in prioritisation discussions and shifted accessibility from reactive fixes to structural improvement.

Outcome

Decisions became more evidence-led, accessibility risks were surfaced earlier, and platform changes were supported by a shared understanding of user behaviour.

We shifted from release-driven decision-making to evidence-informed prioritisation, using research as a standard checkpoint rather than an optional add-on.

Scaling UX research in this context was less about introducing new methods and more about changing how certainty was earned.

When research consistently showed where assumptions failed, and when signals were shared across teams, UX moved from being a support function to a source of clarity during change.

Next

Continue to the next case study.

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 Design appeared first on Alessandro Zulberti.