*This email is about usability testing process. If you aren't interested in this topic, you can skip this message.
[..] > I've been working on the website redesign as a "slow burn" project for > the last several months. What drove me to get this iteration finished > is that I'm working on a usability test of the updated design. > > "Usability" means that real people can do real things in a reasonable > amount of time. A website has good usability if real people can use > the website to learn about FreeDOS in a reasonable amount of time (a > few clicks to find the right content). > [..] I wanted to share a preview of the process in usability testing. As I mentioned in my other email, I teach a graduate level course in Usability and Human Factors. Several years ago, I also taught an undergraduate course in Usability Testing at a different campus. So I'm familiar with what the students need to do to design, build, execute, and analyze their usability tests. If you want to learn more about usability testing, you might be interested in my presentation to GUADEC last year. Skip ahead to 3:33:00 in this video for my presentation about usability testing in open source software: https://www.youtube.com/watch?v=28junhvu6EQ Here's the process the students will likely follow: 1. The first step in any usability test is to understand the users of the system, and what those users do on the system. The standard way to do that is to interview the client (that's me) to ask questions, then create what are called "personas" and "use scenarios." I'm meeting with one of the student groups tomorrow; the other student group is still figuring out a time to meet, but probably in the next few days. A persona is a fictional - but realistic - description of a typical user on the system. A project will usually create many personas to describe lots of different people - because you don't have just one kind of person using the system. If you were doing a usability test of a word processor program, you might have personas that described a business person working in an office, an independent author, a university student, a home user, and other personas that describe typical people who use a word processor to do anything. For the website, I imagine the students will create personas like an expert DOS user (someone who has been using DOS since the 1980s or 1990s), a DOS developer (such as any of you), a beginner user (someone who only recently discovered FreeDOS) and probably 4 or 5 other personas. Those personas might do different things on the website. Each "thing" that a persona might want to do is called a "use scenario." For example, a beginner user might want to download the FreeDOS distribution (that's a use scenario) or they might want to learn how to use FreeDOS (that's a different use scenario). Different personas might have the same use scenarios - for example, pretty much everyone will probably want to download FreeDOS. When I teach usability, I have my students review the personas and use scenarios with the client. So I expect to review their personas and use scenarios, probably in about a week. (If the students give their permission for me to share, I'll share copies of these - probably in the wiki.) 2. After you understand the typical users who use the website (by writing personas) and how those users might use the website (by writing use scenarios) you move on to the next step: writing scenario tasks. The scenario task is the heart of a usability test. You use these in a usability test by giving each tester the scenario tasks, one at a time, and observing what the tester does, and how easy or hard it is for them to do it. You need to understand who uses the system (personas) and how they use the system (use scenarios) so you can write scenario tasks that accurately reflect what real people would want to do on the website. There's an important difference from use scenarios: the use scenario describes what the persona might do at a high level - they want to download FreeDOS, or they want to learn how to use FreeDOS. When you think about use scenarios, think about *intent* of that persona. What does that persona intend to do on the website. The scenario task is a specific action or goal that someone might have on the website. The scenario task sets a brief context, then asks the tester to do something specific. For example, if you were doing usability testing on a web browser, you might have a scenario task like this: "The text on this website is just a little too small to read comfortably, and you don't have your glasses with you. Make the text bigger on the website." In this case, the context is clear: the text is too small to read. And the task is also clear: make the text bigger. The tester will know when they have completed the task, because they will have made the text bigger. And as an observer, you should agree that they've finished the task, because the tester will have made the text bigger. When I teach usability, I have my students review their scenario tasks with the client. I expect to do that here, probably in a few weeks. (If the students give their permission for me to share, I'll share copies of these - probably in the wiki.) 3. Once the students have their scenario tasks, they'll identify testers for their usability test. You might think this requires a lot of testers to get good results, but actually you only need about 5 testers to get results that are "good enough" to make improvements to the system. So I imagine the students will get 5 or 6 testers (it's always good to get an extra tester in case one tester doesn't show up, or if one tester has problems - at least you have the other 5, and 5 is the minimum.) 4. After completing their tests, the student groups will collect their observations and compare them using a variety of methods. Then they'll write a report about their test. Most usability test reports discuss what worked well for testers (which scenario tasks were easiest for testers) and which were hardest (which scenario tasks were most difficult for testers). I'll get their usability test reports in May. (If the students give their permission for me to share, I'll share copies of these - probably in the wiki.) Jim _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
