Back to the Drawing Board: When Design Fails

Although a considerable amount of instructional design planning and testing goes into the instruction we provide in the library, not everything goes according to plan. Occasionally we find ourselves having to rework or refine a lesson, activity, or learning object. One recent example of this relates to a library scavenger hunt activity that introduces new freshman and transfer students to the library’s spaces, services, and resources. The activity is in its third year and recently we made a slight change that had unintended consequences for our Information Desk. One of the first stops on the scavenger hunt requires students to locate the Information Desk and input into their mobile devices the activity code they find there. Originally the sign at the desk was temporary and printed on neon paper that looked like Image 1 below. Due to the success of the activity, we moved to permanent signage and in that process we changed the sign to look like Image 2.

blogimage

The first quarter of the signage change, we noticed that the Information Desk staff put a sticky note on the sign with an arrow that pointed to “help”. The Information Desk was being inundated by students asking for the activity code. This confusion took up staff time and negatively impacted the desk workflow. It was clear to us that the issue was associated to the new sign as we didn’t experience this issue in previous quarters. Our first solution assumed a user issue and we checked the activity instructions for clarity of language. In doing so we changed the instruction language to refer to “activity code” instead of “validation code.” The next quarter, the sticky note was back. Although we had clarified language in the instructions activity for the user, the sign design was still problematic. It was then that we determined that the new sign conveyed to students “come her for activity help” as opposed to “the activity code is help”.Clearly this was a sign design flaw as opposed to a user issue. We then decided to change the code from “Help” to “Desk”, a word that had no assistive meaning assigned to it.

It may be difficult at times for a developer to look critically at the work they have done but it is a necessary part of evaluation. It is all too easy to assign fault based on how others behave as opposed to the design of a lesson or object itself. This experience is a reminder to us that in many cases when something is not working the way it is intended, the issue at hand is most likely a design issue and not a user issue.

Advertisements

Kirkpatrick Model Level 1: Does your instruction get two thumbs up?

by Dominique Turnbow

In this post, we’ll explore Level 1 of the Kirkpatrick Model. In the previous post, I introduced the model and pyramid I’ll be referring to throughout this series. While this model was not developed specifically for information literacy instruction, it is applicable to the work that we do as instruction librarians.

Continue reading