Friday, May 18, 2012

The Three T’s of Badge System Design

We’ve been working on the Mozilla Webmaker badge system, or at least initial alpha badges for the Summer Campaign and it’s tough! We knew that going in - if it were too easy, then we probably wouldn’t end up with very valuable or robust badges - but that didn’t make it easier. There are many things to consider and it’s very easy to get caught up and stuck in the core question of what badges?  That’s a really loaded question because its not just about what to call the badges - which is a rabbit hole of itself altogether - but its also considerations around specific skills, levels and granularity (which is a huge/tough one), assessment, experience, etc. We spent days trying to answer the what badges question - should we have an HTML Level 1 and Level 2 badge, or just an HTML badge (and what do those mean?)?; should we call them Ninjas or Samurais (note: we decided on neither)?, is there a Webmaker badge that everything aggregates up to and if so what are the badges that make that up?; are all badges the same granularity?, etc. The decisions at this level are also things that more people care about and have to sign off on so that also slows down the process.

I’ve since stepped back and looked at the process and realized that there were a few considerations that actually helped us move forward - and that those considerations were one or more steps removed from the badges themselves. I’m now calling this my 3 T’s of badge system design, and so far its proving to be a helpful place to start or at least move back to when you feel you getting buried in badge level decisions. 

3 T’s of Badge System Design:

(1) Types - general categories of badges. Do you have skill badges or participation badges? Progress badges or achievement badges? To do this, you need a general understanding of the learning experiences, the community and most importantly, the goals of the badge system, but you don’t have to go super deep. You don’t, for example, need to know the exact set of skills that you want to badge. And you definitely don’t need to finalize the badge names ;). You just need to decide if you are badging skills or actions or achievements or progress, etc. Finalizing and putting some lightweight descriptions around your types of badges can really help you scope the system before diving into the questions around the specific badges that fall into each.   

Our alpha badge TYPES*:

Skill badges - I developed this skill

Participation badges - I attended or hosted this event

Achievement badges - I made this

(2) Touchpoints - next you do Touchpoints or general description of how someone will earn the TYPE of badge. This starts to pull in assessment and criteria but again, you don’t have to go super deep at first. 

Our alpha badge TOUCHPOINTS*:

Skill badges will be based on work that the learner submits, assessed by peers against a rubric. (note: this is probably even more specific than you need to go at first)

Participation badges will be based on registration for an event and proof of attendance.

Achievement badges will be based on work that the learner shares with the community.

It’s a good practice to think through if there are several possible touchpoints for each badge type (and the pros/cons of each approach). Thinking through this at the outset gives you more flexibility going into the technology considerations and helps you better work with any technology constraints you might have. For example, back up touchpoints for our badges might be:

Skill badges will be issued when the learner completes a learning challenge that cover the skills.

Participation badges will be issued by the host of an event directly to attendees.

Achievement badges will be based on completion of making exercises/projects.

(3) Technology - finally, you translate the touchpoints into high level technology requirements. 

For the first set of touchpoints, our TECHNOLOGY requirements might look something like the following:

Badges integrated into the learning tool environment and the events site

A Gallery component that learners can submit work to with a voting or rating capability for skill/achievement badges

These can be more granular but don’t have to be at this point. Just think through the basic requirements and see where you net out. It may immediately become clear that something won’t fly and you can start to work around it right away instead of way later in the process. Going back to our example, maybe we would find out that we weren’t able to have a gallery component and if this is the case, we could go back to our touchpoints and decide to use another option for those types of badges and tie those badges to the learning exercises, and thus the learning tool, instead. That decision would most likely change elements about the assessments and the specific badges we ended up defining as well, so the information flow works both ways.

What you end up with is a general map of your badge system and a basic roadmap for what needs to be built to support the badge issuing. It could also help you evaluate existing badge issuing platforms to see if they have the features that meet your needs. 

Next steps are to start to dive into each piece a bit more. Define a few of your skill badges and work through the work flow again - what is the specific touchpoint (rubric, rating required, etc.) and what are the specific features needed to support that. Press repeat, press repeat. 

Again, this is the model that we’ve accidentally started to use with our badge system design. It’s not rigorously tested by any means, just seemed to work well for our first few iterations. Would love to hear back from folks on if this is helpful, where it breaks down, etc.


*Note: our alpha badges are still in alpha so are subject to change