Skip to content

Professional development should guide teachers on integrating digital content and tools, not just offer technical know-how

Principle · All principles
Evidence · 19 claims (15 for, 4 mixed) · 17 studies (5 qualitative, 4 review, 4 associational, 2 theoretical, 1 quant-synthesis, 1 design), q1–q3 · 1 of 17 report an effect size · 18 claims rest on one study

Conditional relationship

This page owns one choice about the content of professional development when a school or program introduces a digital tool (a learning platform, a writing-feedback tool, a data dashboard, a generative AI assistant): whether the PD teaches teachers how to operate the tool, or how to use it to teach their own subject to their own students. For in-service teachers (adult, working in pre-k-12 schools; the same choice applies to faculty in postsecondary teaching) who have access to a tool but use it rarely, or only to display material, PD that starts from a lesson goal in the teacher's subject, shows the tool doing a job in that kind of lesson, and has teachers plan and teach such a lesson with follow-up support, is expected to produce more, and more purposeful, classroom use of the tool (observed use in lessons, skill-performance, at a term-plus horizon) than PD that covers only how the tool works. Better student outcomes are a further hope, not part of what the evidence here reaches.

The relationship is conditional on whether teachers can already operate the tool (if they cannot, a short technical walkthrough is a precondition, not an alternative), on whether they have time between sessions to try it with a class, on the tool's quality for the job (teachers who judge the tool's output poor will not use it, whatever the PD), and on how use is measured: frequency of use, teachers' reports, and observed use for a stated learning purpose are different outcomes.

No claim in this wiki compares integration-focused PD with technical-only PD for the same tool. The page's founding claim is a survey association from a 2000 report: teachers with 11 or more hours of integration training in the previous year reported relying on software and the Internet at almost double the rate of untrained teachers, which does not separate integration content from the hours or from which teachers chose training. The nearest comparison of content is from pre-service preparation (technology instruction built into methods courses correlated more positively with integration ability than stand-alone technology courses, no coefficient printed). Interview and implementation studies add that teachers ask for subject-specific use cases and that tailored support and time went with integration of writing-feedback tools. One qualitative finding limits the model: a technology coach found that single-tool, step-by-step walkthroughs produced uptake where demonstrations of many tools did not, so technical know-how, narrowly scoped, is part of the design rather than the thing to cut. The design below is therefore a default, labelled step by step as tested, carried from a neighbouring finding, or an untested proposal.

How the converted siblings sit beside this page: the Professional Development pattern holds the full coaching cycle for one classroom practice (diagnose, model, rehearse, enact with feedback, fade, check maintenance) and its doses; this page applies that cycle when the practice involves a digital tool and adds only what the tool changes. The Ongoing Study Teams and Peer Coaching principle holds which ongoing school structure carries the cycle. The Digital Learning principle decides whether a tool earns its place at all and credits any gain to the method it carries, which is why PD here starts from the method and the lesson goal; the Technology Augments, Not Supplants principle decides which part of a task stays with the learner when a tool could do it, which is the judgement integration-focused PD should rehearse with teachers.

Default design, while the relationship is untested

The earlier page asked that PD "guide teachers on the effective integration of digital content and tools rather than just offer technical know-how" and that schools "ensure professional development truly supports their digital learning goals". The steps below turn that into a design a PD lead can run and revise. Doses are labelled proposals unless a claim gives them.

  1. Name the lesson goal before the tool (before the first session). For each teacher or subject team, write down one learning goal the tool is meant to serve and the job it does there (more practice with feedback, a record of every student's response, drafting feedback, access outside class). If no one can name the job, the tool may not earn its place: see the Digital Learning principle. Evidence status: untested proposal, from the earlier page; The educational value of GAI is contingent on pedagogical integration, not on the technology itself [+M] is a narrative synthesis making the same argument for generative AI.
  2. Teach one tool, step by step, and only the functions the lesson needs (session 1: proposed 30–45 minutes of hands-on walkthrough on teachers' own devices and accounts). Do not tour the platform's features. Evidence status: Teachers tended to adopt district-provided tools, and single-application step-by-step training supported uptake of Forms [~M] (one technology coach's report, four-country interview study); the time is a proposal.
  3. Show the tool doing its job in the teachers' own subject (session 1, proposed 30–45 minutes: two or three short worked lesson examples from their subject and grade, live or on video, with the reasoning for when the tool is and is not used). Evidence status: teachers' stated need, not an outcome: interviewed science teachers ranked subject-specific examples first among PD topics [+M] (21 in-service teachers, 11 naming subject-specific examples against 7 naming general use).
  4. Teachers plan a real lesson with the tool, in their own content (session 1 or 2, proposed 45–60 minutes, in subject or grade teams). Each teacher leaves with one lesson they will teach within two weeks, including what students will do with the tool and what the teacher will look at afterwards. Evidence status: carried from pre-service preparation: technology instruction integrated into methods and curriculum courses correlated more positively with integration ability than stand-alone technology courses [+M] (survey of preparation programs, no coefficient printed).
  5. Teach it, with tailored follow-up support (within two weeks of the session: a coach, technology lead or colleague available for a 15–20 minute check-in before or after the lesson, aimed at that teacher's lesson and problem). Evidence status: teachers' use of Ecree depended on tailored technical support and time to learn and integrate it [+W] and regular and tailored support helped teachers integrate Ecree and MI Write [+M] (implementation studies of writing-feedback tools in grade 8–11 English classes); technology-focused coaching in the Dynamic Learning Project went with more frequent reported technology use than in non-coached teachers [+M] (end-of-year survey, same schools).
  6. Protect the time to try it (release time or a cut elsewhere, agreed before the PD starts). Evidence status: Teachers used Ecree less than intended, and some reported they did not have enough time to learn it and integrate it with instruction [~M]. Without protected time, the default should expect low use and plan for it.
  7. Debrief on what students did with the tool, then decide keep, adapt or drop (proposed 30–45 minutes in the team, within a week of the lesson). Start from student work or the tool's record of responses, not from whether the tool worked technically. Evidence status: carried from teacher coaching generally: coaching programs improve teachers' instructional practice by a pooled 0.49 SD across 43 causal studies [+M] (coaching of many practices, not technology integration as such).
  8. Repeat across the term, with support shifting to the teachers (proposed: four to six cycles of steps 4–7, two to three weeks apart, about 11 or more contact hours across the school year). Early cycles: the PD lead supplies the worked lesson examples and the technical walkthrough. Middle cycles: teachers bring their own planned lessons, and colleagues supply the examples. Late cycles: teachers choose the next use, one colleague observes, and the coach checks in monthly. Move a teacher on to a second tool or a new use when the tool appears, for its stated purpose, in two consecutive observed or shared lessons and the teacher can say when they would not use it (a proposal). Evidence status: the 11-hour figure is the threshold in the survey association that founded this page [+M], not a tested dose; coaching paired with group training and materials went with larger effects [~M] (an exploratory meta-regression, not a test) supports pairing sessions with follow-up rather than either alone; the arc and move-on rule are untested proposals.
  9. Check use, and its purpose, a term later (one observation or a shared lesson per teacher at least six weeks after support ends). Record whether the tool is used, how often, and for the goal named in step 1. Evidence status: untested proposal; self-reported frequency of use, the outcome in most claims here, does not show purposeful use.

When a condition is not met: if teachers cannot get the tool working at all, run step 2 alone first and start the cycle at the next session; if the tool's output is poor for the job (teachers say so, or student work shows it), stop and revisit step 1 rather than adding more PD.

Fitting the design to a situation

The three facts that most change the decision:

  • What teachers can already do with the tool. A teacher who cannot log in or run the basic function needs the short technical walkthrough first; one who operates it fluently but uses it only to display slides needs subject examples and lesson planning, not more training on features. If unstated, ask: can each teacher do the one function the lesson needs now, unaided, and have they used it with a class?
  • Time between sessions and who supports the first lesson. The evidence here points at time and tailored support as the conditions for use. If unstated, ask: how many hours of release time are there across the term, and who can check in with a teacher before and after the first lesson with the tool?
  • What counts as success. Frequency of use, teachers' confidence, observed use for a learning goal, and student outcomes are different targets. If unstated, ask: what should a visitor see in a lesson a term from now, and what student work would show the tool did its job?
If the brief says… Then change… Basis
Teachers already operate the tool fluently (advanced users) but use it little in teaching Drop the technical walkthrough; spend the whole first session on subject examples and planning one lesson; start the follow-up cycle at once Teacher interviews: subject-specific use cases are the top stated PD need [+M] (stated need, 21 science teachers)
Teachers are new to the tool or have low confidence with technology (novice) Keep step 2 and make it longer (two short sessions, one function each), with a printed step-by-step card and a buddy; plan the first lesson around one function only Single-tool, step-by-step trainings produced uptake where multi-tool trainings did not [~M] (one coach's report)
Learners are pre-service teachers in a preparation program Put the tool into methods and subject courses, used on lessons students plan for their subject, rather than a stand-alone technology course Integrated instructional hours correlate more positively with integration ability than stand-alone technology courses [+M] (pre-service, association)
Learners are faculty in postsecondary teaching or trainers in adult-workplace settings Keep the order (goal, one function, examples in their discipline, plan one class session); replace school release time with a scheduled course-design hour; use a colleague in the same discipline as the follow-up untested proposal; the claims here are about school teachers
The tool is a generative AI assistant Add to step 3 an example of where the tool's output is wrong or does the students' thinking for them, and plan where the student attempts first; take teachers' concerns about output quality as a design input, not resistance Teachers cite poor AI output quality and risks to students' cognitive engagement as main obstacles [~M]; the student-side design is owned by the Technology Augments principle
One coach or technology lead for many teachers, or scarce facilitator time (a volunteer, a busy term, a short check-in only) Keep the first session whole-group; replace one-to-one follow-up with a 10-minute check-in per teacher by message before the first lesson, and a team debrief in the next scheduled meeting; ask teams to share one worked lesson each so examples come from colleagues untested proposal; tailored support helped integration [+M] is about support, not its format
Only a single session is possible Run 60 minutes: 15 on one function, 20 on two subject examples, 25 planning one lesson to teach within two weeks; send one follow-up message offering a check-in. Do not claim sustained use from it untested proposal; long-term content-specific support is argued to outperform one-shot sessions [~M] (a review citing a survey and an earlier report)
A fixed short time budget (for example, 90 minutes across the term) Split it into three 30-minute pieces: one function plus one example; plan a lesson; debrief student work after teaching it. Do not add content to fill time untested proposal
Mixed modes: some teachers join remotely, some in the room, or some on a phone only Run the walkthrough on each person's own device and account, with the remote group's screen shared; give planning a shared template both groups write in; check that the tool's teacher view works on a phone before assuming it does untested proposal
The brief names its own routine, framework or rubric (SAMR, TPACK, a district technology standard, its own lesson template or look-for list) Keep it as the planning template and the debrief criteria; change only what the evidence points at: one function at a time, examples in the teachers' subject, follow-up support untested proposal; the evidence speaks to PD content and support, not to which framework is used
The brief uses its own categories for uses of the tool (for example "practice", "feedback", "creation") Sort the subject examples and the planned lessons by those categories, and do not substitute another taxonomy untested proposal
PD is tied to appraisal, or the debrief would use lesson video or student data that is private Separate the follow-up from evaluation; the teacher controls who sees the lesson video and the tool's student records, and chooses what to bring to the team; use anonymized student work in debriefs untested proposal; the Professional Development pattern's row on low uptake holds the coaching side
The brief wants a whole lesson taught with the tool, not separate exercises Keep the planned lesson whole in step 4 and debrief the whole lesson; do not reduce the PD to practising tool functions in isolation untested proposal
The brief reports a mistake teachers made (the tool used only to project slides, a quiz tool used with no follow-up on the results) Use it as a compared case in step 3: the same lesson with the tool as a display and with the tool doing its job, and ask teachers what students do differently in each untested proposal
No release time and no follow-up support can be offered Say so in the plan; scope the PD to one function and one lesson per teacher, and expect low use Teachers used Ecree less than intended, some lacking time to learn and integrate it [~M]

Seven of the fifteen rows cite a claim, and each says how far the claim is carried: most are single implementation or survey studies of school teachers, and none compares integration-focused with technical-only PD. The rest are untested proposals.

Observation, state and explanation

What can be observed: attendance, whether a teacher planned a lesson with the tool, whether that lesson was taught, what students did with the tool (work produced, responses recorded), how often the tool is used afterwards, and what the teacher says about it. "Has integrated the tool", "resists technology" and "lacks skills" are inferred states.

Response Plausible explanations Observation that could change the interpretation
Attends and plans, but the lesson is not taught No time; the tool failed technically in the room; the teacher was not sure enough to try it in front of a class; the lesson did not fit the scheme of work Ask what got in the way; offer a co-taught or rehearsed first lesson; check whether the tool worked on students' devices.
Tool used often, but only to display material Technical-only PD, so the teacher knows features but not the job the tool does; the job was never named; the subject examples did not match the teacher's subject Ask what the tool was for in that lesson; show one example where students act with the tool, and see whether the next lesson changes.
Use rises during support and drops after it ends Support was carrying the use; the tool's job was not one the teacher valued; new demands pushed it out Ask what replaced it; run one more cycle with a colleague rather than the coach, and check again later.
Teacher says the tool's output is poor The output is poor for that job; the teacher used it in a way the tool handles badly; a concern about students' thinking being done for them Look at the output with the teacher on a real task; try the use a colleague found worked; accept a "drop" decision if the output is poor.
High reported use, weak student work Frequency counted, not purpose; the tool is used for a goal it does not serve; students use it without the teacher seeing the results Observe a lesson and look at the tool's record of student responses against the goal named in step 1.

These rows are untested proposals. A check-in is itself support and changes what it observes; record it.

Evidence and qualifications

No claim in the wiki compares PD on integrating a tool with PD on operating it, with the tool, teachers and hours held equal. The claims below bear on parts of the relationship.

Learners, tools, dates and outcomes differ (a 1999–2000 national survey, a 2003 Chicago survey, 2018–2023 implementation studies, a 2026 interview study); do not rank them. Every outcome above is reported use, reported need or reported ability; none is observed classroom use for a stated purpose, and none is a student outcome.

The evidence by question

Further evidence, not yet read against this model

Claims found while rewriting this page that bear on it but are not part of the model above. None has been re-read against the model.

Objective and learner-valued goal

The designer's objective is usually observed use of the tool, in lessons, for a named learning goal, a term after the PD. Ask teachers separately what they want: to save time on marking, to meet a district mandate, to stop feeling behind their students, to get a struggling class working, to avoid a tool they think does students' thinking for them. Agreement and divergence are both observations. A teacher who values time savings will adopt a use that saves time and may skip one that serves the goal but costs preparation; a teacher worried about students' thinking will resist an AI use that hands the work over and may welcome one where students attempt first.

For example, a district's objective may be that every English teacher uses an automated writing-feedback tool for drafting, while a teacher wants fewer hours marking first drafts. PD that plans one drafting lesson where the tool gives first-round feedback and the teacher reads only revised drafts serves both; record whether the teacher's marking time and the students' revisions both changed, so that one is not read as the other.

What would revise this model?

The expectation should weaken if a comparison of integration-focused with technical-only PD for the same tool, with comparable teachers and observed classroom use as the outcome, shows no difference, or if the difference disappears once hours and follow-up support are equal (which would mean the ingredient is support and time, not content). It should narrow if technical walkthroughs alone produce sustained, purposeful use with tools that are simple to fit into existing lessons, which the single-tool finding hints at. It should strengthen, and move from use toward learning, if studies show integration-focused PD changing student work or outcomes on the goal the tool was meant to serve. Self-reported frequency of use should not be taken as either.

Examples

Key Sources

  • The Power of Digital Learning: Integrating Digital Content. The CEO Forum School Technology and Readiness Report, Year Three. (2000). https://eric.ed.gov/?id=ED447781
Page metadata
Field Value
type principle
id pd-integration-not-just-technical
title Professional development should guide teachers on integrating digital content and tools, not just offer technical know-how
description When a school introduces a digital tool, professional development that starts from a lesson goal in the teacher's subject, shows the tool doing that job, and has teachers plan and teach a lesson with follow-up support and time is expected to produce more purposeful classroom use than training on how the tool works alone; no claim in this wiki tests that comparison, the nearest evidence is survey associations and implementation reports, and one coach's report limits it by finding narrow step-by-step technical training necessary for uptake.
status review
canonical True
generated by claude/unspecified on 2026-10-15
trust unverified — no one has confirmed this page's content
sources 1 — the-power-of-digital-learning-integrating-digital-content-the-ceo-forum-school-technology-and-readiness-report-2000

Frontmatter is the page's machine-readable record — see the Schema & Guide.