Design

Design is the second step of the ADDIE process. In this step, the designer proposes an storyboard or instructional design concept intended to meet learning objectives, and present a high-level map of what the final product might look like. The Savvy Start plan and Storyboard below represent my initial project concept, and the shape I thought it might take early in the process.

While I did not end up undertaking the project described in my Savvy Start with my final project, I did take a lot of the feedback from my peer reviewers to heart while creating subsequent documents and high level design ideas. The practice was especially useful in thinking about how to present a concept at a high level without investing too much time and effort on ideas that were not going to be used in the final iteration.

Savvy Start

Title

Let’s Work a Case

Brief Project Summary:

This project is designed to be an e-learning activity performed in week 9 (of 18) of the Disability Adjudicator Training process. The activity presents the user with the type of background information an adjudicator would typically receive when he or she begins working a case, and then allows the user to decide the next step to take to move the case along correctly and efficiently. Choices that are correct or expeditious will be rewarded with an announcement of how many days of case processing were saved by the choice.  Choices that unnecessarily delay case processing will be penalized in the form of “total case age” days added.  With each choice, the user is presented with additional information, and asked to decide what to do with it, until the user completes the process of adjudicating a claim. While working an actual live claim can take weeks to complete, this activity allows the user to practice all of the steps required of working a claim in a single sitting, and receive feedback on their choices throughout the process.

How I used Peer Feedback

I received only one set of peer feedback on my project. However, I would say the most useful feedback I received was regarding how to present the project to managers or stakeholders. I will fully admit that I was not thinking very much about a manager or stakeholders when I was writing my description of the different slides of my prototype. I have a very clear audience in mind for the activity itself, but my concept of the audience for the description was a little more muddled—do I describe this for the peer who will be reviewing it? For the instructor of this course? Or for the actual manager who will be approving or disapproving the design?

Thanks to the peer feedback I decided to really target a specific audience with my descriptions—the supervisor, manager, and program director who will actually be approving my work on this project (which I am designing for use in my actual current workplace). As a result, the main adjustments I made to this project were in the “notes” section of the slides.

That said, this choice of a specific audience also meant I rejected some of the feedback given to me in peer review. For example, the peer reviewing the project recommended that I do not use acronyms without explaining them. However, the audience who will be using this project will find these acronyms very familiar by the time they are engaging in this e-Learning activity. Similarly, the reviewer suggested the statement “You reach him on the phone” on slide #4 is a redundancy of language, and is implied. However, for the intended audience of this project, it is actually not redundant or implied—trainees in this program will have already learned an entirely different set of steps for what to do if the claimant actually cannot be reached by phone.  Therefore, those recommendations were considered but rejected.

I am very interested in the recommendations for adding additional case scenarios, or additional levels of difficulty for this kind of decision-making activity. Ideally, I would like to create multiples of this type of scenario, with increasing degrees of difficulty. With this in mind, I added an additional page near the beginning of the activity that allows users to decide which claim they would like to work on. This additional page reflects the ultimate goal of having multiple “cases” for the adjudicator to practice on, each of increasing difficulty.

What I learned from Savvy Start:

I really like the idea of presenting a rough idea of a project, and then refining it over several iterations with feedback from invested others. One thing that made this process a little challenging for me, at this point, was that my project is designed for a very specific audience with a very specific subset of knowledge.  I appreciate the peer feedback on the project, but I felt that I would benefit more from someone who had more knowledge of the audience and needs that the activity is designed for. I also struggled to provide feedback to my peers when reviewing their projects, depending on how comfortable I felt with the topic.

I also realized that there was a lot of variation in terms of the scope of individual projects. It made me wonder if I was shooting for something big enough? Or too big? I’m still not sure.

One of the most difficult things for me was holding myself back from trying to refine and refine and refine the project—it was difficult to turn in a truly rough draft of my concept.

That said, it makes a lot of sense not to spend too much time on the details of the first draft if it is likely to be changed and refined throughout the process. There was something motivating about knowing I didn’t have to know everything, or make it “really good” in the first iteration of the project.

I do want to implement this project, or something like it, in my actual work environment. I am hoping to get feedback from some of my training team members over the next week or so, and use that feedback to refine this further.

Storyboard Iterations

Storyboard Prototype, initial

Storyboard Prototype, revised