Reflection on the elective module, in the What / So What / Now What structure used across this portfolio. The applied intervention was submitted on 24 May 2026; this reflection draws on the peer testing and the cohort forum that ran across the module's four weeks.

WHAT?

TThis was the module I had been waiting two years for. It asked me to design a technology-enhanced intervention in my own teaching, implement what I could, evaluate it, and reflect. For once the brief asked me to do the thing I came here to do rather than write about it: use Design Science Research to solve a real teaching problem.

Curriculum Development and Assessment had let me think about my teaching from a safe distance. This one wanted a real intervention in front of real students, which was exciting and a little terrifying. It ran alongside my Research Methodology work too, and the two conversations kept pushing against each other in useful ways.

The problem was not hard to find. I have been living with it.

Every second February I teach the Evidence and Information in Health Management module on the Postgraduate Diploma in Healthcare Management, a seven-day intensive for fifteen to twenty mid-career managers from the public and private sectors. They arrive with deep workplace knowledge and almost no exposure to information-systems theory or design research, and every year they stall at the same place: the DSR problem statement, the first move that shapes everything downstream. The 2026 marking data named the pattern more precisely than my impression of it ever had. Students drift to national-system scope when the problem they can work on sits at the level of a workflow or a single data field. They fold constraints and limitations into one another, and asked for constraints they write "funding" and stop. The constraints criterion scored bottom of the five, a cohort mean of one out of two, and it did so although every student had the rubric in front of them and the lecturer's written appraisal beside it.

That last detail reorganised my thinking. What these students needed was not more to read; it was something that intervenes at the moment of reasoning rather than the moment of reading. A closeness paradox sits underneath it: a manager knows their workplace so intimately that the problem feels self-evident, which is the very reason they cannot scope it. The questions a supervisor would ask to loosen that, patiently and one at a time, do not divide across twenty people and a single teaching team.

ProbleMeisha is my answer to that arithmetic, and I named her with some care: a warm, recognisably South African woman's name, so the help would feel like a colleague leaning in rather than a chatbot (Figure 1). She is a Socratic tutor, embedded with DSR theory, who takes a draft problem statement and asks the contingent questions a senior supervisor would ask, refuses on principle to write the statement for the student, and fades through a turn cap rather than running on the way chatbots do. She is paired with a Padlet of five columns matching the rubric, a hard scaffold to her soft one. She is also, and this is the part I find satisfying, a DSR artefact about DSR. I built her through the same six-activity cycle she teaches, so the tool is a worked example of the method inside it. Figure 2 sets out where she sits among the workshop's scaffolds.

SO WHAT?

Choosing her meant arguing with the technology rather than simply adopting it, and the module handed me three lenses that disagreed in useful ways. SAMR asked how far the integration travelled, from substitution up to redefinition, and placed the Socratic tutor near the top because no paper version of her exists; but SAMR reads that ascent as a ladder worth climbing for its own sake, a tendency Hamilton and colleagues concede in their own review of the model. TPACK asked whether content, pedagogy and technology were aligned, and exposed Padlet at once: the canvas template holds pedagogical structure and no DSR content, so it fits the teaching while the content sits outside the tool. TPACK is a snapshot, though, good at showing whether the three meet and quiet on which decision should move first. PICRAT turned the question toward the student, from passive to creative and replace to transform, which is the right question to ask; its labels merely flatter you when you score the affordance you intended rather than what a learner does on the day.

Each lens lit one wall and left the rest dark.

Fawns's entangled pedagogy is what made sense of that. His argument is that technology and pedagogy co-shape one another rather than sitting in clean categories, so any single framework offers a partial view and the analytical work lives in holding them together. That was not a position I admired from a distance. It became the thing the build kept proving.

The most useful thing the module did was disconfirm me. I had walked in treating the failure modes as content gaps, the sort of thing a clearer explanation repairs, and the one-out-of-two constraints score, earned with the rubric in hand, says plainly that they are not. I had taken scaffolds to be additive, more support yielding more learning, until Kim and colleagues' effect-size work put the weight on sequencing and fade instead of quantity. Like most people I carried the worry that an AI tutor would think for the student, and only while building her did I see that holding her to questions redistributes the cognitive work toward the student rather than away. The assumption that went deepest was that pedagogy and technology could be specified apart, decide the teaching first and then choose the tool. How she opens, how she handles a manager who arrives with a solution and no problem, when she stops: none of these would sit still long enough to be settled away from what the workshop was for. That is Fawns, met in the work rather than in the citation.

One conviction I brought to the build I had already put in print. A few months earlier I had led a methods paper with two colleagues, arguing that a designed artefact carries prescriptive knowledge rather than serving as a one-off technical fix (Dyers, Mahomed and van Greunen, 2025). ProbleMeisha put that claim under its own load: if artefacts carry knowledge, then building one to teach DSR ought to teach me something about DSR, and it did.

Because she is a DSR artefact, the build is itself evidence, and I kept the logs to show the cycle rather than tidy it away. The two build diaries and Annexure A carry the record. Problem identification came from the 2026 marking dataset. Objectives became a soft scaffold aimed at the five rubric qualities. A facilitator's quiet remark in the design week sharpened them: my outcome verbs, describe, place and indicate, were running in low gear, and lifting them to formulate, situate and specify changed what students were being asked to do rather than only how it read. Design produced her questioning script, her exemplars, and the refusal patterns that stop her answering. Demonstration ran first as a React artefact I could talk to inside a chat window, so I could kick her tyres before committing her anywhere; three long conversations against the failure-mode scenarios caught two behaviours I would otherwise have shipped. Figure 3 maps the six activities of that cycle.

The cycle did not run clean, which is the point.

The specification went through five versions, not one, after I asked the model to play a methodologist, a clinician and a tired learner at nine at night and try to break her. Deployment had its own plot twist: the live site returned the dreaded "404 error" because I had pinned a model identifier that Anthropic had quietly deprecated, and the artefact, very reasonably, declined to roleplay as a model that no longer exists. A one-line fix, a redeploy, and a lesson larger than the string. The whole thing cost about twenty dollars and a good deal of staring at screens. Peffers gives you a sequence; Hevner reminds you the sequence loops, abandons attempts, and doubles back, and the record bears him out.

Peer testing made the entanglement concrete. I put ProbleMeisha in front of senior colleagues, who brought her their own DSR problems, and one round exposed a flaw I would not have predicted. She moved to context questions before testing whether a real problem had been articulated at all, which goes wrong the instant a peer opens with a solution in mind. The fix was to bring root-cause elicitation earlier, and to do it indirectly rather than through bare "why" prompts, which read as patronising in adult conversation. A small finding, and the whole lesson in miniature, because that loop was an unplanned behavioural-validation cycle: it caught the gap between a Socratic tutor in the specification and a polite assistant in practice, the gap I had not thought to design against.

The cohort forum did the rest of the feedback work. Greg named three tensions I have not stopped turning over. Emmanuel pressed the offloading worry that the no-writing rule answers only in part, since a student set on extracting text will open a different tool. Aniena and Maria, between them, showed me that a public canvas fails two students at once, the one who cannot connect and the one who will not speak, and that an empty Padlet card will not tell you which. Fakazi handed me Williamson on solutionism at the moment I had quietly begun treating the existence of the artefact as evidence that it worked. It is not. At submission I could claim that she was implementable and that the iterative loop was productive. What I could not yet claim was that she changes what a student can do.

The forum widened the lens too. Watching peers wrestle with chatbot-supported communication training, virtual clinical reasoning cases and emergency triage simulations across the country made plain that none of us are working in a settled field, and that the discussion sharpens the tensions more often than it resolves them.

A quiet remark in the design weeks reframed the whole thing for me. The innovation, I was told, was not the technology; it was the way the pedagogical work was being redistributed across an AI agent, the peers, the Padlet and me. That has stayed with me. Integrating technology stops meaning adding a tool to a practice that holds still, and starts meaning rebalancing who, or what, holds which kind of thinking. ProbleMeisha makes senior questioning available at workshop scale, but she does not watch the room. The human work is differently shaped, not displaced.

All of this has a shape I recognise. ProbleMeisha is the Theatre of Reflective Design built in software, a mirror that shows a student their own thinking by questioning it, with me as stage manager setting the conditions and then, on purpose, stepping off the stage. The module tested whether the metaphor holds when the mirror is an artefact rather than a person. It mostly does. The limit is the one the cohort found for me: a mirror cannot tell you who has declined to look into it.

NOW WHAT?

By the time I submitted, three refinement loops had already begun, and a fourth waited for the next iteration. The peer-test loop had done its first job and reordered the question sequence in the specification. An exemplar-refresh loop will reseed her examples from each new cohort's own idiom rather than the 2026 baseline, so she does not fossilise. A register-adaptation loop will rework her language for cross-disciplinary use, where Family Medicine and Education name things differently but the rubric criteria still translate. The fourth loop is the one I most want to keep, behavioural validation built in from the start of design rather than stumbled upon late, because the discipline that separates a good instructor-designed tutor from a generic chatbot lives there, in the validation, not in the model underneath it.

The real test is whether she fades. Within an entangled pedagogy, fading is not pulling the technology out of a fixed configuration; it is reconfiguring the workshop so the soft-scaffold work moves from ProbleMeisha to the student. The signal I will watch is the post-activity reflection, the point at which a student holds the constraints-versus-causes distinction without her prompting. If that point never comes, she has become a crutch and the design has failed on its own terms, and a prompt card or a peer-review protocol may carry the same load for less. I would rather build something that works to make itself unnecessary than something elegant that quietly does not.

There is one honesty I owe this reflection, because it is the part I cannot design my way around. I had expected students to object to AI-mediated dialogue on cognitive-justice grounds, and the truthful answer is that the artefact cannot meet that objection. ProbleMeisha runs on training data that under-represents the contexts my managers actually work in. The Socratic constraint helps, by foregrounding the student's own knowledge and refusing to supply content, but the structural questions, who is represented in the data and whose problems get framed at all, sit outside what an artefact can reach. Saying so plainly is more useful than pretending the design dissolves the problem.

Two principles seem to me to travel beyond this case. Socratic AI questioning can support problem-scoping without offloading the thinking, but only on two conditions: the questions must be contingent on what the learner says rather than fixed in advance, and the tool must refuse to write the content. Remove either and it becomes the thing everyone fears. The second principle is quieter. A hard-scaffold canvas avoids the box-ticking collapse only when its columns mirror the assessment rubric the students will be marked against, so that filling a column is the same act as practising the outcome.

Some of this now points past the module. I am building a short course on Design Science Research for Stellenbosch at masters level, and the principles I abstracted from ProbleMeisha will sit inside it as a worked example of the method applied to itself. The facilitator's reframing of innovation as a redistribution of work, rather than a tool bolted on, becomes a teaching point in its own right. My ambition there is specific: that students leave able to ask the design questions it took me a whole module to learn to ask.

The closer thread runs through my own practice. The habit of assuming shared understanding has now surfaced in feedback across Curriculum Development, Assessment, Research Methodology and this module, and I have stopped treating it as a writing problem. It is an assumption I make about audiences whose worlds I share only in part, and it needs a structural fix rather than a stylistic one. The fix I am piloting is a four-sentence opening borrowed from my Leadership reflection: what the issue is, a working definition of any unfamiliar term, why the issue exists, and what the piece does about it. ProbleMeisha encodes the same discipline at the student's level, holding them to scope and definition before they run ahead. The symmetry pleases me.

This sits in my professional development plan as a dated commitment, and I want to be plain about how modest it is. At the next cohort I will run her through the full Day 3 to Day 5 sequence, keep the anonymous turn-level records, score the rubric shift between each student's draft and revision, and set an unscaffolded transfer task at the close, so that a claim of implementable can become evidence of effective, or fail to. I have set myself a rule I am not entirely comfortable with: if the fade signal does not come, she is retired and a prompt card inherits the work. What I cannot yet promise is that I will read that signal cleanly when the time comes, given how much of myself is now in her.

It was my favourite module because it let me work as a designer-researcher rather than a commentator, and the discipline I most want to keep from it is the willingness to say, of my own best work, that built is not the same as effective. That caution reaches past the module into my dissertation, which asks how university faculty experience working with AI in their own teaching and research, where what they can build is a smaller claim than what their builds do for student learning.

I would not have written that sentence a year ago. The MPhil has moved me from someone who picked up new pedagogical tools with enthusiasm to someone who asks harder questions about what each tool is for and what it leaves untouched. I am not done with the questions. I am asking them better.

A NOTE ON FEEDBACK

The feedback that shaped this work came from two places: a round of peer testing with senior academic colleagues, which produced the root-cause-before-context revision, and the cohort forum, which ran across the module's four weeks and where Greg, Emmanuel, Aniena, Maria, and Fakazi each surfaced a tension or a limitation I revised the design or my claims in response to. The examiners' comments will join them here once they are available.

FOUNDATIONAL READING

• Biggs, J. (2014). Constructive alignment in university teaching. HERDSA Review of Higher Education, 1, 5-22.

• Dyers, R. E., Mahomed, H., & van Greunen, D. (2025). Design science research in quality improvement: embedding rigour in digital health innovation. African Journal of Primary Health Care & Family Medicine, 17(2), a5194.

• Fawns, T. (2022). An entangled pedagogy: looking beyond the pedagogy-technology dichotomy. Postdigital Science and Education, 4(3), 711-728.

• Hamilton, E. R., Rosenberg, J. M., & Akcaoglu, M. (2016). The substitution augmentation modification redefinition (SAMR) model: a critical review and suggestions for its use. TechTrends, 60(5), 433-441.

• Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28(1), 75-105.

• Honigsberg, S., Watkowski, L., Mallek, S., Weritz, P., & Drechsler, A. (2025). Designing AI tutoring systems for higher education: an instructor-design perspective. (In press.)

• Koehler, M. J., Mishra, P., & Cain, W. (2013). What is technological pedagogical content knowledge (TPACK)? Journal of Education, 193(3), 13-19.

• Kim, M. C., & Hannafin, M. J. (2011). Scaffolding problem solving in technology-enhanced learning environments. Computers & Education, 56(2), 403-417.

• Kim, N. J., Belland, B. R., & Walker, A. E. (2018). Effectiveness of computer-based scaffolding in problem-based learning: a meta-analysis. Educational Psychology Review, 30, 397-429.

• Kimmons, R., Graham, C. R., & West, R. E. (2020). The PICRAT model for technology integration in teacher preparation. Contemporary Issues in Technology and Teacher Education, 20(1), 176-198.

• Lee, H.-Y., Chen, P.-H., Huang, Y.-M., & Wu, T.-T. (2026). From immediate answers to structured inquiry: a Socratic method-enhanced ChatGPT system for blended learning discussions. Journal of Educational Computing Research.

• Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of Management Information Systems, 24(3), 45-77.

• Reiser, B. J. (2004). Scaffolding complex learning: the mechanisms of structuring and problematizing student work. Journal of the Learning Sciences, 13(3), 273-304.

• Titus-Dawson, S. (2025). Technology-enhanced learning and the pursuit of cognitive justice: perils, pearls, and possibilities. African Journal of Health Professions Education, 17(3).

• Williamson, B. (2024). The social life of AI in education. International Journal of Artificial Intelligence in Education, 34(1), 97-104.