Designing a course is one thing. Designing the first course in an entirely new degree program is something else entirely. When building LETE 1303 for the Bachelor of Arts in Learning Technology program, the challenge wasn’t simply creating content. It was establishing the architectural foundation upon which every subsequent course, certificate, and student experience would depend. This first entry in the Curriculum in Progress series explores the assumptions, lessons, and design choices that shaped the program from the beginning.
Building LETE 1303: Starting with a Blank Canvas
Most curriculum conversations begin with content.
What topics will be covered?
Which textbook will be used?
What assignments should students complete?
Those questions are important, but they weren’t the first questions I asked when beginning development of LETE 1303.
The more important question was:
What kind of graduate are we trying to produce?
That question became increasingly important because LETE was being developed during a period when artificial intelligence was beginning to dramatically reshape how educational technology professionals work. Content creation was becoming easier. Building attractive deliverables was becoming easier.
Discernment was becoming more important.
The easy path would have been to create another educational technology program focused primarily on learning theories, technology selection frameworks, and management concepts.
There are already plenty of those.
What I kept returning to instead was an observation accumulated over decades of working in educational technology, instructional design, academic operations, and enterprise systems.
Many talented professionals understood pedagogy.
Many understood technology.
Far fewer understood what actually happened when those two worlds collided.
The Problem I Was Trying to Solve
Throughout my career, I have repeatedly encountered a frustrating disconnect.
Instructional designers often rely heavily on systems they do not fully understand.
Meanwhile, technical staff are frequently asked to support educational workflows they have never experienced as instructors or designers.
The result is predictable.
Miscommunication.
Dependency.
Delays.
Missed opportunities.
Over time, I came to believe that many educational technology professionals would benefit tremendously from becoming just a little more technically fluent.
Not programmers.
Not system administrators.
Not web developers.
Fluent.
They should understand enough HTML to diagnose a formatting issue.
Enough accessibility principles to recognize a compliance problem.
Enough LMS architecture to understand how content actually moves through a system.
Enough troubleshooting methodology to write an effective support request.
In short, they should be able to speak both languages.
LETE 1303 became my opportunity to build a course around that philosophy.
Operational Fluency Instead of Tool Training
One of the earliest design decisions was that the course would not focus primarily on software.
Software changes too quickly.
Products appear and disappear.
Interfaces evolve.
Companies merge, rebrand, or get acquired.
If curriculum becomes overly attached to specific tools, it ages rapidly.
Instead, I wanted students to develop what I often describe as operational fluency.
The ability to examine a problem.
The ability to ask good questions.
The ability to troubleshoot systematically.
The ability to communicate effectively with both technical and non-technical stakeholders.
These skills outlive software.
As a result, many course activities were designed less like traditional academic assignments and more like real workplace situations.
Students had to write professional support tickets.
Students had to document technical problems.
Students had to explain system failures clearly enough that another person could reproduce them.
Students had to identify root causes rather than merely describe symptoms.
[Insert example of a support-ticket assignment and discuss common mistakes students made during the first submission.]
What interested me was not whether students could memorize terminology.
What interested me was whether they could communicate problems effectively enough for someone else to solve them.
That skill travels.
Looking Under the Hood
Perhaps the most unusual decision involved introducing HTML and CSS concepts early in the program.
This occasionally surprises people.
After all, LETE is not a computer science degree.
But I wasn’t interested in teaching web development.
I was interested in teaching literacy.
Modern educational technology professionals work inside systems built on technologies they rarely see.
Understanding basic markup gives students a way to see beneath the interface.
Suddenly, a formatting problem is no longer mysterious.
Accessibility issues become easier to diagnose.
System limitations become easier to recognize.
Technology begins to feel understandable rather than magical.
Good instructional design requires understanding how learning experiences are delivered.
Sometimes that means looking under the hood.
[Insert real-world example from your career where understanding basic HTML or CSS significantly reduced troubleshooting time or improved communication with a technical team.]
Building Backward from the Portfolio
Another major influence on the program came from a conversation I had while seeking feedback from instructional design leaders on what new graduates most often lacked.
One particularly insightful response came from Briana Johnson at iDesign.
When I asked what instructional design graduates needed in order to stand out professionally, the answer wasn’t a particular software package.
It wasn’t Storyline.
It wasn’t Captivate.
It wasn’t AI.
It was the ability to explain their work.
Hiring managers routinely see polished deliverables.
What they rarely see is the reasoning behind them.
Why was a particular activity selected?
What constraints shaped the solution?
What alternatives were considered?
What would the designer do differently today?
As Briana observed, the portfolio pieces that stand out are often those that reveal the process behind the product. A rough prototype, a needs-analysis document, a wireframe sketch, or a design rationale can reveal more about a designer’s abilities than a polished artifact alone.
That observation immediately resonated with me.
The program should not simply help students create portfolio pieces.
It should help students create portfolio stories.
As a result, LETE 1303 was designed around the idea that students would build artifacts while simultaneously documenting the thinking behind those artifacts.
[Insert specific excerpts or additional observations from Briana’s email that most influenced your design decisions.]
Designing Across a Program, Not Just a Course
One mistake I have seen repeatedly in higher education is treating each course like an isolated island.
Courses become collections of activities rather than parts of a larger journey.
I wanted to avoid that from the beginning.
While building LETE 1303, I was already thinking about future courses.
Assignments were designed to become portfolio artifacts.
Portfolio artifacts were designed to support later coursework.
Skills introduced in one course were intentionally positioned to reappear later in more complex forms.
Students were not simply completing assignments.
They were laying foundations.
This required building backwards.
Every major project had to answer a simple question:
What future capability does this support?
The resulting architecture may not be immediately visible to students.
That is okay.
Good scaffolding rarely draws attention to itself.
What I Hope Students Leave With
The longer I work in educational technology, the more convinced I become that tools matter less than judgment.
AI can generate content.
Templates can accelerate production.
Software can automate many tasks.
But none of those things eliminate the need for discernment.
Students entering the profession need to understand not only how to build something, but how to evaluate whether it should be built, whether it works, and how to explain its value to others.
That was ultimately the goal of LETE 1303.
Not teaching software.
Not teaching code.
Not teaching theory in isolation.
Teaching students how to think about systems.
Looking Ahead
Now that the first cohort has completed its initial journey through LETE 1303, the real work begins.
No amount of planning reveals as much as actual students interacting with a course.
Some assumptions proved correct.
Others did not.
Student questions exposed gaps.
Assignments revealed friction points.
And several design choices changed almost immediately.
The next entry in the Curriculum in Progress series explores those discoveries and how teaching LETE 1303 began reshaping the development of LETE 2301 before that course was even finished.
#BuildingLETE #CurriculumDevelopment #InstructionalDesign #LearningTechnologies #CourseDesign #AI #PortfolioDevelopment #EducationalTechnology #HigherEducation
