| Element | What it is | Where it comes from |
|---|---|---|
| Perceived Usefulness (PU) | The degree to which a person believes using a given system would enhance their job or task performance | Davis (1989), MIS Quarterly |
| Perceived Ease of Use (PEOU) | The degree to which a person believes using a given system would be free of effort | Davis (1989), MIS Quarterly |
| Behavioral Intention (BI) | The user’s intention to adopt the system, shaped by attitude toward using it | Original TAM path model |
| Actual System Use | The end-point outcome variable — whether adoption actually occurred | Original TAM path model |
| TAM2 extensions | Adds social influence (subjective norm, voluntariness, image) and cognitive instrumental processes (job relevance, output quality, result demonstrability) | Venkatesh & Davis (2000) |
| UTAUT | Integrates TAM with competing acceptance models into a unified framework | Venkatesh et al. (2003) |
What TAM actually claims, in plain terms
The Technology Acceptance Model, introduced by Fred Davis in a 1989 MIS Quarterly paper, argues that two beliefs — perceived usefulness and perceived ease of use — largely determine whether a person forms the intention to use a new system, which in turn predicts whether they actually use it. Davis defined perceived usefulness as the degree to which someone believes a system would enhance their job performance, and perceived ease of use as the degree to which they believe using it would be free of effort. The model is an extension of Ajzen and Fishbein’s Theory of Reasoned Action, adapted specifically for information systems adoption rather than behaviour in general — which is exactly why it fits a computer science thesis studying whether users adopt a piece of software, a platform or a new interface, rather than a thesis about behaviour with no technology component.
Why TAM is a good fit for certain computer science theses, and a poor fit for others
TAM belongs in a thesis whose central question is genuinely about adoption: will people actually use the system you built or are evaluating, and why or why not? It is the wrong theoretical framework for a thesis whose real contribution is a novel algorithm, a performance benchmark, or a systems-architecture innovation with no human-adoption question attached — forcing TAM onto a purely technical contribution paper reads as a box-ticking exercise rather than a genuine theoretical grounding. If your thesis includes a user study, a pilot deployment, or a comparison of adoption between two interface designs, TAM gives you a validated, well-cited lens for that specific piece of the work, even if the rest of the thesis is technical.
How TAM has evolved, and which version to use
The original two-construct model (Davis, 1989) is the right choice for a focused, tightly scoped thesis that wants a simple, well-established measurement instrument without adding complexity your sample size cannot support. TAM2, introduced by Venkatesh and Davis in 2000, extends the model with social-influence factors such as subjective norm, voluntariness and image, plus cognitive instrumental factors such as job relevance, output quality and result demonstrability — appropriate if your adoption question specifically involves workplace or organizational context, where social pressure from colleagues or supervisors plausibly shapes adoption. UTAUT (Venkatesh et al., 2003) integrates TAM with several competing acceptance models into one unified framework that outperformed each individual model in its original validation, but it also requires measuring more constructs, which means a larger sample and a longer questionnaire — a real cost for a thesis with a modest participant pool. Match the model’s complexity to what your sample size and timeline can actually support, not to which version sounds most sophisticated in your literature review.
Operationalizing PU and PEOU: what your instrument actually needs
Davis’s original measurement scales for perceived usefulness and perceived ease of use have been replicated many times: Adams, Nelson and Todd (1992, MIS Quarterly) used two different samples to demonstrate the internal consistency and replication reliability of the two scales, and later work by Hendrickson and colleagues reported good test-retest reliability. That validated item structure is still the standard starting point rather than writing your own items from scratch. Each construct is measured with several Likert-scale items asking participants to rate agreement with statements such as “using this system would improve my performance” (PU) or “learning to use this system would be easy for me” (PEOU) — adapt the wording to your specific system, but keep the underlying construct definitions exactly as Davis defined them, rather than drifting toward a colloquial sense of “useful” or “easy” that no longer measures what the validated instrument measures. Pilot your adapted items with a handful of participants outside your main sample before full data collection — a wording change that seems trivial to you can shift what a construct is actually measuring, and a small pilot catches this cheaply, before it costs you a full data-collection round.
Analyzing your data: what a TAM study actually reports
Many TAM studies use structural equation modelling (SEM) to test the hypothesized paths — does perceived ease of use predict perceived usefulness, do both predict behavioral intention, and does intention predict actual use — because SEM lets you evaluate the whole measurement model and the whole structural model together, including whether your items genuinely load onto the constructs they are supposed to measure. If your sample size is too small for SEM (a common constraint in a thesis-scale study), a simpler regression-based approach testing the same paths individually is a defensible, clearly-labelled simplification, as long as you state explicitly that you are not testing the full model simultaneously and explain what that limits you from claiming.
Known critiques of TAM your literature review should acknowledge
A thesis that presents TAM as an uncontested gold standard invites exactly the kind of examiner pushback that a more candid framing avoids. TAM’s critics have long pointed out that “actual use” is often measured through self-report rather than genuine behavioural logging, which weakens the model’s core predictive claim; that the model leaves a large share of variance in actual system use unexplained; and that it says relatively little about the post-adoption period — whether a user keeps using the system, becomes a power user, or abandons it after the initial trial. Acknowledging these limitations explicitly, and stating how your own study design does or does not address them (for instance, by measuring actual use through server logs rather than self-report, if your system allows it), reads as methodological maturity rather than as undermining your own framework choice.
A worked example of framing a TAM chapter
Illustrative, fictional example: a thesis evaluating adoption of a new internal code-review tool among a university’s computer science teaching-assistant team. The theoretical-framework chapter would define PU and PEOU using Davis’s original definitions, state that the study uses the original two-construct TAM rather than TAM2 or UTAUT because the sample (a single TA cohort) is too small to support the additional constructs those extensions require, present the adapted Likert items alongside Davis’s original wording for transparency, and state the analysis plan (regression-based path testing, given the sample-size constraint) before any results are reported. Every choice — which version of TAM, which items, which analysis — is justified against the study’s actual constraints rather than assumed.
How this connects to other work on this site
TAM is a theoretical framework choice, not a structural or tooling choice — if you still need to settle how your thesis is organized chapter by chapter, the standard chapters of a Canadian computer science thesis covers that separately, and if you’re choosing the practical tools you’ll build and write the thesis with, the tech-stack comparison for a computer science thesis is the companion piece for that decision. And if your thesis is closer to a full worked specimen than a single-framework question, an annotated data science thesis walkthrough from title to conclusion shows how a theoretical framework like TAM would sit inside a complete thesis structure. The same discipline of matching a framework or a data source to what your access and resources can actually support — rather than to what sounds most sophisticated — is also the core lesson of how an occupational therapy thesis ranks its evidence sources, worth reading for the method even outside computing.
Where Tesify fits
Deciding which version of TAM fits your sample size, adapting the validated items to your specific system, and writing the justification for those choices is exactly the kind of methodology-chapter work Tesify helps you draft and structure in your own words, from your own study design. See how it works at app.tesify.app.
Frequently asked questions
What is the Technology Acceptance Model?
A model introduced by Fred Davis in a 1989 MIS Quarterly paper arguing that perceived usefulness and perceived ease of use largely determine a person’s intention to use a new system, which predicts actual use.
When should I use TAM in a computer science thesis?
When your thesis has a genuine adoption question — will people use the system you built or evaluated, and why — not when your core contribution is a purely technical algorithm or architecture with no human-adoption component.
Should I use the original TAM, TAM2, or UTAUT?
Match the model’s complexity to your sample size and timeline: the original two-construct TAM for a focused, smaller study; TAM2 if workplace social influence is central to your question; UTAUT only if you can support measuring its additional constructs with a larger sample.
Where do the PU and PEOU survey items come from?
Davis’s original scales are the standard starting point; Adams, Nelson and Todd (1992) replicated them and demonstrated their internal consistency and replication reliability. Adapt the wording to your system but keep the underlying construct definitions intact.
Do I need structural equation modelling to use TAM?
Many TAM studies use SEM to test the full model, but a smaller thesis-scale sample can use a simpler regression-based approach instead, as long as you state explicitly that you are not testing the full model simultaneously.
Can I use TAM if my thesis is mostly a technical contribution?
Only if a genuine adoption question — a user study, a pilot deployment, an interface comparison — is actually part of the thesis. Forcing TAM onto a purely technical paper with no adoption question reads as an unjustified theoretical add-on.
What are the main criticisms of TAM I should acknowledge?
That “actual use” is often self-reported rather than behaviourally logged, that the model leaves much of actual-use variance unexplained, and that it says little about post-adoption behaviour like sustained use or abandonment. Acknowledge these explicitly rather than presenting TAM as uncontested.
Should I pilot my adapted PU/PEOU items before full data collection?
Yes. A small pilot with participants outside your main sample catches wording problems cheaply, before a change that seemed trivial ends up shifting what a construct is actually measuring across your whole dataset.
How many items does a typical PU or PEOU scale use?
Several Likert-scale items per construct, taken from Davis’s original validated scales and adapted in wording rather than written from scratch; report the exact items you used in an appendix.
Can Tesify help me justify which version of TAM fits my study?
Tesify helps you draft and structure your methodology chapter’s justification for your theoretical framework choice, in your own words, based on your own sample size and study design.