User Experience Design for Learning

One of my highlights from the eLearning Guild’s DevLearn 2013 conference this year was Julie Dirksen’s course in “User Experience Design for eLearning - from Prototyping to Usability”. Julie is a well known instructional designer and the author of Design For How People Learn.
I liked Julie’s book and bought it before the course to find out more about the topic and it gives a lot of information on how to create training that is focused on the user’s needs. Other people attending the course also knew of Dirksen and had read the book - some were only attending because she was teaching there. As we chatted about our backgrounds and reasons for attending the course we realised that we had selected this particular course over others available because we all believed that education had to be built with a user focus to be successful, and wanted a better understanding of how to achieve that.

During the course we were taken on a journey covering many of the principles she has used in designing education. The main focus of this course was to explore a different approach using modern software development principles.

This article is an expansion of my notes from the course and may be more complete on some topics than others but hopefully it gives at least an overview of the course and ideas for taking this principal further.

##Concept Dirksen began the workshop by looking at techniques on understanding the learner, and creating user roles, basically a profile of a typical but imaginary user who would be taking the training used to better understand their needs. This was then linked to understanding the goal of the training.

We started with a discussion of Jesse James Garrett’s elements of user experience diagram. This diagram was built to illustrate user experience design for the web but Julie was applying it to e-learning experience design.

The course was built around each of the levels of the diagram and discussions of how to build education that would meet the needs of the users.

  • Visual Design
  • Interface Design/Navigation Design/Information Design
  • Interaction Design/Information Architecture
  • Functional Specifications/Content requirements
  • User Needs/Business objectives

We started at the bottom layer looking at user needs and business needs.

##User Needs Our first principle in looking at the user is looking at the problem we are trying to solve and the learners relationship to it. Not all learning problems are ones where the learner lacks information. It might be a problem of knowledge, or one of information, but it could be a skills problem, one of motivation or the problem may be the environment itself. You may be familiar with “KIS ME” as an acronym. Knowledge, Information, Skills, Motivation, Environment. This approach is covered extensively in Julie’s book Design for How People Learn, and has has proved to be a useful framework to better understand the user. Julie’s favourite maxim is “Respect the learner for they are not you”.

To quote from

“User experience (UX) focuses on having a deep understanding of users, what they need, what they value, their abilities, and also their limitations.  It also takes into account the business goals and objectives of the group managing the project. UX best practices promote improving the quality of the user’s interaction with and perceptions of your product and any related services.”

###Expert Viewpoint The standard design process is usually based on stakeholders representing the needs of the business and the subject matter expert providing the content. However an expert’s model of the world differs from that of a novice; the expert’s model of the situation is often very well organised and sophisticated. Julie likened this to a large very organised closet with the novice’s model being a pile of clothes dumped on the floor. To organise a novice’s ‘closet’ we need to built ‘shelves’ to store the ‘clothes’ by which we mean mental models and frameworks.

Many learning programmes have little focus on analysing users needs from their perspective and rely only on the expert point of view. Recent learners are a great resource and are useful to understanding the learner viewpoint

###Contextual Analysis We next looked at what we could borrow from analysis methods from website and software user experience design. The first subject was contextual analysis, otherwise known as job shadowing. How does this help us? Actually being on site watching people use our material enables us to see how its used in the real world, which often differs from the sort of reports you would get from a focus group. In contrast to interviews we can gather types of information that people would leave out. If we see the environment we get a clearer understanding of which behavioural triggers and memory prompts are available in the environment. Details matter if you want to resonate with your audience as it shows that you understand their world.

There are many approaches we can take to understanding our learners. User interviews are a first and important part of this process but we can go much deeper using tools like [Contextual Inquiry] (

###User Interviews The next part of the course covered how to create questions and conduct conducting interviews without adding our own bias to the results.

###Persona Development Building a course based on the statistics of your audience demographics may cause you to design for a non existent statistical average. Obviously you can’t design for each individual so developing personas is one way to ensure you develop for representative users. Developing a persona must be done from real world experience, such as contextual inquiry and interview data.

##Business Needs Along with user needs we need a good understanding of the business objectives in relationship to user needs and performance change. So we need to be able to define this concisely. This leads us into the next section where we can further refine this.

##Problem statements To be able to solve a performance issue we have to clearly define the problem. This helps us not to immediately jump to the conclusion that training is the solution. Stephen P Anderson’s the “Author of Seductive Interactive Design” has a slideshare presentation “Stop Doing What You’re Told!” which shows the design pitfalls people often slip into, and how to create useful problem statements by asking better questions, thus getting to the real cause of the problem to make sure we are solving the right issue .

##Learning objectives After we’ve defined the problem we then need to convert this into defining the goal of the training. There are several ways we can get to that point. Cathy Moore’s action mapping can help us define what behaviour we are trying to change and [how to change it.] (

##Solutions thinking Once we have a goal we then need to think of a solution. Ideally this is done using research-based learning techniques to create a solution which is then prototyped and tested. Based on the feedback the design is then improved and we go through this cycle until the course meets the goal most effectively.

Can it happen in the real world? Can you tell if they’ve done it? If the answer is ‘no’ then we don’t have good objectives. Use learning objectives and time constraints to include only essential content. In Julie’s words “Don’t give people the entire closet - it’ll just end up on the floor”

##Interaction Design So we have a solution in mind which meets the learning objectives, how do we get from concept to delivery? We need to build a prototype! There are many well tried prototyping methods in interface design from graphics tools which do wire-framing, rapid prototyping tools where we were encouraged to make ugly prototypes, “you can make them pretty later!”. In Dirksen’s course we actually tried a more manual method using paper and flip charts however there are other simple ways to create a working prototype, such as powerpoint, Storyline, Captivate, Balsamiq or Axure

##Content architecture At this point in the course we were focused on cognitive load as a factor in learning, ensuring all cognitive resources are spent on content (interaction) not on anything else (navigation, instructions etc).

To develop a good architecture we could again lean on software development techniques to define what goes where in our information architecture. This can include techniques such as card sorting to define information relationships and grouping. This is where we put each subject on a card and shuffle them around on a table to see where they best fit. The arrangement of cards can then be turned into storyboards or content grids

Navigation Design/Interface design:

  • Fitt's Law
  • Grouping and chunking
  • Top left and lower right
  • Instructions F-shaped reading
  • Five second usability

Defining ‘red routes’, which are expected user paths through the information to make it easiest to find what the user expects. This is harder than it sounds and may require a number of rounds of testing to see what these will be.

##Testing your designs How should we test our designs? We had some recommendations to look at based on usability testing (Steve Krug - Don’t make me think, Rocket Surgery made easy)(

We also defined what Usability testing is NOT:

  • User Acceptance Training
  • Focus Groups
  • Demos
  • ending the link for feedback
  • Quality Assurance Testing

Steps for User Testing:

  • Create a test plan
  • Recruit users (5-6 testers 1-1.5 hours each)
  • Write a script giving them an understanding why they are there , that they can't do anything wrong, we won't help, talk aloud
  • Watch them use it
  • Document the results in a report which turns into design recommendations to then be further tested

This is a very brief summary of my notes from the course and there was a lot more depth than I can show in a short article, especially as I found myself more engaged in doing the training than making notes! Using established software development techniques and tools looks to be a great way to get started on user focused development of training and I’m keen to see what techniques we take from this as a team and what training we’ll develop because of it.