Monthly Archives: May 2015

Prompt: Reflect on the outcome of Project B. What worked? What did not? Why? Did you use your peer for feedback? If so, discuss the feedback your peer provided; if not, explain why? Discuss your client’s feedback. What did you use? What did you reject? Why?

I made it through to the end! This was my first instructional design course and so my first true experiences with instructional design. For my Project B, my client needed me to create a new employee manual for the position of Reference & Instructional Services Librarian. As this position is new, no manual exists for it. To further add to the challenge, instead of using a paper-based manual, which is the same format as our old, existing manuals, he wanted me to create an electronic one.

I have to admit that this project was very challenging for me. Not only did I have to start from scratch but also I had to research possibilities for a secure electronic format. One of the options that we considered was LiveBinders but since the default for the free version is public, that would not work for us. In the end (and many thanks to my professor), we decided to create a Google Site. We chose this as you could make sites private as well as add and remove users from the site. Once this decision was approved, I moved onto the content. Once I actually started adding items, the creation process flowed well.

I used an existing template provided by Google Sites and just modified it to meet our needs. I used a left-hand menu to organize the overall content and added a table of contents box that appears on the right side of each page to further help with organization. I added some pictures to personalize the main page and used a ton of screenshots to help with explanations. I think the end result looks awesome! When I previewed it with my colleagues, they all loved it and thought it looked great. My hope is that my supervisor (who has been on vacation) will approve as well and we can transition the old manuals to this format.

A couple of snafus occurred during the creation process. One is that when I first set up the site, it took me awhile to figure out if Google Accounts could be created without a Gmail account. We wanted our staff to use their SMU emails to log into the site. After some intense searching, I found that yes it is possible. I was so relieved as I was afraid that the entire project would have to be scrapped. Next, I set about creating the instructions on how to do so using a non-Google email. Well, my original instructions were wrong. Instead of teaching them how to create a Google Account using their SMU email address, my instructions showed them how to create a Gmail account. That was a disaster. Luckily, this occurred during the beta test and not the implementation phase. As a further complication, I did not account for users who were already logged into their Gmail accounts when viewing documents within the site. This caused some issues with not being able to access the documents. After adjusting the instructions to account for all these technical issues, the issues were resolved successfully and repeats should not occur.

As the Google Site is private, my peer reviewers could not access it but they were able to review my design document, job aid, and implementation and evaluation report. My peer reviewers did not have many suggestions for me when it came to improving my documents but did like the flow and organization of them. It was gratifying after all the effort I had put into this project. One of my peer reviewers suggested that in my job aid, I explain who a person was so that the learner would understand why the name was being used in the document. I had not thought to do this, as I did not think the name mattered but from an outside perspective, I can see why it actually does.

My client also did not provide a lot of input into this project as well. I think this is because he is super busy with own job duties and has very little free time. He did review everything I gave him and one big change he had me make was that for the assessment he wanted a perfect score. I originally had made it so that the learner could achieve a four out of five possible points but he wanted it to be all or nothing. As he put it, this is a learning experience and they need to perform every task successfully.

I did ask two of my colleagues for their input on the job aid as well as the look and functionality of the Google Site and that really helped. They found some grammatical errors as well as the larger account creation mess. One of them suggested that I take the time to explain why the learner should log out of the personal Google Account before accessing the site. I had not thought of explaining why but doing so helped make the job aid more useful.

During the process, it was the little things, such as explaining names and providing justifications, that I tended to overlook. Having multiple eyes outside of my client and myself really helped to solidify the design and to make it shine. I am very proud of what I have accomplished during this semester with both of my projects. I look forward to getting more hands-on practice with instructional design.

Prompt 1: Think about instructional design in general. What have you learned this semester about instructional design and development? What about process? What else?

I think that the biggest takeaway that I have learned about instructional design and development is that it takes a lot of work. At the beginning of his book, Piskurich (2006, p. 1) states, “There is an old saying that if you don’t know where you are going, any road will get you there.” Well, thanks to Projects A & B in this course, I have learned that when it comes to instructional design and development it is much, much better to have a destination in mind. Even when employing some of the shortcuts that Piskurich (2006) helpfully supplies as templates in our textbook, it still takes planning and forethought before undertaking any development. By the way, I found this textbook so helpful I plan to buy the updated version so I can continue to reference it over the years. That says a lot about how helpful the book really is.

Regarding the process, I discovered that instructional design requires not only the willingness to plan but also the dedication to see your plan through to the end, and along the way, the ability to accept constructive criticism. During the process of designing and developing both my projects, I had to keep reminding myself that the product is not static and it is not personal. As I put a lot of work into all of the ADDIE phases – analysis, design, development, implementation & evaluation – I grew attached to my products. When something did not work right, or either the client or the learner wanted something changed, it was difficult for me not to take it personally. My first thought/instinct was “No, I like it the way it is.” However, I quickly came to the realization that my thinking was ineffective for an instructional designer. That is something that I will need to continue working on, as I know that nothing is perfect, change is inevitable, and outside feedback makes for a better result.

Surprisingly, although I imagine I should take this an indication that this is the right degree/program for me, I really enjoyed doing all the work. I will admit that I found it extremely daunting and overwhelming at the beginning of each project, but once I started asking the right questions to determine my client’s true needs, it made the development process much smoother. With Project B, the development process was much more forbidding as I started with nothing. At the end now, looking back on it, I am very proud of what I accomplished. Yes, I do realize that it is not set in stone and will change.

Prompt 2: Also, what did you learn from the Evaluation of the product? What would you do differently next time? How much did you learn from the process and evaluation that will make you a better future instructional designer?

From the evaluation phase, I learned that it is easy to skip over steps that seem intuitive to the designer. When it comes to designing job aids, it is safer to err on the side of too much information than not enough. With Project B, I assumed that my learner either would use a browser other than Chrome to view the manual or would not sign into their personal account. I was wrong. When she tried to create a new account and to view documents in the online manual using Chrome, which she was already signed into, it caused major issues. Google kept defaulting to her personal Gmail account. Because there were no employee manual documents saved on her personal Google Drive, it kept giving her an error message saying nothing was available to view. I am sure this caused her unneeded frustration. To stop this from reoccurring, I added instructions about using a different browser or not signing into a personal account. From this experience, I learned why it is important not to assume as well as why I should spell out the details.

For future designs, I would like to always schedule smaller beta tests and then the larger full-scale implementations. With Project A, it fell during our spring break, so I only had limited staff available to implement. I think I would have received additional, helpful feedback using a larger audience. With Project B, while I only used one person for the full-scale implementation, I did use additional staff, three people, for a smaller beta test. The beta testers discovered a big bug. The instructions I had originally written for the Google account creation process were wrong. Had I not tested them before full-scale implementation, the design would have failed!

Overall, I learned that setbacks are inevitable but nothing is as surmountable as it may seem at the time. In most cases, all it takes is some additional thought and effort along with some time away from the project. When you come back and look at it with fresh eyes and a clear head, often times the answers are waiting for you.