Schön's Reflective Model: Reflection in Action and on Action

Go from storyboard to an interactive course in minutes

Start Free

Picture a field service technician on the roof of an office building on a hot afternoon. The job ticket says level 6 is too hot, the manufacturer's flowchart points to a failed temperature sensor, and the new sensor goes in without trouble. Twenty minutes later the unit trips again. The building manager has a client event at 4 pm, the company rewards jobs fixed on the first visit, and nothing in the flowchart covers what happens next.

I'm an instructional designer at Coursebox, where we make instructional design software that turns a brief into a course outline, so I'll mention our product where I tested it. Donald Schön wrote about this kind of moment: the point where a skilled person's routine stops working and they have to think while they act. I cover what Schön said, in his own words, why his ideas have no stages, one rooftop call-out worked through each idea, how to build them into training, two real cases, the criticisms and two free templates.

What is Schön's reflective model?

Schön's reflective model is the usual name for Donald Schön's account of how professionals think while they work: they act on tacit know-how, and when a situation surprises them they reflect in action, reframing the problem and testing a new move, then reflect on action afterwards.

View the full-size diagram

Schön set it out in The Reflective Practitioner: How Professionals Think in Action (Basic Books, 1983). He did not present it as a model; the label came later. His starting point was ordinary skill. "Our knowing is ordinarily tacit, implicit in our patterns of action and in our feel for the stuff with which we are dealing," he wrote. "It seems right to say that our knowing is in our action" (p. 49). In a 1987 address he put the two central ideas side by side: the capacity to do the right thing, "knowing more than we can say", "is what I mean by knowing-in-action. And this capacity to respond to surprise through improvisation on the spot is what I mean by reflection-in-action."

The purpose was an argument about professional knowledge. Schön thought universities and professions had taught that good practice means applying research and technique to well-formed problems, and that this left out how skilled people handle the messy situations they meet every day. In the 1983 book his cases came from architecture, psychotherapy, engineering, town planning and management, not nursing or teaching, although both professions took up his work later. Two other strands shape how the ideas are used today:

• Education for practice. His 1987 book turned to how professionals learn, through practice with a coach in a protected setting he called a reflective practicum.
• Organisations. Before and after the 1983 book, he wrote with Chris Argyris about the gap between what people say guides them and what their actions show, and about double-loop learning, where a review questions the rules and goals behind a mistake.

Here are the main ideas at a glance, with the question each one puts to a training designer.

Case study: Reflection in Agile software teams in the US, New Zealand and India

This was an explicit application: the researchers built their model of reflective Agile work on Schön's theory. Agile software teams already have reflection in their routines, such as a retrospective at the end of each work cycle, but the researchers found those habits are often the first to fade as teams settle in and focus on delivery.

• What they did: In a nine-month action research study in a small US software company, the team worked to make reflection-in-action a habit, including "microblogging" their thoughts and observations in a team wiki as they worked. Retrospectives, daily stand-ups and short learning spikes served as reflection-on-action. A separate study of 58 practitioners from 23 companies in New Zealand and India fed the same model.
• Evidence and result: Babb, Hoda and Nørbjerg reported in IEEE Software in 2014 that "the practices most likely to be lost, sacrificed, or compromised over time were those most closely related to learning and reflection". The paper reports no measured result for the US team's new habits. In the separate New Zealand study, one team found in a retrospective that manual testing was placing high demands on its productivity, and automated the testing. Its pace dropped in the short term, and the authors judged that the team clearly benefitted over the longer term.
• Limitation: Both studies were qualitative, with no measured outcome. In action research the researchers take part, and the authors built the model from their own studies, so the benefit is their judgement rather than a measured effect.
• Lesson: Make reflection in the moment cheap, such as a one-line note at the point of surprise, so the later review has real material. Then protect the review's time under delivery pressure; these studies found reflective practices especially vulnerable.

Schön's books: which one to read

Schön's ideas are spread across several books, and the dates often get mixed up.

• The Reflective Practitioner (1983). Read this one. Chapter 2 sets out the argument and defines reflection-in-action, and chapter 3 follows an architecture tutor, Quist, reviewing a student's design. The 1991 and 2016 printings are reprints, and the "1984" on some copies is a reprint date.
• Educating the Reflective Practitioner (1987). Read it if you train or mentor people. It covers the reflective practicum and how a coach works. His 1987 address to the American Educational Research Association, which shares the book's title, is a free and shorter way in.
• Argyris and Schön, Theory in Practice (1974) and Organizational Learning (1978). Read these for espoused theory, theory-in-use and double-loop learning. A revised Organizational Learning II followed in 1996.

Donald Schön (1930 to 1997) trained in philosophy and from 1972 was Ford Professor of Urban Studies and Education at MIT. One more date detail: the 1983 book is about reflection-in-action. "Reflecting on action" appears there only in passing, and the paired terms took shape in his later writing, including a short 1995 article in Change.

A reference in Harvard style:

Schön, D. A. (1983) The Reflective Practitioner: How Professionals Think in Action. New York: Basic Books.

What problem was Schön trying to solve?

Schön was arguing against a view of professional competence he called technical rationality: the idea that "professional activity consists in instrumental problem solving made rigorous by the application of scientific theory and technique" (1983, p. 21). On that view, training means teaching the techniques.

His objection was that "In real-world practice, problems do not present themselves to the practitioner as givens" (p. 40). Someone has to work out what the problem is first. Then comes the passage people remember:

"there is a high, hard ground where practitioners can make effective use of research-based theory and technique, and there is a swampy lowland where situations are confusing 'messes' incapable of technical solution." (1983, p. 42)

A sentence later he adds that "in the swamp are the problems of greatest human concern". Schön was not dismissing research or procedure. As Elizabeth Anne Kinsella put it in a 2007 analysis in Nursing Philosophy, he was "not discarding research-based professional knowledge, but rather challenging conflated views of its practical significance". The high ground is real, and plenty of work belongs on it.

For workplace training, the swamp is a useful test. Procedure-and-quiz training covers the high ground well: permit-to-work rules, lock-out steps, the manufacturer's diagnostic flowchart. The hardest moments of most jobs sit in the swamp: the fault that does not match the flowchart, the customer who does not fit the script. Schön also noted that "competent practitioners usually know more than they can say" (p. viii). That helps explain why courses written from a procedure document tend to leave the swamp out. So sort a course's parts with that test. High-ground tasks get a clear procedure and a check. Swamp tasks get scenarios with incomplete information, a pause to think inside them and a coached review afterwards.

The worked example: a rooftop call-out

I'll use one hypothetical example for each idea. A commercial building services company maintains heating, ventilation and air-conditioning (HVAC) plant in office buildings, and its field service technicians work on site. The learners are technicians in their first 12 months of solo call-outs, plus the senior technician who mentors them. They hold their trade licence and have done the manufacturer's training, but a licence does not show how someone handles a job that stops making sense.

The job: a tenant on level 6 reports the floor is too hot on a summer afternoon. The job ticket and the manufacturer's diagnostic flowchart point to a failed temperature sensor on rooftop unit 2, and the company's first-time-fix measure rewards swapping the part and closing the job. The technician replaces the sensor. Twenty minutes later the unit trips again, and the fault log shows it trips only when the building's other rooftop units start up. The building manager wants it fixed before a client event at 4 pm.

So that learners' decisions can be judged, the course gives them a job pack: the job ticket, the flowchart step that was followed, the unit's fault log with timestamps, the start-up schedule for all the rooftop units, the site's electrical permit rules and the building manager's message. One safety rule sits over everything: no live electrical work outside the technician's licence and the site permit, and escalate if a test needs it.

The intended outcome is that technicians recognise when a fault no longer matches the flowchart, test a new explanation safely, keep the client informed and bring the job to a review that the mentor runs as coaching rather than a verdict. The example suits Schön because it is a swamp problem inside a job that looks technical, with a clear surprise, room for an on-the-spot experiment, a coaching relationship and a company measure to question.

Schön's ideas, worked through one call-out

Each idea has a short definition, then the same three labels: Schön's words, the call-out and the course.

Knowing-in-action

Knowing-in-action is the skilled, mostly unspoken know-how people use without stopping to think. Just before naming it, Schön lists three of its features: we act without thinking first, we are often unaware of having learned it, and we usually cannot describe the knowing our action shows. He credits the philosopher Michael Polanyi, "who invented the phrase 'tacit knowing'" (p. 52), so knowing-in-action is Schön's term for an older idea, applied to professional work.

• In Schön's words: "It is in this sense that I speak of knowing-in-action, the characteristic mode of ordinary practical knowledge." (p. 54)
• On the call-out: The sensor swap is knowing-in-action at work. The technician reads the ticket, follows the flowchart, swaps the part and expects the job to close, all without much thought. On most jobs that is exactly right.
• In the course: Do not teach the routine as if it were the whole job. The senior technician's knowing-in-action, such as which fault-log patterns make them suspicious, is what new technicians lack, and the procedure document will not contain it.

Reflection-in-action

Reflection-in-action is thinking about what you are doing while you can still change the outcome. It starts with a surprise: "Stimulated by surprise, they turn thought back on action and on the knowing which is implicit in action" (p. 50). The practitioner then "may surface and criticize his initial understanding of the phenomenon, construct a new description of it, and test the new description by an on-the-spot experiment" (p. 63). Schön stresses that this need not be fast. It "is bounded by the 'action-present,' the zone of time in which action can still make a difference to the situation", which "may stretch over minutes, hours, days, or even weeks or months" (p. 62).

• In Schön's words: "When someone reflects-in-action, he becomes a researcher in the practice context." (p. 68)
• On the call-out: The surprise is the second trip. The technician stops treating it as a sensor fault and says what they now think: the trips line up with the other units starting, so it looks like a supply or load problem. The on-the-spot experiment is a quick, safe test that tells the two explanations apart, such as requesting an authorised diagnostic check from a suitably qualified person, or reviewing existing fault and start-up records to test the suspected connection. A changed operating schedule also needs approval through the site procedure. They keep the building manager informed as they go.
• In the course: Put the pause inside the scenario, at the moment the unit trips again, and ask open questions before the learner chooses what to do: what surprised you, what do you now think is going on, what quick test could you run right now, and what will you tell the building manager? Then show the consequence of the choice, including a branch where the learner swaps another part without testing.

Reflection on action

Reflection on action is looking back on the job after it is over and putting what happened into words. Schön describes it as reflecting on reflection-in-action. His example is a basketball player watching a recording of Saturday's game, asking himself "How was I trying to get past that guard? Why didn't it work? What moves should I try next time?" (1995, p. 30). In his 1987 address he made the contrast with reflection-in-action plain: looking back "IS an intellectual business, and it DOES require verbalization and symbolization".

• In Schön's words: "Yet we also have the ability to reflect on such a process, reflecting on reflection-in-action." (1995, p. 30)
• On the call-out: The next morning, the technician writes up the job: what happened, what surprised them, how their view of the fault changed, what they tested and what it showed, and what they would do next time.
• In the course: Make the after-the-job review a separate activity in open text, not a quiz about the scenario. Give it real material by asking for a one-line note on the job ticket at the moment of surprise.

Coaching in a reflective practicum

Schön's 1987 work asks how people learn to work in the swamp, and his answer is practice with a coach. A reflective practicum is "a situation in which people learn by doing", in "a virtual world in the sense that it represents the world of practice, but is not the world of practice". The person helping is "more like a coach than like a teacher", and at its best the two hold "a dialogue of reciprocal reflection-in-action".

• In Schön's words: The coach's job includes describing and demonstrating in ways suited "to the difficulties and possibilities of THIS particular student", and "building a relationship in which defensiveness is minimized" (1987 address).
• On the call-out: The senior technician runs a 20-minute review of the job. Descriptions of Schön's 1987 book give three ways a coach can work, and the mentor can use each. They can demonstrate and ask the technician to follow, such as showing how they read the fault log. They can experiment together, trying the next test side by side on a similar job. And the review itself can be what Schön called a "hall of mirrors", where "the teacher of the teacher is also doing the thing that she is teaching": the mentor asks the questions they want the technician to ask on the roof.
• In the course: A protected, coached simulation can form part of a reflective practicum. Coaching can also continue around real jobs; it is not confined to the after-job review. Add a guide for the mentor, with questions to ask and a note on when to show and when to hold back, rather than a checklist for grading the technician.

Double-loop learning

Double-loop learning comes from Schön's work with Chris Argyris. In Theory in Practice (1974) they separated espoused theory, what people say guides their actions, from theory-in-use, what their actions show. In Organizational Learning (1978) they described single-loop learning, which corrects an error within the existing rules and goals, and double-loop learning, which questions those rules and goals. They compared single-loop learning to a thermostat that turns the heat on or off when the room is too hot or too cold. Argyris and Schön share the credit for both books.

• In their terms: Single-loop learning fixes the error. Double-loop learning asks whether the norms, policies or objectives that produced it should change.
• On the call-out: The single-loop fix is a better sensor check in the flowchart. The double-loop question is whether the first-time-fix measure pushes technicians to swap parts instead of diagnosing. The espoused theory is "diagnose properly"; the theory-in-use, shown by what gets rewarded, may be "close the job fast".
• In the course: Give the team, not only the individual, one open question about the measure: does it encourage swapping parts, and what could change? A course cannot change the measure, but it can surface the question for the people who own it.

Skilled people can be very good at single-loop fixes and still keep an organisation from learning, as Anita Tucker and Amy Edmondson's 2003 study of hospital nurses showed.

That time went on coping: workarounds that let the task continue and left the cause in place. The technician who swaps a part to hit first-time fix is doing the same thing on a roof.

Case study: Nurses working around failures in nine US hospitals

This study used Argyris and Schön's ideas as a lens on what the researchers observed; it tested no training. The researchers wanted to know why hospitals kept meeting the same small operational failures, such as missing supplies, missing or wrong information and missing orders.

• What the researchers did: They observed 26 nurses at nine hospitals for 239 hours and recorded 194 failures. They coded each response as a workaround that let the task continue, or as an action that alerted someone who could remove the cause, which they describe as "analogous to Argyris and Schon's notion of single and double loop learning". They also interviewed 12 nurses.
• Evidence and result: In their California Management Review article, nurses worked around the failure for 93% of the problems. Only 7% of responses alerted anyone who could fix the cause, even on lenient criteria. Seventy percent of the nurses interviewed believed their manager expected them to work through the disruptions on their own.
• Limitation: It is an observational study of 26 nurses, with more observation hours at one hospital, and the data are more than 20 years old. The authors call their categories analogous to single- and double-loop learning, not the same thing, and they tested no intervention.
• Lesson: A quick fix done well can still hide the cause. Build a "who needs to know?" step into the job and the course, and make it normal to raise the cause with the people who can remove it.

What is the difference between reflection-in-action and reflection-on-action?

Reflection-in-action happens during the work, while what you do can still change the outcome. Reflection-on-action happens afterwards, when you look back and put the experience into words. Schön's own framing links them: looking back is reflection on the reflection-in-action that happened during the job.

The two are not stages in a fixed order. Reflection-in-action can happen several times in one job, or not at all on a routine one, and a review can look back on a job where nothing surprised anyone. The line between them also blurs when the work is slow, which is one of the main criticisms of Schön's ideas.

Two later additions often get credited to Schön. Reflection-for-action, thinking ahead to guide the next situation, comes from Killion and Todnem's 1991 article in Educational Leadership, which describes it as "A third type of reflection" added to Schön's two. And the three questions "What? So what? Now what?" go back to Terry Borton in 1970, developed later in nursing by Driscoll and by Rolfe, Freshwater and Jasper.

How to build Schön's ideas into workplace training

Schön did not write a design method, so this workflow is my adaptation of his ideas for a training designer, using the call-out as the example.

1. Sort the job into high ground and swamp. List the tasks the procedure covers well and the moments where it runs out. Only the second list needs the rest of this workflow.
2. Find the knowing-in-action. Watch experienced staff or walk through recent jobs with them, and ask about the last time a job surprised them. The procedure document will not tell you.
3. Write the surprise into a scenario. Use a real pattern, give learners the information a good decision needs, and do not let the right answer be obvious from the procedure.
4. Pause inside the scenario at the surprise. Ask open questions before the learner chooses, then show the consequence of the choice. Place the decision before the scenario outcome if you want learners to reconsider while they can still affect it. A written or selected-response question can sit at that point; timing and reasoning determine its role, not the response format. Looking back after the outcome is reflection on action.
5. Keep the safety boundary visible. Make escalation a good outcome where the test needs work outside the learner's licence or permit.
6. Ask for the cheap note on the job. One line at the moment of surprise, on the ticket or in a log.
7. Run reflection on action as a coached review. A short review with a mentor within a few days of a surprising job, with questions for the mentor to ask.
8. Ask the double-loop question as a team. When reviews keep finding the same workaround, ask what rule, target or measure is producing it.
9. Check later jobs, not only the course. Look at the next surprising jobs for the behaviour you wanted, which is the behaviour level of Kirkpatrick's evaluation model.

For steps 3 and 4, a scenario-based learning design with branches does most of the work, and our branching scenario examples show how consequences can play out. For step 7, decide whether the senior person is there to coach, train or mentor, because coaching, training and mentoring ask different things of the same person.

The call-out course plan

Here is the rooftop call-out as a plan, with each part tied to one of Schön's ideas.

Getting knowing-in-action out of your experts

Knowing-in-action changes how you interview subject matter experts. Ask a senior technician for the procedure and you will get the flowchart. Their real skill shows in what they notice and test when the flowchart stops working, and they may not be able to put it into words until you take them back to a specific job. These techniques are my own, built on that point:

• Ask about a specific job, not the general rule. "Tell me about the last time a fault came back after you fixed it" gets further than "how do you diagnose a trip?"
• Ask what made them suspicious. The cue they noticed (a timestamp, a sound, a pattern in the log) is the knowing-in-action to teach.
• Ask what they tested first, and why that test. On-the-spot experiments are often quick checks experts no longer think of as decisions.
• Watch a job or walk through one on site when you can. People show more than they say.
• Ask where the procedure is wrong or incomplete. Then check the answer with a second expert before it goes into a course.

What course briefs ask for

To see whether people brief courses for the high ground or the swamp, I looked at course requests typed into Coursebox in the 90 days to 7 October 2026: one per person, from English-language browsers, with no uploaded file. Of 266 prompts, 104 were course requests. I classified them against written definitions. Half were classified by hand and half by an AI classifier, and every positive and borderline call was re-read by hand. Borderline calls were counted in and there was no second independent rater, so treat these figures as classification estimates. Re-reading positive calls does not establish an upper bound or detect all missed requests.

The three were airline check-in agents dealing with unruly passengers, teachers responding to classroom behaviour, and a looser call on a theory course about conflict. The procedure-centred requests included a refinery induction with permits to work, a warehouse safety induction and an ISO 9001 course, and many of those should be procedural. Beyond those three, nobody asked for the moment the procedure stops fitting, and nobody asked for a pause to think inside it or a coached review afterwards. The sample is small and covers requests, not finished courses. If you want a course to prepare people for the swamp, write those three things into the brief yourself.

Schön vs Gibbs, Kolb and other reflection models

Schön's ideas are often taught next to staged reflection models, and they suit different jobs. The table is my synthesis, not a ranking; I found no study comparing them head to head.

Gibbs' reflective cycle is a reflection-on-action tool in Schön's terms: a debrief sequence for after the event, built on Kolb. Kolb's experiential learning theory describes learning across a whole sequence of experience and reflection, and it is the better fit for planning a course. Schön puts the thinking during work and the coaching relationship in the foreground. Gibbs and Kolb can be used alongside those activities, so the comparison is about emphasis rather than an absolute exclusion. For the rooftop call-out, I would use Schön to design the scenario pause and the mentor review, and Gibbs' stages if the team later needs a structured debrief of a serious incident.

Limitations of Schön's reflective model

Schön's ideas are widely taught, but they have drawn steady criticism, and the evidence for them as a training approach is thin.

• Time is tight in some work. Michael Eraut argued in a 1995 critique in Teachers and Teaching that none of Schön's examples relate to crowded settings like classrooms, and that "a rapid intuitive process is not the same as a slower, more deliberate, process". Schön had answered part of this himself: some moments are too dangerous for thought, "But not all practice situations are of this sort" (1983, p. 278).
• In and on action are hard to separate. Eraut also found it "difficult to see how one could distinguish reflection-in-action from reflection-on-action when the action is cool and deliberate rather than hot and rapid". For design purposes, the pause inside the scenario and the review after the job are separate activities, whatever you call them.
• Some critics doubt it can be done, or say it ignores context. Linda Finlay's 2008 review of reflective practice summarises Jennifer Moon as regarding reflection-in-action as unachievable, Usher and colleagues as finding Schön's account unreflexive, and Boud and Walker as arguing that it ignores the context in which reflection happens.
• It says little about power and organisations. Thompson and Pascal argued in Reflective Practice in 2012 that reflective practice tends to be oversimplified and that common accounts give too little weight to its social and political side. In a workplace, whether a technician can question the first-time-fix measure depends on more than their reflection.
• Reflection is hard to assess. Graham Ixer concluded in a 1999 article in the British Journal of Social Work that "there is no theory of reflection that can be adequately assessed". A well-written review shows that someone can write about a job, not that they handle the next one differently, so treat marks on reflections as formative feedback.
• The workplace evidence is thin. I found no controlled workplace trial outside medicine that names Schön and measures a work outcome. The best experimental evidence comes from medicine: in a 2008 study of 42 internal medicine residents in Brazil, described in the authors' 2023 review, a deliberate pause to re-check a first diagnosis, which they describe as reflection-in-action, improved accuracy on complex written cases and made no difference on simple ones. A 2010 Dutch study found a similar benefit after a biasing exercise. A larger randomised study of 393 clinicians found no difference for a related approach.

Using Schön's ideas with an AI course builder

On 8 October 2026 I briefed Coursebox to build the rooftop call-out course. Coursebox is our product, so weigh my account with that in mind. The brief gave the job facts and the job pack and asked for a plain explanation of Schön's ideas with no stages, a scenario that pauses at the second trip with open-text questions, an after-the-job review, a guide for the mentor's coaching conversation and a wrap-up.

Much of it came back as briefed. The outline opened with "Before You Start" and a page to open the call-out job pack. "When Procedure Runs Out" had pages titled "Knowing Beyond the Flowchart" and "Notice the Mismatch", an open-text page, "Describe Your Working Picture", and no stages in the outline. "On the Roof" set the rooftop unit 2 scenario at the second trip.

What was missing was the coaching side, which is what Schön's 1987 work is about. The first outline had no after-the-job reflection page, no mentor review guide and no wrap-up. The outline also had no separate section for the brief's question about the first-time-fix measure; the nearest was "Carry It Forward", on turning experience into team learning, so that page needs checking for the question.

One follow-up message added the missing review, coaching and wrap-up pages to the outline. I asked for the after-the-job review, the mentor's coaching guide and the wrap-up from my brief, then reloaded the outline and checked it. It now had "After the Job", with an open-text reflection on the call-out; "Review With Your Mentor", a 20-minute coaching review with questions for the mentor; and a final "Wrap-up" on bringing your next surprising job to a mentor review. It came to about 56 minutes across 7 sections and 12 pages. I checked the outline only: two short quizzes remain, a thinking-in-action check and a choice of next action, and whether the scenario pauses inside the call-out with open-text questions is something to check in the generated course. The revised outline includes those parts of the plan, but the scenario pause, consequence branches and question about the first-time-fix measure still need checking in the generated pages.

Putting Schön's ideas to work

Schön's reflective model is not a procedure to follow. It is an account of how skilled people think when the procedure runs out: they notice a surprise, rethink the problem and test a new move while they can still change the outcome, then look back on it afterwards, ideally with a coach. Use it to decide which parts of a job need more than a procedure and a quiz. For well-defined tasks, start with clear instruction, suitable practice and a performance check. More support may still be needed, especially for newcomers. For the moments where the procedure stops fitting, build in a scenario pause, a coached review and a question about the rules behind repeated workarounds.

Start with one job: sit down with your most experienced person and ask about the last time it did not go to plan. That surprise is what the scenario pause and the mentor review are built around.