TMCnet News
REDISCOVER THE VALUE OF A PROTOTYPE [T + D](T + D Via Acquire Media NewsEdge) When developing mobile learning, prototypes are a vital step to consider adding to your design process. This is true especially when you have high-quality assets you can procure from marketing or shoot with your digital or smartphone camera. We've been able to move from script to storyboard to final deliverable in such a short time that creating a prototype seems like an overengineering exercise. However, with recent changes in tooling and design, and a totally new interaction model offered by mobile, you may find yourself in foreign territory. Gestural inputs are new to many of us. How will a pinch-and-zoom affect the interactions you have planned How do we prove whether our replacement interactions will work or be easy to use We need to plan and test, and plan and test. On top of all of this, many of your existing e-learning tools may have deficiencies in the mobile area, or perhaps they don't function at all. This might have you feeling a bit out in the cold as to how you are going to create a home for all of your great content. It's not that bad, though. A prototype is a functional or semifunctional demonstration of a system or project. It can be used to discover issues in the planned execution or plan for a project, prove a strategic approach, or test the value of an idea from a specific aspect. There are several options available in mobile development. Everything from low-fidelity paper prototypes to high-fidelity clickable prototypes can be options for bringing ideas to your team and stakeholders. The value to mobile learning The design of mobile learning is a new discipline for many of us in this field. There are a host of new considerations you must recognize before you begin a comprehensive mobile learning effort (for example, not just one app, but perhaps multiple; not just a website, but a strategically positioned one connected to a content management system). These considerations range from choosing user interface conventions to picking development methodologies and deployment paths. Each of these areas is worth exploring in a prototype phase to get kinks out before the real costs start to add up. Making decisions and finding problems earlier in the process is far less expensive and requires shorter revision cycles and approval times. The bottom line is that prototypes save time and money. Everyone can agree that that is a good thing. When to prototype When other early deliverables - such as sketches, wireframe, and whiteboardsare just not enough, you'll know you need to create a prototype. Sketches, wireframes, and whiteboards are definitely powerful ideation tools, but offer little in the way of helping to test functionality and definitely don't help you understand how the delivery of the final product will actually work. These richer tests made possible by prototypes are necessary when people need to experience your website or application to visualize how it will work and how they will integrate it into their workflows. Create a prototype to prove your concept and even to connect the systems (deployment, content management, learning management) represented in it. The connection points could be somewhat less than obvious depending on the integrations, with customer relationship data and sales bulletins intermingled with training content. Make clear what you are proposing at this stage and don't overcommit. Remember, you're testing a path, not forging a method set in stone. You'll need to start a prototype phase in time to validate its results in advance of a formal development effort or a larger pilot project. Have resources available for both the prototype testing and the followup survey or measurement phase, where the results will be collated and the findings shared with the team at large. With a plan in place, a prototype can be created wherever you are in the process. This flexibility is liberating. With a prototype, though, you must make plans to receive the results, review them, and be able to make recommendations on how the next stage will change based on the collected results. This is harder than it sounds. Too often issues arise when a prototype testing phase ends and not enough time is given to analyze the results before jumping to conclusions. Remember: A prototype without analysis and testing is a proof of concept, not a complete prototype. While that's not bad, it is not what you are looking for here. How to enter a prototype phase A prototype must be a deliberate undertaking. You will need a focus and numerous tests that you plan to run in the process. The prototype may be design oriented, function oriented, or perhaps a test for usability and user acceptance. The table above offers sample prototypes and some considerations. A successful prototype is usually the first version of a product meant for testing purposes. It might not work as a program or unit, but it is made to present a potentially viable product visually. Depending on your project's needs, and sometimes the culture of the company or the team assembling it, this state of the application can vary in terms of detail. At the outset there are several factors you need to be aware of and prepared for. To come out of the prototyping phase successfully, address the following in the initial planning stage: * prototype goals * prototype fidelity * prototype deliverable format * prototype designer * prototype developer * prototype content developer or writer. Make your goals explicit at the onset. The goals set for your prototype will inform the subsequent factors. A prototype that is created to prove the feasibility of a human-computer interaction or solve a usability issue has different fidelity and design needs than one that tests and proves data communications with a server or between servers. Prototype fidelity is a more abstract concept. The graph on page 37 maps a prototype's trueness to its final deliverable (fidelity) against the effort level or scheduling it's going to take to get it done. It boils down to this: The closer the prototype is to the expected final outcome, the more time and effort the prototype is going to take to produce. The interesting point here is that a clickable sketch, which takes little time to produce (relatively low fidelity from an image standpoint), may pass an important usability test or prove whether people will use an app or service. As you can guess, you can accomplish much without breaking the bank. There are many great products that allow you to take design assets and move them directly into a prototyping phase with little (if any) programming requirements or extra work. Many of these tools are web-based and operate as softwareas-a-service (SaaS), so their overall licensing requirements and costs are low. InvisionApp, Daio, FieldTest, and Justinmind's Prototyper are a few that you can try out easily to determine if they meet your needs. Others have found great success with such tools as Keynote and even PowerPoint when used for clickable, high-fidelity prototypes. Don't believe me Check out www.keynotekungfu.com to see how far you can take presentation software as a prototyping tool. There are options out mere; you just need to be creative. If you are going to be using a tool such as one of these, keep the following in mind. Skip the lorem ipsum text. Surely you have some relevant placeholder copy or can whip some up in a few short hours, right Why bore or confuse your users and testers with Greek text Sketch at scale and correct aspect ratio. For example, if your target tablets are 1024x600, then scan in and prepare your sketches via a graphic editing program at that scale for quick and accurate review. You cannot test user interface for a mobile device reliably on anything other than a mobile device. Use real user interface elements as quickly as you can. Enough templates, sample themes, and downloadable kits exist that you can be using real iPhone or Android buttons and controls in minutes. You'll save yourself time, and get closer to the finished product at the same time. Obey the interface guidelines for your desired platform, and don't deviate. Android and iOS devices look and feel different from each other, and they obviously are very different from desktop user interfaces. Don't simply resize your e-learning content with the same interface elements in them. That's a recipe for failed usability and confused users. With these helpful suggestions in mind, you are already much closer to success than you may think. The deliverable format doesn't have to be a head-scratcher, either: Get the prototype out to people and have them use and review it. That should be a baseline expectation. A prototype is not set up to succeed if it requires a special software install or a trip to the testing lab to try it. Prototyping tools should be accessible and usable with minimum fuss. This can be done efficiently over the web with rapid -prototyping tools. You can even put the prototype at a hidden URL or password-protect it with one of the many aforementioned packages. To maintain maximum continuity, the designer and developer resources used on the prototype ideally should be the same that will be used to create the final application. If this is not possible due to time constraints or resourcing issues, make sure that the team that puts the prototype together is at least as skillful as the team that handles the final development. Do not assume that a rookie team or junior staff member can execute this crucial step as well as a senior-level team member. Success is of the utmost importance in this phase, so the prototyping team must be staffed accordingly. If a junior staff member is the only one available to create the prototype, have his work independently audited prior to wider circulation. Plan to have an available copywriter for the prototyping phase. A product that's going to testers rife with typos and grammar issues or overflowing with placeholder or lorem ipsum text is doomed from the start. Be sure to put the proper amount of focus on the application's content. Delivering a polished prototype that testers can relate to will pay off. When you present the prototype to the testing team, have a form of standardized reporting in place that will allow you to receive consistent input from all team members. This could be an email form, survey, or even a formal testing period with video recording and transcripts. However, understand that formality is no substitute for thoroughness and adherence to your original goals. Keep matters tightly focused, and you'll get the results you need to make informed decisions. Get to testing A prototype project may be a new experience for you as a learning creator. This may be for many reasons, but to test and identify key factors you're going to need in your larger effort, consider putting it on your radar when you move to mobile. Be sure to have ample time to build a meaningful prototype on which stakeholders can weigh in. Remember to share your goals with the testers and the users of the prototype to lay out your expectations for their focus while trying it. Prototypes can have widely varying levels of fidelity and utility, so if you don't cover these with your testers, you may be setting yourself up for failure before they even give you feedback. Having your framework in place to accept and collect this feedback for review and processing is vital. After a prototype project or two, you should consider running a pilot program to work out any kinks found across the entire product life cycle. Everything from design to delivery to post-launch maintenance should be considered in a comprehensive pilot project. LISTEN TO THIS FEATURE at www.asid.org/TDpodcasts Prototyping may be a lost art in the training and development world. Rapid tools for e-leaming may have dulled our skills in building something quick to test or get to a few testers for quick feedback. For years prototypes haven't been needed because rapiddevelopment tools make it so easy to bring instructional materials to our audience. Key Reasons to Build Prototypes for Mobile Learning * Mobile development can get pricey. * Mobile development can be tricky if you are new to it. * Building a full project takes time and can get bogged down. Prototyping helps maintain velocity. * Prototyping helps manage cost and risk. * Prototyping helps get buy-in and user acceptance and usability out of the way earlier. INTERESTED IN ORDERING E-PRINTS Would a digital version of this article be a great fit for your next course, presentation, or event Are you interested in e-prints of several J+D articles on a specific topic Visit www.astd.org/TD. and click on "About 7+0." for more information. Prototyping may be a lost art in the training and development world. Rapid tools for e-learning may have dulled our skills in building something quick to test or get to a few testers for quick feedback. For years prototypes haven't been needed because rapid-development tools make it so easy to bring instructional materials to our audience. This is true especially when you have high-quality assets you can procure from marketing or shoot with your digital or smartphone camera. We've been able to move from script to storyboard to final deliverable in such a short time that creating a prototype seems like an overengineering exercise. However, with recent changes in tooling and design, and a totally new interaction model offered by mobile, you may find yourself in foreign territory. Gestural inputs are new to many of us. How will a pinch-and-zoom affect the interactions you have planned How do we prove whether our replacement interactions will work or be easy to use We need to plan and test, and plan and test. There are several options available in mobile development. Everything from low-fidelity paper prototypes to high-fidelity clickable prototypes can be options for bringing ideas to your team and stakeholders. Chad Udell is managing director of Float Mobile Learning. He also works with universities and other learning organizations to develop their unique visions of where and how to use mobile learning. He is author of Learning Everywhere: How Mobile Content Strategies Are Transforming Training, which can be purchased at www.store.astd.org, and has been a faculty member of Bradley University for more than five years; [email protected]. (c) 2013 American Society for Training and Development |