My role as a Learning Designer is to assist academic authors in the design of learning and teaching, through facilitating a structured design process, inputting on and challenging teaching approaches based on my own understanding of pedagogy and evidence, and generally being a pedagogic pal / guide on the side. I've been doing this across a range of modules over the last few years, and have had pretty good feedback overall. I've taken two approaches with this during that time, one the 'official' path that's part of our established processes - and the other the approach that's gradually evolved within my own practice in response to feedback, my own experiences, completing the Educause LX Learning Architect pathway, and my growing understanding of pedagogy.

The (old) OU Core Offer learning design approach

The Learning Design team used to use a 'core offer' of standard sessions as its basis. My Learning Design journey used to start with a Learning Design Workshop. This was traditionally a 1-2 day long in-person workshop that acted as the official kick-off for a module, feeding in to the specification, and addressing the key design points along the way in a series of activities:

• Requirements gathering with module team chair

• Learning outcomes design

• Student profiles (asking teams to generate a series of straw person student profiles, to generate design considerations and sense check later outlines and drafts)

• Design challenges (consensus activity to identify and group potential pedagogic challenges)

• Activity types composition (based on our taxonomy, the aspirational makeup for activites across the module as a whole)

• Student journey mapping (an initial mapping of the main components of the module)

Pre-pandemic it was a lot of folk in a room, putting heads together, discussing things, and moving a lot of post-it notes around. As the design process progressed I'd then follow this up with:

• An activity design session, looking to sense check initial drafts against OU design principles.

• Tools selection session (helping teams decide which tools and tech best fit their design intentions)

• Workload mapping (a student experience review of module directed workload, activity mapping and alignment across a module - often alongside a top-level draft review).

• Evaluation (A range of activities, including student surveys, data evaluation and student panel consultation).

I've run these activities with a lot of teams over the last few years, and while it's pretty comprehensive - I'd found the move to remote working had made the 'group work' aspects of it tricker, and that remote workshops are much more cognitively draining for participants. I'd also found aspects of the approach a little bitty, and didn't always line up flexibly with the priorities and positioning of the team.

This and feedback with authors led me to tweak my approach a little.

My evolving learning design approach

Before moving in to my current role, my more recent approach as a Learning Designer was a little less component/group activity based, and relied more on structured conversations, asynchronous work and then bringing everyone together to sense check, challenge and discuss things. I found it more flexible, more personal - and seemed to have a better overall impact.

• Initial chat - where is the module team in terms of design and thinking? Do they have any initial concerns or development needs we should address first? Is there space to front-load the design work?

• A series of discussions with the core authoring team, stepping through the data and understanding around students, the context, vision, learning outcomes, assessments, key skills (constructive alignment) and story of the module. Many of these are run as an asynchronous activity, followed by an opportunity to respond to it - and then coming together as a small team in a session to discuss the ways forward. This gives folk time to really mull things over, rather than pushing for quick synchronous decisions. I've also found it a good way of drawing out responses from quieter members of the teams.

• Return to the wider team with the design thinking so far (usually with some visualisations), sense check and look for holes in constructive alignment, discuss challenges identified. 

• Iterate, and then off to the production races.

While the underlying direction and items covered was the same as our normal approach, I found this got around some of the big challenges of remote collaborative work - getting anything productive done when there is a single channel of communication, and people's finite capacity for online meetings. In-person you can have multiple conversations going on simultaneously, and you can communicate nonverbally with a room to show your reactions, indicate when you'd like to chip in and so on. Online, not so much.

With this approach, the heavy lifting of ideation and response are offloaded to asynchronous activity beforehand, and then when everyone's together they've had a chance to reflect, view one another's arguments and can have a facilitated discussion through them. It also means we make full use of time together for discussion and decision making, rather than wading through presentations.

There's a bit more to it that that, but I've given some examples of a variation of this in the Evidence section of this page, in the form of a predesign proposal and evaluation.

Considering the technology that enables all of this, there's glimmers of options appearing to give alternatives to traditional video calls. Over the two years I've tested a variety of virtual environment tools which have allowed more organic collaboration - but haven't quite found one yet that hits the sweet spot of usability and free-to-use-for-education-purposes-ness. Miro, a rather fab collaborative whiteboarding (and much more) tool does get us half of the way there, but I think there's still a gap in the market some bring spark needs to fill to get a proper organic discussion going remotely.

As a team, we're now working towards a more hub / consultative approach that I've been helping to design as part of the coordinating group. I think the hub domains are also named after an infographic I knocked up on the quick, which was unexpected.