How to make #openbadges work for you and your organisation.

A big hello to those arriving here from the Badges MOOC! You may be interested in my other blog posts about Open Badges as well as my presentations. 🙂


“Hi, I’m Doug Belshaw, Badges and Skills Lead for the Mozilla Foundation

“Oh, so you’re the guy heading up all of the badges work? I really like what I’ve seen so far.”

“Well actually my colleague Sunny Lee is Product Manager for Open Badges, and Carla Casilli is in charge of Webmaker Badges. I evangelise both badge systems in Europe and work on Mozilla’s Web Literacies framework.”

“Cool. I’ve been looking at badges for a while and was wondering how to implement them in my context.”

“I’m really glad you asked because I’m just about to write a blog post on that exact subject.”


I’ve had the above conversation with many people over the last few months. They tend to go beyond this, obviously, but I do need a post to point people towards.

So this is it. 🙂

The first thing to say is that there is no objectively-awesome way to issue badges. What works for one group of people in one context won’t necessarily work in another context. Having said that, there are some general principles which should stand you in good stead.

Second, you’ll find that it’s fairly natural for people to project their worldview into what is, after all, an open and emergent ecosystem. I’ve had people tell me that badges “will inevitably lead to X,” that “you can’t do Y with badges,” and that “Mozilla need to make sure that Z”. The great thing about the Open Badges Infrastructure (OBI) is that it’s a platform for third parties – including you – to innovate and think differently about their organisation is set up to do.

Third, there’s some criteria that are required for Open Badges and some that are optional.

The REQUIRED metadata fields are:

  • Badge Title
  • Description
  • Criteria
  • Image URL
  • Issuer
  • Issue Date
  • Recipient

The OPTIONAL metadata fields are:

  • Evidence URL
  • Expiration Date

What follows  isn’t the only way to approach badge design – my colleague Carla, for example, sometimes starts with the graphical element – but it’s an approach which has worked well for me over a series of conversations and workshops.

Here it is in the abstract, followed by a worked example:

  1. Decide on some behaviours, skills or attitudes you want to promote.
  2. Think of some criteria for a badge which would begin to promote those behaviours, skills or attitudes.
  3. Consider if the criteria for the badge you’ve come up with can be broken down in more granular ways.
  4. If (as is likely) you end up with multiple badges, think about multiple (potentially interest-based) pathways through your badge ecosystem. Ask yourself, which badges depend upon other badges? What are the relationships between these badges? (this may help structure that)
  5. Get someone to design you an awesome-looking graphical badge and use a badge issuing platform such as badg.us, ForAllBadges, WPBadger or BadgeStack to issue badges

This, of course, looks fairly easy but will take a decent amount of time from start to finish if done in a considered and collaborative way. Just to illustrate the point, my colleague Laura Hilliger and I are running a two-part, 5.5-hour workshop in Porto this week where we probably won’t manage to get the participants through all five steps in the time we have available.

Now, an example.

I’m always slightly wary about using examples as they tend to be held up as THE way to do things rather than A way to do it. With that in mind, let’s take as our example Alina who wants to start a new online community for teaching Webmaking skills. How could she use badges to promote the behaviours, skills and attitudes that she wants the community to embody?

  1. Alina wants to encourage community members to level up in their web skills. She’s seen that Mozilla have started to provide Webmaker badges for that, so she decides to use those for the skills element. She decides to focus her efforts on badges to encourage mentorship and community etiquette.
  2. New to the concept of badges, Alina thinks that one mentorship badge will be enough. The criteria she comes up with is that once a member has got enough ‘thank you’ upvotes using the forum software then they will automatically be awarded a ‘Mentorship’ badge.
  3. A couple of days later, Alina talks through her idea for a single Mentorship badge with a member of the community whom she meets at a conference. They raise concerns that such a system would promote people ‘begging’ for upvotes and/or lead to reciprocal backslapping. Alina goes back to the drawing board and begins to come up with a system of badges.
  4. Reflecting on her own experience as a member of various online communities, Alina realises that there are different forms of mentorship and ways of recognising it. She proposes several different granular badges which aggregate to a larger mentorship badge in different areas of Webmaking. Alina then invites some community members who already show the behaviours, skills and attitudes she is looking for to an virtual workshop. As a result, she tweaks the number of badges and the criteria for each badge. Some badges they decide should be emergent, all should be peer-assessed, and some should expire. They decide that the inclusion of an evidence URL showing how the member earned the badge would be useful.
  5. Alina announces the badge system to the wider community via a blog post and asks for feedback. She mentions that they haven’t yet come up with the visuals for the badges. A community member with an interest in graphical design volunteers to design the badges. Before long, the first iteration of the badge system is up-and-running using WPBadger, WordPress and BuddyPress.

I hope that helps. Badge ecosystem design is an iterative, emergent process. My main advice would be to make it an open, inclusive process involving the participants formerly known as stakeholders. 🙂

Image CC BY-NC AlbinoFlea

1 Comment

Add yours →

Leave a Reply

Your email address will not be published. Required fields are marked *

css.php
https://dougbelshaw.com/blog/2012/11/26/how-to-make-openbadges-work-for-you-and-your-organisation/
dougbelshaw.com
crawl=CC-MAIN-2019-30
53461
application/http; msgtype=response
sha1:2BB3VUONWT4GVH5KMDQWJMT23FHZ43YY
<urn:uuid:67f55bbe-116e-434f-b491-ce3b3725aa41>
2019-07-22T21:27:05Z
104.27.176.30
text/html
sha1:IDFCB3R335G2CL4NX547HXM2QECMZ5Z5
<urn:uuid:361a9209-6ee9-4b6e-8c35-bc1b8a58cb1b>
https://dougbelshaw.com/blog/2012/11/26/how-to-make-openbadges-work-for-you-and-your-organisation/
response
<urn:uuid:2259ce0c-5804-4660-a4f8-016ea84c8896>
isPartOf: CC-MAIN-2019-30
publisher: Common Crawl
description: Wide crawl of the web for July 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-146-52-92.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/