Introducing the DML Design Principles Documentation Project
- The Transcendent Potential of Digital Badges and Paradigm Shifts in Education
- Research Design Principles for Studying Learning with Digital Badges
- Ulterior Motives –Start the Interrogation!
- Initial Consequences of the DML 2012 Badges for Lifelong Learning Competition
- Some Things About Assessment that Technology is Changing
I want to introduce the DML Badges Design Principles Documentation project. This two-year project was launched at Indiana University in July 2012. The project intends to document the badge design principles that emerge from the Badges for Lifelong Learning initiative sponsored by the MacArthur Foundation’s Digital Media and Learning program. In this post, I describe our general goals and seek input on accomplishing these goals. There are specific questions at the end if you want to jump ahead.
Why Document Badge Design Principles?
The roughly 30 badge content projects funded under DML 2012 are all now underway. Teams are working hard to implement the plans in their proposals. Many are refining those plans to accommodate things they had not anticipated and are uncovering unimagined (and unimaginable) new opportunities. Some are completely revising their plans. Mozilla’s Carla Casilli explained this process in a recent post about similarities and differences in badge system design:
Regardless of where you start, it’s more than likely you’ll end up somewhere other than your intended destination. That’s okay. Systems are living things, and your badge system needs to be flexible. You must embrace a bit of chaos in its design.
This reality was highlighted by Charles Perry of awardee Mentor Mob at the recent DML Badges workshop. Charles announced that his team had finally made enough progress that they “could now start bragging about their failures.” In the closing remarks at the workshop, MacArthur’s Connie Yowell applauded awardees for taking risks and trying out new things.
Research on design rationale has shown that most of the knowledge generated when designing complex systems simply “evaporates” as features evolve and teams dissolve. Given tight deadlines and budgets, projects forget why things were done the way they were, or why a plan did not work out. This knowledge is actually quite valuable across projects and for others who might pursue similar goals. Our project aims to capture this knowledge.
Like digital badges, this is uncharted territory. The closest example I am aware of is the Design Principles Database project led by Yael Kali and Marcia Linn. Their project also captured design knowledge across multiple projects and helped share that knowledge. To do so, they distinguished between specific practices within projects and more general principles across projects. The Badges Design Principles Documentation project is organized around this distinction as well.
Our overall goal is identifying appropriate practices for using badges in particular learning contexts. This is important because the features that define contexts are what determine whether a particular practice is appropriate. This is complicated for the badges initiative because (a) the practices and contexts are mostly new, (b) the practices and contexts are evolving, and (c) the practices and contexts shape each other. Our specific goals aim to tame this complexity. With input from DML, HASTAC, Mozilla, and some of the projects, here are our specific goals at this time:
Near-term (by February 2013): We aim to document how the plans in each proposal (“intended practices”) evolved as they were put in place (“enacted practices”), and link that evolution to relevant aspects of the project contexts. So far we have summarized the intended practices in all of the proposals and have conducted one-hour interviews on enacted practices with eight of the projects. We hope to complete the interviews and have all projects review and approve our characterizations before the January workshop.
Medium-term (by June 2013):We plan to use clusters of similar practices across projects to derive “initial badge design principles” that can be exemplified with specific project features. Around DML 2013 in April, we hope that projects will be interacting with each other around the principles in mutually useful ways.
Long term (by June 2014). We hope to finish with a comprehensive database of general badge design principles. Roughly five sets of about five principles should be manageable. Each principle will be linked to more specific project practices and features. Our ultimate goal is finding the best way to share this information with projects and other badge design efforts more broadly.
We are also going to be reviewing and cataloguing the relevant research literature; I will ask about these plans in a separate blog post. One thing we are not doing on this project is evaluating projects or studying learning outcomes. But we certainly want to help projects share practices and principles for doing so!
Three doctoral students in Indiana University's Learning Sciences Program are working on this project. Elyse Buffenbarger, Rebecca Itow, and Andi Rehak. are all also HASTAC Scholars, so you can access their profiles and leave messages by following the links. They will introduce themselves in more detail in a subsequent post that describes our plans to review the relevant research literature associated with the design principles as another part of this project.
Help the DML DPD Project Help You!
All comments and suggestions are welcome and appreciated. One specific question I have concerns our initial categories of principles. As I described in a previous post, we have initially organized our search for badge design principles around four categories of badge functions:recognizing/accrediting learning, assessing learning, motivating learning, and evaluating/studying learning. I just posted several questions there and would love to get feedback and suggestions on that post.
A second question concerns the way design knowledge is shared. We are currently summarizing intended and enacted practices on a private wiki. Does it seem reasonable to ask projects to review our summaries before letting other projects see those pages? Eventually we want the “badge design principles database” to be fully open and self-sustaining. What we really want to do is leave behind a network where these principles are continually refined and spread like “memes” across the open badges ecosystem. This makes me wonder, for example, how our initial decisions about categories (described on the other post)) will impact the spread of principles across such a network. I suspect that some readers are familiar with research on creating self-sustaining interest-driven networks. I would love to get some pointers and suggestions.
We look forward to hearing from you. We would love to get feedback and suggestions here as comments. But we also hope that team members will ponder these questions and share additional insights as part of our project interviews.