This week’s question was “what do I bring to the table to a business partner as an e-learning designer?”
I had to put a lot of thought into this one actually. I wasn’t quite sure I have ever considered myself to be an e-learning designer. In fact, this course (OPWL 551 – Storyboard & Scenario-Based eLearning) has made me realize there is a lot I don’t know about the eLearning design world. So I have went through a little self-doubt in thinking that I can bring anything to the table as a designer.
Then I had an epiphany. I realized that most of my thought was focused on the word designer. So I looked up the definition of “designer” in the Oxford dictionary, and of course I wasn’t impressed: “a person whose job is to decide how things such as clothes, furniture, tools, etc. will look or work by making drawings, plans or patterns.”
Well, on to the next definition source then… dictionary.com provided my two nouns to help my search for meaning: 1) a person who devises or executes designs, especially one who creates forms, structures, and patterns, as for works of art or machines. 2) a schemer, intriguer, or plotter.”
That is exactly what I was looking for and it confirmed my suspicion. I had been stuck on designer because I am NOT good at the graphic design sort of things. However, when I did some deep diving I realized that a designer is not just in the art portion of the job. Literally, my job as a designer is to “scheme” and “create structures” so that someone can put some meat on the bones that I design. So with all of that long-winded explanation and some self-discovery I think I can finally answer my professor’s question this week.
I bring an innovative mindset to the table. I am comfortable with working in unfamiliar places with unfamiliar teams of people and bringing them together to support the learner in the end. My passion is teaching adults. Scenario-based eLearning is where I can bring my passion to the table to help scheme and design meaningful modules for adult learners. My design methodology is simple, if they aren’t going to be able to immediately apply the module or eLearning to their everyday job, then it is useless. If my business partners want to develop useful training for the workplace and the adult learner, then I would bring a lot to the table. If they have no idea what any of that means, then I can still bring a lot to the table in the way of opening up the perspectives of my partners.
This simple way of thinking can solve so many issues we have with workplace learning. As a designer, I would work to employ principles of adult-learning into these scenarios so that we stay on track and produce products that learners will want to participate in.
Part II of this week’s question is “what have I personally learned form creating my own eLearning ID project plan?”
That one is easy since I am just finishing my project up and submitting it today. The high-level design document was extremely easy for me as I was very familiar with what the client wanted. I ended up using a pseudo-client but a real problem so it made it very easy to adapt to that. However, that confidence in the material and the reasoning behind a scenario-based branched eLearning module did not come without its hiccups.
Overcomplicating things. I found myself trying to build multiple branches off of a single trigger event that blossomed into this tree of things that looks like a family tree that started out with 16 brothers and sisters and each one of them go married and had 16 kids each for multiple generations. So, I needed to really focus in on the decision points for my project. What was I trying to accomplish with the training? That is where I went back to “keep it simple” and “can they apply this right now?” once I was able to narrow down the options by keeping focused on those internal principles.
Storyboarding for Review Sucks. To create a detailed storyboard using the template provided seemed extremely tedious. I feel like I could have just made a draft PowerPoint file and called out what I wanted in the notes section for graphic designers and such. However, the meticulous details and having to spell everything out actually made me notice some mistakes and eventually helped me narrow down my total slide count since I could link some branch slides to others and not duplicate too much in the process.
Building a branch diagram and flow on a computer was problematic. I tried to build out my entire flowchart using LucidChart. This was probably the worst idea as I got stuck on the site itself and the intricacies of building everything out using the program. I had a really good idea on a whiteboard… I felt like I should have just taken a picture of that or just used my tablet and pen to draw all of that out on a program and bring it in. I was attempting to “make it look professional” and ended up draining a lot of my time trying to make it perfect.
Learn the company’s expectations early. I would be very dissatisfied with a company that wanted that level of detail for every idea that I was working on. It seems like I got about 12-14 hours of work into this project and that I am “pitching the idea” instead of designing the curriculum. With that in mind, I think it would be wise for me to get a better expectation of what the company needs to see for me to run with my thoughts on design and interaction… I feel like a “semi-working prototype” is much better than a words document or a pdf that says, “here is what I would like to do”. Instead, why not just give the guys a demo version that says, “here is what I started working on, we can change a lot of the characters and audio and everything else but here is how your learner will interact throughout the scenario.” With my method I feel like my client would be more impressed than having to read “some other document or proposal that day”.
The Process I Did Would Be Great For an Internal Team Document. I wholeheartedly think that the document I produced (High-level design document and Storyboard Detailed) would be better suited as an internal design document vice a client document. This would allow the internal team to have a working knowledge of what the end-state is for the training and then we can iterate at each level within the team to make it the bet possible training. In addition to that, we could also make sure that our graphics designers and coders understand where our gaps are and what needs to be developed on that end.
Overall. This was a great learning experience for me! I had a ton of fun figuring out how to make this work and then make my “small mental tweaks” along the way.
Check out my final document here:
Comments