Building a portfolio – conclusion

Testing and launch

I was nearing the end of the journey: my Storyline project to turn my career into a portfolio was in the testing phase.

I learned to test software in a previous lifetime when I earned the nickname “She who can break anything”. In those days, testers typically ran through the specifications and noted whether they worked as designed. This is obviously critical. (well, maybe not obviously, as one of our software architects believed that he could test as a thought experiment rather than by touching the software) but I was more of an inexperienced user, who might use the software in unexpected ways. Today that’s called user acceptance testing and beta testing, but in the late 80s in our company, it was called something far less flattering.

Testing elearning products requires three types of testing

  • Editing – Is the text correct, and does it express your message correctly? Are the punctuation and grammar consistent and correct? Yes, this is done as part of the storyboard phase, but since Storyline makes it irresistibly easy to edit in the module, you need a final test, somewhere between proofreading and content editing, to be sure.
  • User testing – This is the user acceptance testing – does the final module meet the user-defined goals and learning objectives? Is it easy to navigate and are the conventions consistently used? Most importantly, is the product as compelling and effective as expected? Again, much of this happens in the storyboard stage, but I find that users have an easier time finding inconsistencies and unworkable passages when they see it online.
  • Technical testing – Do all the buttons and links work properly? Does the navigation work smoothly, and will all of the properties (graphics, audio, video) appear correctly? Can the project be correctly linked to the LMS or web site that will be its destination?

In large organizations, these tests can be separated into individual phases (alpha testing, pilot testing, specification testing, user acceptance testing, beta testing) and done by different groups of people. These days, much of the testing, like the production, is outsourced. But for this project, it’s just me.

That does not mean that testing can be skimped. Even if you do your own development, you need to approach testing as though the course were new to you. Based on previous testing projects, I compiled a simple testing form and started to work on the first of two sets of testing.

In the first pass, I worked in a preview version of the deck. Storyline previews are easy to work with, and let me postpone the task of linking the project to my website until the second round of testing.

I identified a few things that were either not working correctly, but a number of standards that I had not applied consistently. These went into a list on the form and would be repaired at the end of testing.

But then I started noticing other things I wanted to change, including dissatisfaction with early design decisions I had made. Why had I used tabs instead of a gallery? Why hadn’t I created drop-down menus? Did putting pictures behind the buttons distract from the readability, or maybe I should have just left the pictures as the buttons and left off the text? These were distractions –I needed to finish the project. Anything that was not fixable in the next development pass would have to wait.

So, armed with my list of fixable items, and setting aside my list of design questions, I repaired the project and started round two of testing. This time I was looking for specific things that had been identified in the first pass, but the second pass was not completed any more quickly than the first. For example, once I had found one title with that had been capitalized differently from its predecessor, I had to examine every title on every layer in the project.

And then it was done. I had fixed all the bugs, and everything worked as intended. The project was published, stashed in my Dropbox™ account, and linked to the website. Along the way, I had learned a lot about Storyline, and more than a little about how I present myself to the world. It’s a good portfolio, but I know that one day I will redesign it.

Lesson learned: Everything can be done in different ways; don’t let perfection prevent you from finishing. There’s always version 2.


Memorable Learning was founded after almost 30 years of telling the stories of people passionate about what they are doing. It began as writing laboratory reports to support a method of protecting a third-world farmer’s hard-won harvest from rats, but soon expanded. Whether it’s explaining a new software product to users, teaching engineers how to share data with international counterparts through an enterprise-wide system, or bringing accountants up to date on new developments in their fields, I’ve been privileged to work with some of the most passionate people in the world.

Leave a Reply