Your Source for Learning
Technology, Strategy, and News
ARTICLES       RSS feed RSS feed

Mobile eLearning Design: How to Survive Your First mLearning Project

by J.P. Medved

March 3, 2014

Feature

by J.P. Medved

March 3, 2014

“Monitor your finished mLearning product for quality both immediately after you complete development and periodically after you’ve deployed the product. Quality assurance can come in the form of use tests, user surveys, and debugging.”

President Eisenhower is quoted as saying, “In preparing for battle, I have always found that plans are useless but planning is indispensable.”


Figure 1:
Eisenhower (center) and his generals: “Planning is indispensable”

The commander of the Allied forces at D-Day, and the architect of the strategy that broke the Nazi war machine, was no stranger to planning. While designing a mobile eLearning experience may not be even remotely as challenging as liberating France, planning ahead is still just as crucial to success.

Mobile is fast overtaking traditional computing; more smartphones shipped in 2012 than PCs and that’s only likely to accelerate. With increasingly mobile and connected workforces, mLearning initiatives should be at the top of any CLO’s list for 2014.

In this article, I’ll present a step-by-step guide for crafting an mLearning project-management plan, and explore how to address unique mLearning design considerations throughout.

Using a project plan template for mLearning

Project plans tend to follow the same rough template as the Project Management Institute’s PMBOK Guide. I’ll use a simplified version to outline your mLearning course development plan, which will cover:

  1. Purpose
  2. Scope
  3. Schedule
  4. Cost
  5. Quality

1. Purpose

The first step in planning for your mobile-learning project is to figure out your goals. Determining your purpose actually consists of a couple different parts, and it’s more complex than simply writing, “Build an mLearning app,” and taking the rest of the day off. The parts you need to define in this stage of your project plan are:

  • Target learners: Who at your organization (or outside) will actually use the material you develop? Ideally, you should create individual profiles for the different learner “types” you have. Do your employees work remotely and require “point of need” training support, or does your workforce travel often and need access to training materials from airplanes or other places with no internet access? Do all your learners use the same mobile devices, or is there a mix? Understanding your target learners’ profiles will help you refine your goals.
  • Assumptions and constraints: What limits your mLearning initiative? Constraints can be organization-based (for example, you don’t have the in-house skills to build a mobile app) or technical-based (such as the small screen size of your targeted mobile platform). Many of these assumptions will play into the target learner profiles that you develop above (for example, if your workforce isn’t tech-savvy enough to operate a web-based app, that’s a constraint). You should also lay out any assumptions about the actual impact the mLearning initiative will have on your organization. Do you assume a certain dollar return? Or productivity increase? Or accident decrease? 
  • Finally, the actual goals themselves: I recommend writing these out using the S.M.A.R.T. methodology. Regardless, make sure you at least answer these three questions:  
    • What are the project objectives?
    • What are the expected outputs from the mLearning project?
    • What are the criteria for assessing project success?

The “purpose” step is, arguably, the most important one, as it sets the foundation for the entire rest of the project. If you skimp here, you could be setting yourself up for failure, even if you manage to build a mobile learning tool.

2. Scope

The scope of your mLearning project plan should be composed of two parts: work breakdown and a deployment plan. Let’s look at both.

Work breakdown

First, you’ll want to detail the different tasks that you need to work on in order to develop a successful mLearning product. It’s helpful to start by diagramming this breakdown, based on different stages in the project. Figure 2 is an example using a native mLearning app:



Figure 2:
Mobile work breakdown map

The map above shows a pretty simplified version, and you may want to include details like who’s leading each effort, and each effort’s estimated time and cost.

Deployment plan

How you decide to deploy your mobile learning experience will depend on several different inputs. That’s why the work you did in the “Purpose” step, above, is so important. Your answers to the three parts above (target learners, assumptions and constraints, and goals) may already have decided your deployment plan.

There are three main ways to deploy mobile learning:

  1. Native application: This is an “app” such as the ones you would find in the Apple App Store. It resides on the mobile device itself and can take advantage of device-specific functionality like the camera and GPS. It also doesn’t need to be connected to the internet for you to access it, so if your target learners work in places with spotty cell service or want to access learning materials on an airplane, a native app is the best way to go. Downsides of native apps include potentially higher development costs (if you need to develop it for multiple mobile operating systems) or being limited to only one mobile platform, as they’re not cross-platform compatible. As such, native apps are not well-suited for BYOD organizations.
  2. Web-based application: This is, essentially, an HTML5 mobile-optimized website that operates very much like an app. Because it uses a platform-neutral language, it’s accessible by anyone with internet access, whether they’re using an iPhone or an Android. That said, it can’t use some of the more unique functionality of a mobile device (like GPS), and you can’t access it without internet or cell service. Additionally, most people automatically think of an “app” as a native app and will expect to access it through a button on their home screen, rather than on a webpage. As a result, a web-based app may not be suitable for non-tech-savvy workforces.
  3. Hybrid application: As its name suggests, this app mixes the above two models by storing some data locally on the phone while also interfacing with the web for updates and specific material. The Wall Street Journal’s app is a great example of a hybrid; you download it as an app to your home screen, and you can access the most recent news even when you’re not connected to the internet. But when you connect to the internet, the app will automatically update stories and download the new day’s paper.

There are a couple of other considerations when making this decision, such as cost, that we’ll get into below.

3. Schedule

Developing a detailed project schedule—with milestones included—is key if you want to have your project done in a timely fashion. The project manager should check in every week to see whether the project is on pace with the original schedule and milestones.

You can incorporate the schedule into your Work Breakdown, and it should include milestones, activities, and deliverables. I also recommend including estimated costs and resource allocation to each.

Figure 3 is a simplified example schedule for a native mLearning app:


Figure 3:
Simplified mLearning app development schedule

4. Cost

Estimating how much the mLearning app will cost to develop is a sticky proposition. There are a multitude of variables that go into figuring the expense, including whether you’ll build it in-house, hire a developer, and what type of app (web-based, native, or hybrid) you plan on developing. That said, there are some good rules of thumb to help guide you in making these estimates.

  • Stick with estimating direct costs, like labor and material, not indirect or opportunity costs.
  • Research from Propelics indicates that it takes one full time employee (FTE) one week to do all the work for one screen of a mobile enterprise app. That means if you have one developer, a six-screen app will take you six weeks (including designing, programming, and testing) to complete. Multiply that time out by the salary of the FTE for a rough estimate of labor costs.
  • If you plan on developing a native app for multiple mobile platforms, be warned: Deloitte says that could increase the cost by 60 percent for each additional platform.
  • If you hire a programmer to build the application for you, it could range anywhere from $8,000 to $50,000.
  • Small costs can add up, so be sure to include things like the cost of converting existing content or images to a mobile format or size.

5. Quality

In this part of the plan, you need to do two things:

  1. Define which quality standards you will use to measure the project.
  2. Come up with a monitoring process to measure these standards.

For an mLearning app, quality standards will vary based on your goals. The Tennessee Board of Regents came up with a set of standards for educational mobile apps that includes:

  • It is aligned with the curriculum
  • It can be measured in terms of students’ outcomes
  • It allows the instructor to monitor and track students’ progress
  • It provides at least two learning modalities options (visual, audio, etc.)
  • It can be used without the internet

While their list does not include technical issues like a minimum number of bugs or accessible user interface, these may be items you want to add to your own QA list.

Monitor your finished mLearning product for quality both immediately after you complete development and periodically after you’ve deployed the product. Quality assurance can come in the form of use tests, user surveys, and debugging.

Next steps?

Some final, additional things you may want to consider when planning for your mLearning project include using a mobile-friendly learning management system and getting a developer account for the mobile platform on which you plan to deploy (if a native app).

Did I miss anything big? Add it in the comments below!


Topics Covered

(21)
Appreciate this!
Google Plusone Twitter LinkedIn Facebook Email Print
Comments

Login or subscribe to comment

Hi, the statement in the article regarding native applications may cause some confusion "[a native app] doesn’t need to be connected to the internet for you to access it, so if your target learners work in places with spotty cell service or want to access learning materials on an airplane, a native app is the best way to go. "

Some native apps will include all of the content and interactivity on the device, however this is not always the case. Many native apps are really a special browser using API's to access and interact with server hosted content. They are a client, not a stand-alone.

The benefits of a stand-alone are as stated, however depending on the amount of content a stand alone might use all/most of the available device memory. Also, if you require some level of reporting or interactivity with a server, then that may not be possible.

The benefits of the client model are that only the content that is needed gets delivered, new content can be deployed automatically and metrics data can be captured by the server.

Many LMSs are bundling native apps for the LMS to allow users to access learning materials via the app rather than a web browser. This means that you (the content owner) don't need to build and maintain an app (for each platform and platform update ... ugh!). But it does mean you probably have to stop using some tried and tested tools like Adobe Flash (which will never be supported on iOS or Android), you will need to convert some old content to HTML5, and you need to think long and hard about how you layout your screens because fat fingers + tiny "next" buttons = unhappy learners.
Related Articles