As you build systems and create information products (e.g., digital libraries), you assume that you know how it will look to people who use it. However, do you ever check to see if your assumptions are true?
This came to mind to day after receiving an electronic document from someone and seeing that the fonts used were not fonts that my computer recognized. It was easy to rectify, but here someone had made an assumption about what my machine could handle (and what the document would look like) which was not true. This problem can also occur with web sites because of how monitors can vary, screen sizes, differences in browsers, etc.
The solution? Testing, testing, testing. Okay, you know to test a web site on multiple browsers and monitors. And you do test your PowerPoint presentations on different machines (and in different room environments) if time permits. But what about those other files you send around and those formatted/stylized e-mails? During the summer, I sent an e-mail to a a large group of people and I did test it ahead of time by sending it to my many e-mail accounts on different e-mail systems. That allowed me to see how the message might look on the receiving end and led me to make several changes to the e-mail message. (Oddly, I found that the best thing to do was to build the HTML e-mail in FrontPage then copy it into Outlook. That seemed to ensure that the formatting was more correct when people received it.)
Testing, though, is time consuming and it slows us down. We skip testing because we think all will be okay (based on our assumptions), but that is likely when something will go awry. For example, a remember hearing a story about an international non-government organization (NGO) who had created an information product to be used by people around the world. The product was housed on the organization's central computers and people accessed it over the Internet from various parts of the world. Unfortunately, the organization assumed that the access would be as fast and cost effective as it is in the U.S. It wasn't. Testing early on could have lead them in the right direction. Instead, they ended up getting feedback after the product had launched and then devising the product and disseminating it on CDs.
You might say that the product definition phrase should have been done better, but testing finds those things that aren't thought of. Testing during a products development ensures that it meets the users' needs and works within their environments.
Yes, testing does cost us time and money, but it can save time, money, aggravation and reputations in the long run.
If you're in the middle of creating something that people will see on their own computers and in various environments, why not take some time to test it now. Make sure your assumptions are true.