We’ve spent the past year at Foundation developing our core curriculum. It’s a difficult process, we’ve scrapped and restarted more times than we can count, trying to make it work and find a methodology that made sense.

There’s lots of resources out there when it comes to building a curriculum within an educational setting but none seemed to fit, we’re more than just an educational body and we’re not shackled by the confines of a traditional school. Equally we’re more than just a martial arts club and so can’t restrict ourselves from that side either.

After lots of experimentation and lots of failure it turned out the right path for us lay in a methodology that’s been used in the tech industry for well over 10 years.

A quick bit of context: Before I made the leap to leading a social enterprise I worked for over 10 years in the web and design industry planning, designing and coding lots of wonderful sites and apps for some amazing agencies. A lot of theses agencies use very specific methodologies to define and identify users, what it is they need and applying this to the development process.

We’ve basically cherry-picked the useful bits from a model called Agile and used it to build a principles based curriculum that meets our needs and the needs of our service users.

If you’re reading this there’s a good chance you’re facing the same challenges so we wanted to share our approach.

Who is your (service) user?

Normally this kind of research means creating personas. These are representations of your users grouped together to give you a solid understanding of needs, goals and interests but we’re coming at this from a slightly different angle. We’re creating these user stories based on our needs and the requirements we have for our students.

This doesn’t mean that we’re ignoring users it just meant the research was much smaller and involved a few simple questions focussing on the “why”. Obviously with the vast age range of the people we engage with there were lots of variations on the wording and context but the general focus was the same.

Around 90% of respondents stuck to the same patterns that were easy to predict; building confidence, social aspects, cultural learning, language, discipline, respect etc.

This information is fantastic and all the better because it falls in line perfectly with our own goals, we still get to take our students on the journey we had planned and we can rest assured that on a broader scale we’re meeting the needs of our service users.

Whatever information you end up gathering from your service users just try to remember that the personas you create should be grounded in the now and not future focussed. It shouldn’t be based on yours or anyone else’s opinion, you’ll have to remove your bias and be as realistic as possible, this approach will help you to understand what your users need and their motivations and help reenforce the decisions you make moving forward.

Our Goals & Needs

With our service user persona research underway we recognised that we also needed to capture our business requirements. We’re not a “user” but this allows us to record the broader needs and goals we have for what we’re teaching.

This was the hardest part, countless cups of coffee, debates and discussions. It also made us realise there are changes we needed to make to the broader vision we have for the organisation as a whole. Not a small piece of work but some of the most meaningful we’ve done to date.

Define the Epic & Derive the Story

A user story is a goal and reason distilled to it’s purest form — a sentence. We started our process with the biggest possible stories, called Epics.

An epic story tends to be just that, something huge that can contain a whole host of more detailed stories within it. This was great for us as we have always had these big abstract requirements based around principles instead of techniques. These epics are the foundations (pun intended) of everything we do and will sit at the highest level. We also found that our epic stories tend to be the ones that align more with the needs defined in our service user personas too.

When we’re writing our stories (epic or not) we structure them like so:

“As a <user type>, I would like to <goal>, when/if/so <reason>”

A good example would be the epic from our kids curriculum:

“As a kids student, I would like to protect myself when I am pushed, thrown or fall over”

This looks great to us, but it’s such a broad story that contains so much detail. There’s no way we could realistically gauge success with something this big. This is why we break it down into smaller more granular user stories. An example of a user story that could sit under this epic would be:

“As a kids student, I can perform a backwards break-fall when I am pushed, thrown or fall on to my back”

This works well, it’s more granular, it’s more specific and makes perfect sense. The problem is it’s still too broad to be considered acceptance criteria, for that we go deeper.

Acceptance Criteria

So how do we judge when we’re successful. When our student has successfully completed the “user story”? We set a series of criteria, a checklist that determines if all the parameters required in our story are in place.

This can get overcomplicated very quickly so it’s important to be ruthless and only include what is required for that user story to be “accepted”.

Here are some examples of success criteria we created for the story above:

“When I fall backwards, my head doesn’t make contact with the floor”

“When I fall backwards, I hit the mat with my whole arm (finger tip to shoulder)

There are definitely more of these but the key thing here is they are all tangible, measurable and easy to validate, perfect! So now we know that when a student can tick off all of these boxes they have done everything for the user story to be accepted, which means the wider epic is now one step closer to being complete.

Win or Learn

If you are a UX expert I have do doubt you’re slowly shaking your head right now muttering about “cognitive bias” and I’m sure there are smarter people than me who could refine and improve our implementation but cherry-picking and repurposing worked for us. This methodology has helped set a vision for what we teach and how we define success.

It took lots of work, lots of failure and it’s important to remember this isn’t set in stone. We see this as a living, breathing approach that will evolve, grow and improve with each iteration.

What methodology do you use to build your curriculum? Do you engage with your service users? Get in touch, let me know and if you’re going to try and apply what we’ve done for your own organisation let us know how you get on.