Reflective journal My account of the SDF work, written in February 2026 about events in 2025.

Technical materials The code, processing logic and diagrams of what I built, showing how it worked.

Dated messages Messages from the time, used only to confirm dates and the order of events.

Participant account What an interviewee described. Not observed or checked independently.

Interpretation dashed outline Conclusions drawn from the evidence.

Stage of use Whether a change was in use, being tested, explored or proposed. These labels describe a stage, not whether the change succeeded.

Research question 1 · Friction

When did a poor fit between tools, information and the way work was organised change how a task could be done?

Short answer

Friction mattered when it changed how the work could proceed: it interrupted work, led to corrections after information had been used, added checking or coordination, held back wider use, or left it unclear who was responsible. Some of it came from generated output, some from other systems people already used, and some from requirements that had to be met before a tool could be used more widely.

Thesis Section 7.3 · full question wording in Section 1.4

What friction means here

More than an inconvenience

GenAI tools can be easy to operate and still hard to use dependably. The tool may not fit the task, may not reach the information needed, may sit outside the system where the work happens, or may produce output that needs a lot of checking. I call this A poor fit between tools, information, the way work is organised, what the task requires, and who is responsible. It is a relationship between these things, not a fault of one tool or person.Thesis Sections 1.8 and 2.9.1 when the poor fit changes how the task is carried out. A small annoyance that does not change the work is not counted.

Before using a tool

Preparing information, getting access, working out what is allowed.

While using it

The tool does not fit the task, or cannot reach the right material.

After an output exists

Checking, correcting, explaining, and deciding who answers for it.

Friction can arise at any of these points. It may prompt a response, but it does not decide what that response will be (Thesis Section 2.9.1).

Where it came from

Different sources, similar effects on the work

The examples below show where difficulties arose and how they affected the task.

Repeated manual work and organisational pathways

My SDF reporting: matching records by hand each cycle, and months of requests for a suitable IT environment.

Reflective journal

Other systems people already used

SP06's Teams service interruption, SP03's bookings spread across several platforms, SP08's research-software errors.

Participant account

Generated output

SP03's incorrect course codes, SP05's invalid classification codes, SP06's feedback carried from one student's draft to others.

Participant account

Requirements before wider use

Answer-risk review (IP01), engineering checks and sign-off (IP02), live-data testing and production approval (IP03).

Participant account

What made it significant

InterruptionCorrection after useMore checking or coordinationRestricted wider useUnclear responsibility

What each setting showed

One workflow examined in depth, alongside accounts of other university work

My SDF reporting workflow

Each reporting cycle I prepared a statement and email for every staff member, checked the figures and answered questions. Each figure had to stay connected to the right staff record and allocation, so a mistake in preparation could carry through to what staff received. This repeated matching was the first source of friction.

Trying to change it exposed a second source. Python processing was already under development, but I also needed an IT environment and permissions where it could run.

  1. February 2025A colleague in a management role forwarded my request to central IT; I answered questions about environment, storage and access.
  2. April 2025After almost two months without a substantive reply, I lodged a service-desk ticket.
  3. May 2025After a senior colleague followed up, I learnt that part of the request fell outside that team's responsibility and that the role I had asked for gave broader access than the work needed.
  4. Late May 2025I lodged a more specific ticket and arranged a meeting.
“I understood this as a correction to the scope of my permission request and as evidence of a gap in my own knowledge of enterprise security governance” Reflective journal, 16 February 2026

Dated messages confirm the sequence. They do not show why the requests moved slowly, whether the May follow-up caused progress, or whether a suitable environment was later obtained. Access to Copilot alone could not resolve either source of friction. Reflective journalDated messages Thesis Sections 4.2.1–4.2.3

Institutional support staff

  • IP01 described a managed service for subject-related assistants that had begun rolling out. IP01 linked the slower wider rollout to governance and to concern that generated answers could sound authoritative while being wrong.
  • IP02's team could build prototypes in its own environment, but an application others would rely on needed engineering checks and architecture and security sign-off. The interview does not establish a measured delay.
  • IP03's prototype drafted messages from made-up data. Testing with live data and production approval were still outstanding.

Review and approval are not friction in themselves. They count here only through their reported effect on what participants could do. Thesis Sections 5.3–5.4

Everyday staff

  • SP06 lost about 20 minutes looking for a class list when the desktop Teams app hid most groups. Copilot neither caused nor solved it.
  • SP03 coordinated short student meetings across Canvas, Outlook, Teams, calendars and local booking methods; Copilot was not available inside Canvas.
  • SP03 also used course-code information from Copilot because it sounded convincing, and found it was wrong only after checking with students.
  • SP05's early classification trial produced plausible explanations paired with invalid codes.
  • SP06 found a comment about one student appearing in feedback drafts for other students.
“So I thought Copilot was right because it sounded convincing. So I thought it was right. So I went with that information, but of course it wasn't all correct as chat bots are” SP03

Thesis Sections 6.4 and 6.6

Research it builds on

Technology matters through the work around it

Trist, E. (1981). The evolution of socio-technical systems: A conceptual framework and an action research program (Occasional Paper No. 2). Ontario Ministry of Labour, Ontario Quality of Working Life Centre.

Social and technical arrangements are organised around a task, so neither can be judged on its own. Used here to judge workability at the level of the whole work arrangement.

Orlikowski, W. J. (1992). The duality of technology: Rethinking the concept of technology in organizations. Organization Science, 3(3), 398–427. https://doi.org/10.1287/orsc.3.3.398 · Orlikowski, W. J. (2008). Using technology and constituting structures: A practice lens for studying technology in organizations. In M. S. Ackerman, C. A. Halverson, T. Erickson, & W. A. Kellogg (Eds.), Resources, co-evolution and artifacts: Theory in CSCW (pp. 255–305). Springer. https://doi.org/10.1007/978-1-84628-901-9_10

A technology's role develops through use, not through its design or availability. Used here to explain why access to a tool does not settle how it fits the work.

Buck, C., Doctor, E., Eymann, T., & Simoes, E. J. (2020). A systematic literature review on antecedents of workarounds related to information systems in hospitals. In N. Gronau, M. Heine, H. Krasnova, & K. Pousttchi (Eds.), Entwicklungen, Chancen und Herausforderungen der Digitalisierung: Proceedings der 15. Internationalen Tagung Wirtschaftsinformatik (WI 2020) (pp. 664–679). GITO Verlag. https://doi.org/10.30844/wi_2020_f7-buck

Conditions behind workarounds, such as poor fit and inflexible systems, often occur together. Used here to look across the whole arrangement rather than for one failure.

Sui, Y., Zou, J., Zhou, M., He, X., Du, L., Han, S., & Zhang, D. (2024). TAP4LLM: Table provider on sampling, augmenting, and packing semi-structured data for large language model reasoning. In Y. Al-Onaizan, M. Bansal, & Y.-N. Chen (Eds.), Findings of the Association for Computational Linguistics: EMNLP 2024 (pp. 10306–10323). Association for Computational Linguistics. https://doi.org/10.18653/v1/2024.findings-emnlp.603

How table-like data is prepared shapes what a language model can do with it. Used here to show that friction can begin before a question is asked.

Why it matters

Look at what a problem does to the task, not only where it came from

Treating friction as a change to how a task proceeds makes it possible to compare quite different problems: a hidden Teams group, an invalid code, a slow approval. These problems connect with longstanding research on how technology fits into work. GenAI introduced particular checking demands, alongside difficulties involving existing systems and organisational requirements.

A related experiment by Si, C., Goyal, N., Wu, T., Zhao, C., Feng, S., Daumé, H., III, & Boyd-Graber, J. (2024). Large language models help humans verify truthfulness – except when they are convincingly wrong. In Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Vol. 1, pp. 1459–1474). Association for Computational Linguistics. https://doi.org/10.18653/v1/2024.naacl-long.81 found that people could over-rely on convincing but incorrect explanations from language models. SP03's account does not show that this happens across a staff group; it shows where checking entered one task. Thesis Sections 7.3 and 7.7.1