Most curriculum development begins with a course. The development of the Bachelor of Arts in Learning Technology (LETE) program forced me to think differently. Before designing individual classes, I needed to understand what kind of graduates the program was intended to produce. That challenge became even more interesting because the course titles and descriptions had already been approved before I joined the project. Instead of starting with a blank slate, I inherited the rough framework of a degree and had to determine how to transform it into a coherent, industry-relevant pathway.
Building a Degree Before Building a Course
One of the most common mistakes in higher education is treating curriculum development as a course-level activity.
A faculty member designs a class. Another faculty member designs a different class. Eventually enough courses exist that they can be assembled into a degree program.
Sometimes students experience the result as a disconnected collection of classes that happen to share a catalog prefix.
When I became involved with developing the Bachelor of Arts in Learning Technology (LETE), I knew I wanted to avoid that outcome.
What made the situation particularly interesting was that the degree framework already existed. The program had been approved through the normal state processes before I became heavily involved in development. Course titles existed. Course descriptions existed. The overall skeleton of the degree had already been reviewed and accepted.
The challenge was figuring out how to turn that approved framework into a coherent educational journey.
In many ways, the problem resembled architecture more than curriculum design.
The foundation had already been poured.
Now we had to decide what kind of structure would ultimately stand on top of it.
The Graduate Before the Curriculum
The first question I asked was not what should be taught in LETE 1303 Learning Technology Tools, the first course I was tasked with developing with as part of a larger development team.
The first question was:
What should a graduate of the program be capable of doing?
The answer seemed obvious at first. Like many educational technology programs, we could focus on instructional design methodologies, learning theories, technology evaluation frameworks, and project management practices.
Those topics matter.
But after decades spent working in educational technology, online learning, academic operations, enterprise systems, and consulting, I had become increasingly convinced that something important was missing.
I had worked alongside instructional designers who understood pedagogy but struggled to communicate with technical teams.
I had worked alongside technical specialists who understood systems but had little understanding of learning.
I had worked with administrators who could manage projects but lacked a practical understanding of how digital learning environments actually function.
Again and again, I saw organizational friction emerge because professionals understood only one side of the conversation.
That observation became one of the foundational ideas behind my work in LETE, and became a core aspect of the program development cycles.
Students needed more than theory.
They needed operational fluency.
They needed enough technical literacy to understand how systems functioned and enough instructional knowledge to understand why those systems mattered.
Once that outcome became clear, curriculum decisions began to look very different.
Industry Feedback That Changed My Thinking
Around the same time, I reached out to industry contacts to ask a simple question:
If you were hiring a new instructional designer tomorrow, what would make them stand out?
One of the most influential responses came from Briana Johnson, Vice President of Partner Success at iDesign.
I expected the conversation to focus primarily on technology skills.
Instead, the conversation focused on portfolios.
More specifically, what portfolios frequently fail to show.
According to Briana and her team’s hiring discussions, the most interesting part of a candidate’s work is often missing entirely.
Anyone can display a polished final product.
What hiring managers want to understand is everything that came before it.
What problem was being solved?
What constraints existed?
What alternatives were considered?
Why were certain decisions made?
What worked?
What failed?
What would the designer do differently if given another opportunity?
That observation immediately resonated with me.
Much of the most important work in instructional design lives behind the finished deliverable. The needs analysis, wireframes, sketches, conversations, failed experiments, prototypes, and revisions often reveal far more about a designer’s capabilities than the polished product itself.
One comment in particular stuck with me:
Not all great instructional design is pretty.
Sometimes the strongest design thinking exists in a planning document, a rough draft, a workflow diagram, or a handwritten sketch.
That feedback significantly influenced the development of LETE.
We were no longer designing a program around completed artifacts.
We were designing a program around the decision-making process that creates those artifacts.
The Opportunity to Make Course Descriptions Better
As development progressed, we were given an opportunity to revise portions of the approved course descriptions before launch.
The timing could not have been better.
Because we had already begun working backwards from desired graduate outcomes, we could evaluate the curriculum as a connected system rather than a collection of individual classes.
Several opportunities immediately became apparent.
Some of the original descriptions leaned more heavily toward technical implementation and web-development-adjacent expectations. Those approaches made sense historically, but they created awkward scaffolding challenges when viewed from the perspective of the entire degree pathway.
The goal was not to produce entry-level web developers.
The goal was to produce professionals capable of designing, managing, evaluating, and improving learning experiences supported by technology.
The distinction matters.
Using the opportunity to refine the descriptions, we shifted several elements toward instructional design, learning experience development, evaluation, analysis, communication, and portfolio construction.
Almost immediately, some of the scaffolding challenges became much more natural.
Instead of forcing connections across courses, the progression began supporting itself.
The degree became more coherent because the competencies became more coherent.
Designing the Scaffold Before the Courses
Once the desired graduate profile became clearer, a second challenge emerged.
How do you prevent a degree program from feeling like a collection of unrelated courses?
My solution was to start thinking about portfolio artifacts before thinking about assignments.
Every major project needed to answer two questions:
- What competency is this teaching?
- Where does this competency appear again later?
The result was a deliberate effort to build backwards from the end of the program, and again from the desired outcomes from each course.
Portfolio artifacts would evolve over time.
Skills introduced in early courses would reappear later at greater levels of complexity.
Students would not simply complete assignments and move on.
They would gradually construct evidence of professional capability.
This approach meant the courses could not be designed independently.
Everything had to connect.
The program architecture came first.
Individual course architecture came second.
Looking Ahead
Building a degree program turned out to be very different from building a course.
The questions were larger.
The timelines were longer.
The consequences lasted longer.
More importantly, successful program development required thinking about the destination before thinking about the journey.
Once we had a clearer picture of the graduate we wanted to produce, the design of the individual courses became substantially easier.
The first of those courses was LETE 1303.
And that course would immediately test whether the program architecture we had developed on paper could survive contact with real students.
In the next installment of Curriculum in Progress, I’ll look at the development of LETE 1303 itself, why I introduced topics that some people considered unusual for an educational technology program, and what happened when students began interacting with the course for the first time.
#BuildingLETE #CurriculumDevelopment #ProgramDevelopment #InstructionalDesign #PortfolioDevelopment #EducationalTechnology #HigherEducation #AcademicLeadership #LearningTechnologies #WorkforceDevelopment
