Nowdays learning experiences encapsulate tracking of learners events. It evolved recently into a semantic based standard. Using semantic enabled tracking technology to get a sense of how learning took place is not simple. Let’s see why and also how we could do it better. With semantic enabled tracking, we are now in charge of defining what we measure. We must explicit why we expect those events to inform us on how the learning experience took place. We explore here if it is it possible to learn how to design this tracking part from the use of “user stories” in application development or “buyer legends” in marketing. I tried to keep the post short and easy to invite comments. Whether you agree or disagree, feel free to comment. Disclosure: I have little background in L&D or learning design. I became familiar with some concepts due to my work in self-directed learning and personal knowledge management. For the last 2 years, I have been a regular of chats and blogs on learning. L&D and IDs are in my selected target market segment, yet another motivation to listen to their concerns. I participated to an xAPI cohort in 2013 and I was invited to join the new workgroup on vocabularies. I have a limited track record in this field but Ihave other strengths. I’m not bound to any school of thought and I’m multidisciplinary with proven experience in marketing, business and software development. I wrote this piece because I felt I could bring a new idea.

The “let’s stick to facts” bias

Before, only results to tests where kept. While we can contest the validity of such tests to evaluate that learning took place, they have the benefit to exist and to be no brainers from tracking point of view. With the new possibilities learning designers may be tempted to make it simple and stick to very basic verbs (and the corresponding statements) because they reflect events available in their tools. Started the video, stopped the video, clicked here, clicked there. Like for above tests the big benefit is that there is no discussion whether the event took place or not: it did. Imagine the learning experience being deployed at large scale. What will end up in the recording store is “clicked”, “completed” reused across experiences coming from various designers following diverse design trends. Most of the actual meaning in term of learning experience will be lost because: - All click are equals and will be aggregated independently of where they took place. - Contexts will be so variate and undocumented that it will be difficult to draw any conclusions from them. What will eventually be measured is how long the learner took to complete a sequence, how many times did she interrupt the video. Shallow conclusions will be drawn like learners have a low attention span, videos do well, learning on mobile is a win. Gaining feedbacks on how well  the experience was accepted, how well formal and informal experiences combine will be nearly impossible. It’s possible to do much better.

Experience is encompassing all dimensions, yet we can only measure some

A learner in a learning experience is the story a human over a period of time. A human has a context: what did he take for breakfast, what happened yesterday, her motivation, what do they have in mind. He has also emotions, values, belief etc. A learning experience designer is targetting an audience. On this audience, it is expected that a succession of actions will eventually lead to some learning to take place. - When this learning takes place exactly in the imagination of the designer? Why not documenting it? - How well plausible persons fit into the audience? - How personal stories fit into the learning funnel? Where are motivations, emotions taken into account? - How to communicate this design before it’s actually done? - What could be measured, where probes can be placed to track some behaviors? - How to correlate measures of facts with expected effects more meaningfully. And finally, how to capture this part of the design in a form understandable outside of L&D, durable, shareable. Narratives convey all that and are already used in other fields.

Narratives in Marketing

In Marketing, we design personas. personas are archetypes of actual persons in segments of the target audience. Depending on the size of the project, there could be several personas. personas have demographic characteristics but also a name, a personality, and even a personal story. All such elements are taken from real users, from interviews and recombined to form a plausible story. A step further is to observe and compile Buyers Legends. The persona becomes the hero of a short story showing how she went from desiring a book to eventually reading it, sharing it with her friends, recommending it, lending it. A legend covers the whole cycle of the sale process. In a subsequent design stage, the story is used to design the funnel. Name the stages, what are the possible interactions with the buyer, his iterations. The overall goal is to optimize the experience so that a maximum of buyers move from buckets to buckets eventually completing a sale, becoming repeated customers or even promoters. You surely experienced it yourself but maybe never suspected how much design thinking was done behind.

Narratives in Software development

User stories have been brought to us by the Extreme programming group. The same guys who invented the Wiki (which ended up being used for Wikipedia). Similar ideas have been reused in Scrum and user-centric design methodologies. “A user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.” — Wikipedia. from http://en.wikipedia.org/wiki/User\_story What is especially interesting is how discussions are engaged over user stories. It’s common to share them as we share code and reference them directly in the code. The code becomes very concrete yet factorable. Later stories made their way to tests. Tests recently became the driver of software development in TDD. Stories, being embedded in tests, eventually lead coding all along. User stories and use cases are slightly different in the level of detail. Different methodologies exist. Originally user stories are very short. As User Experience became a major part of software development, the shift was made to more detailed use cases and eventually personas stories. For learning experiences, we also need to encapsulate emotional, motivational details because it impacts how learners learn.

Narratives of Learning experiences

We know the power of storytelling in learning and communicating. We also know how fiction writing frees imagination and are the perfect place to express all kind of feelings and emotions. One can be concerned to design using everyday language. At the very end of the design work, we will be forced to using JSON records, IRL, RDF. We have more risks of losing understanding and meaning at the beginning than being left with vague sentences. A learning experience narratives can be written for any kind of learning: Formal, social, informal whatever. Almost everything humans can think and live can be narrated. this wouldn’t be true with some formalized process.

Writing process

We start by defining stakeholders. Learners are just a special case of stakeholders. A group of personas could be formed. I see no problem in reusing personas in different stories. Stories are told. A simple blog post could do the trick. What is important is to cover the complete cycle. How did this person select the course, join it, complete it. Imagine a context even if it is completely fictional. Having a full context helps to see what could variate and impact the experience. Is she stressed because of heavy traffic? Did he hesitate because he is not comfortable using a device in public transportation? The story becomes much more systematic when we reach the development of the learning arc itself. Occasionally it will become a step by step description of what takes places. The writing will be an iterative process because levels of detail may be needed later to support further connections. Using a good HTML editor or a tool like Kneaver, it is possible to work on an outline and gradually add paragraphs of details while keeping the possibility to display the outline again.

What should we find in the narrative

- A description of the experience in everyday words. A good rule of thumb is that it should be readable by the learner himself. - Causal elements. Why learner does this or that, based on his context or preliminary events. - What the designer expects to be understood, learned and when. Of course, learning is a continuous process but there are stages where we expect one thing or another to be climbing the learning ladder from awareness to known. - Enough supporting details to make the story plausible and pleasant to read. - Avoid the temptation to formalize it or turn it into a process definition with optional paths. The learner as a name and his story is defined. So we shouldn’t find sentences like “The learner could either click here or there”. Instead, we should have sentences like “Mark clicked “Yes”, started the video and watched it for 3’ until his phone rang ..” - Subject matter elements, design, look & feel can be suggested by descriptions. It is not a course design but a learning experience design. It’s more generic.

First uses of the narrative

A great benefit of narratives is that they are almost universally shareable. Instead of building a prototype or a well formalize project we could just submit the narrative as is to actual learners or people who know them well. Narratives play well with the design thinking process. The narratives come after ideation. Personas opinions, feelings are inspired by empathy interviews. Sharing narratives with learners is a way to collect very early feedback in the same vein as “pretotypes”.

From narratives to use cases

Pro Tip: We will introduce the formal elements of the use case as code blocks inside the narrative. It’s a technique very often used in programs or when one place tweets in a blog post. Because the style is drastically different it is easy to recognize. Readers of the narrative skips such blocks. Readers of the use case skip the narrative and hop from blocks to blocks. To become a use case as is defined at http://kneaver.com/blog/2014/12/a-framework-for-xapi-2-0-use-cases/ various elements of the case must be identified: application, stakeholders, goals, as well as all information relevant to the learning experience type. What we want to focus now is what and when events will be tracked, why and how they will be encoded in statements. Being it xAPI or an alternative, the questions will remain the same. All system supporting semantic genericity will offer the same choices. In xAPI, statements are made of “subject verb object”. We are going to concentrate on verbs. It is important to use the exact verb definition and leverage the freedom offered by the genericity. It is also important to reuse existing verb definitions to save time, normalize the data, allow comparing experiences, profile learners, and tools. My guess is that learning experiences could end up using 50 event factual ones (clicked, answered, watched), 50 more abstract (learned, practiced, applied).

The catalog case

The first case is the easiest. You have a catalog of good practices with a list of learning experience use cases. You browse and recognize a case similar to your case. The subject matter could be different, but devices, context should be similar. Personas should be congruent, you could place your persona in lieu of the stakeholder of the use case.

Example:

A use case of adult self-directed learner watching a short video. After some explanations, the author of the use case explains that it’s not interesting to capture so much detail on this event because it’s an adult, motivated and we can rely on him to be attentive even if interrupted. In this case, the statement could be <X> <watched> <this video> and we can presume that this translate well to <X> <learned> <this concept>. In the same catalog, we could have different use cases with young children, long videos, noisy workplace areas, boring compliance stuff etc.. The same software event “playing a video” could lead to totally different statements and different translated statements.

Note:

What I mean by translated statement is the statement at the learning experience level. The one that really count but can’t be captured systematically. In xAPI it could be captured and used as a context statement for the more atomic ones. The goal of the use case is to suggest use of existing verbs both for event factual level and abstract levels.

Note:

Of course most tools would suggest you just use a verb exactly describing what happened with no translated statement, no semantic attached. This will lead to the bias described in the beginning.

New territory case

You couldn’t reuse a case that match your narrative. You will have to think out of the box. For the event factual level, we should be led by the facts themselves. Hopefully, registries will be available and it will be just the case of searching them by trying some keywords.

Example:

Your learner must tweet during a lesson on social media. You got to the registry and search “tweet” or “twitter” or “microblog”. It’s expected that quickly the registries will be rich enough to cover most common cases. https://registry.tincanapi.com/#uri/verb/193 For the abstract levels, the problem is not only to find a verb but also to understand where to track it and what should be attached to it to make it meaningful. Due to the nature of event logger of xAPI, for example, some strategies applies. You can’t modify or remove a statement. So if you have a blanket statement created at the beginning of the experience it will be too soon to capture the success of the experience. This statement will mostly serve as a grouping event. The story itself will correspond to a sequence of statements for a given learner, it’s easy. When in your narrative you describe an important step in the learning path it will be time to add more events. That’s where the concept of narratives come into play. The narratives will allow to explore different cases of different learners and understand what differentiate them, what is similar and when they differ. Each statement will correspond to a specific event in the learning experience. Collecting this event should make sense from a learning perspective.

Example:

- A group starts a group discussion. One event is generated for that with the whole group as a subject. - Each learner will watch a video after the discussion with some instructions for a feedback activity about the group discussion. An event could be captured for that. Not so important IMHO. - Each learner now submits some feedback. That could be the occasion to have some peer evaluation or self-evaluation and capture a learning event. Which one, why, which details should be attached to the event is really what should be explored and documented. Once use cases have been explored that could submitted to a repository of uses case and grow the catalog used above. What will be contributed is not only verbs or activity types but also a complete use case supporting the kind design activity we have seen above. With the use-case, we will also have the narrative, possibly edited to remove confidential stuff.

Why this detour

Why not jumping directly to choosing verbs and saving statements? Without uses case and narratives? We would end up with only low-level statements or a profusion of different verbs with irreconcilable meanings. Choosing a verb and a statement requires a thinking process. It is not only collecting but how they can be used after and aggregated across experienced. Uses cases bring a higher level of meaning. They are also easier to share. Why narratives? Narratives give the ground of the use cases. Writing good uses case directly fails often we learned in marketing and user experience design. Uses cases tend to be very abstract and disconnected from real stories. When you read an isolated use case you don’t see if they are plausible or not. When you start discussing plausibility of uses cases we end up fteching parts of unwritten narratives. It’s better to write and establish narratives and write uses cases from them. Use cases are good as synthesis but not to support design thinking or critical thinking. Also, uses cases carry only one part of the description.

Perspectives

This process will help the community to grow a catalog of use case allowing a consistent learning experiences events collection to take place. It will be a reference for new designers to apply best practices. Verbs, activity type will be contributed to a shared repository. It will reflect a shared controlled vocabulary of technical terms while remaining open and extensible. Use cases can also be used by tool vendors and standard developers to enhance their offering and environment. This is how the software developer community work via sites like GitHub, StackOverflow, npm, bower. It led to technology like HTML, CSS, responsive design, jQuery, NodeJS etc. It’s more than open source, it’s open knowledge reusable for every purpose commercial or not, closed or not, for free. We can witness in our everyday life the effect of this great effort of building best practices via open collaboration. What do you think? Jump in the comment section and let’s start the conversation