Blog Post #2

Backward Design and Understanding by Design (UbD)

I think it is valuable to start planning with the end goals in mind because it keeps the learning process focused and purposeful. A time when I experienced this was when I organized a study session for my friend who was taking CSC 320. I had already completed the course with the same professor, so I knew both the content and the type of midterm questions that would be asked. With that in mind, I set the end goal of the session as making sure my friend could fully understand and work with deterministic finite automata (DFA) and nondeterministic finite automata (NFA), since those concepts were central to the exam.

Because I had this outcome in mind from the start, I created a short study plan that mapped out the key concepts, practice problems, and discussion questions we would go through. This “game plan” helped us avoid wasting time and made sure every activity was directly connected to the end goal. Here’s the document I created as a guide for the session.

I truly think now more than ever in learning design, stepping back to look at the end goal is what lets you move forward

Design Thinking

The design thinking framework emphasizes empathy, iteration, and problem solving, and I experienced this directly during my co-op as a manufacturing software application engineer at Schneider Electric. I worked closely with the production floor, where I noticed that new operators often had to train on active production lines. This sometimes caused delays in meeting meter delivery targets and created stress for the operators themselves.

Out of empathy for both the operators and the production team, I began thinking about how the training process could be improved. I learned that stakeholders were considering a new station dedicated specifically to training, so I decided to take initiative and prototype a digital solution. Using Figma, I created an early version of a training app that operators could use to practice and learn without disrupting live production. I shared this prototype and gathered feedback, which stakeholders responded to very positively.

Although this project was not part of my main responsibilities, I pursued it because I recognized the human impact behind the problem. For me, this is what design thinking is about,stepping into the shoes of others, trying out ideas quickly, and refining them with feedback. It reminded me that good design is not just about efficiency or technology, but about people.

Learning Outcomes and Bloom’s/ SOLO Taxonomies

I find the SOLO taxonomy more helpful than Bloom’s because it focuses on the depth of learning rather than just the action. Bloom’s verbs are useful, but sometimes feel like a checklist. SOLO shows how learners move from surface knowledge to deeper integration.

For example, a weak outcome might be(for the study session talked about): “Laura will understand DFAs.” But a stronger outcome would be: “Laura will be able to compare DFA and NFA models, explain their differences, and apply conversion methods to solve new problems.”

This shift matters because it makes outcomes measurable and shows growth. SOLO reminds me that learning isn’t just about what students do once, but how their responses become richer and more connected over time.

Better Learning Design

The project design made all the difference. By moving beyond memorization into actual implementation, the learning shifted from theory I could recite to knowledge I could apply. It showed me that effective learning design isn’t just about presenting content it’s about creating opportunities where students learn by doing, so the concepts become part of their problem-solving toolkit.

Inquiry and Project-Based Learning

I see project-based learning as the most natural way to connect my studies to real-world work. In my courses, the moments that stuck with me most weren’t when I was just listening to lectures, but when I had to figure things out myself. For example, in SENG 474, our MNIST classification project felt like an inquiry process: we weren’t handed step-by-step instructions. Instead, we had to explore different models, troubleshoot errors, and defend our choices. That open-ended approach pushed me to go deeper into the material than any exam could.

In my co-op at Schneider Electric, I also experienced a project-based mindset. When I noticed new operators struggling with training, I wasn’t assigned a formal task.I asked questions, empathized, and prototyped a solution. That inquiry driven approach made the work feel authentic and meaningful because I was solving a real problem for real people.